It's actually recommended not to do this. Using the HTML hidden attribute will do this for you, which is the benefit of using HTML developer.mozilla.org/en-US/docs/W...
What's the use case for this? The current trend with accessibility is to never hide anything from a screen reader. Is it just an easier hook for javascript?
Actually, the hidden attribute is a lot less useful than it initially seems. It has a lower order of priority, so any CSS rules which change the display of an element will be able to completely override it. For example:
<divhiddenstyle="display: block;">I am not a hidden element!</div>
This bit me this week. Changed a div to a font awesome icon, but the fa class overrode the hidden attribute, so the new icon was unexpectedly always visible.
You will likely improve the accessibility of that icon considerably if you use an inline SVG, although not knowing your exact situation, I can't say that with absolute certainty. Font icons typically don't play nicely with screen readers or Braille browsers, so that icon becomes effectively non-existent for people relying on that technology to browse the Web.
From an accessibility context, you can generally add a label to the control in any variety of ways, and show that instead of an icon. Which how I generally use fontawesome.
Not all screen readers will read out title attributes, so you shouldn't be relying on that. You can use ARIA attributes instead, but therse should be used as a last resort.
Also, inlining and SVG can be useful to avoid extra HTTP requests, all of which have a negative impact on the performance of the page, especially if the user is on a slow or metered connection (which is most of the world, including a lot of the USA). Again, I'm not saying always do this, but it can be used as part of an overall strategy.
Probably not necessary to include the whole of Bootstrap for what is effectively a 4-5 lines of CSS to set an item to be visually hidden but available to screen readers as well, that will be another performance hit.
Even if you can't inline the SVG, you can make it a background image and add it in as a data URL in the CSS. For icons this is generally fine, as icons are very simple, so the data URL is actually quite small. It's often more performant to do this than have the CSS reference external image files.
I'm already using Bootstrap for many other things, when it comes to this. Plus I already compile the parts I need with SASS, and minify the whole thing with Webpack. So it's actually not that much of an issue.
Font-awesome is much smarter than it used to be. The npm/webpack version allows you to pick and choose which icons you need, so you don't have to ship the whole icon pack.
The size of the request isn't the only issue. The whole HTTP request has a connection negotiation step before content is transferred which also takes time. On a slow connection (such as dialup or a lot of lower end mobile phone plans) or on one with high latency (for example, satellite connection where upstream requests are done via dialup). The number of extra HTTP requests is a big drain on performance, and ultimately that affects the accessibility of the content too.
Try testing your site/webapp out on a browser with a throttled connection and see how well it performs. You'll see that it's those extra requests which can really have the biggest impact. And when content isn't loaded by a specific time, you can run into all kinds of issues with document reflow, hidden or missing content, and in the worse case, errors caused by code which expects the content to already be there.
I'm not trying to crap all over things like Bootstrap or Font-awesome, but I'm saying it helps to be aware of the issues they can cause and not just the issues they solve.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Can't believe I didn't know about the "hidden" attribute!!!
BTW, don't forget to addaria-hidden=truefor accessibility ;)It's actually recommended not to do this. Using the HTML hidden attribute will do this for you, which is the benefit of using HTML
developer.mozilla.org/en-US/docs/W...
You're correct, I thought about it after! And it would be silly to do that in that case. Cheers :)
What's the use case for this? The current trend with accessibility is to never hide anything from a screen reader. Is it just an easier hook for javascript?
Actually, the
hiddenattribute is a lot less useful than it initially seems. It has a lower order of priority, so any CSS rules which change the display of an element will be able to completely override it. For example:This bit me this week. Changed a div to a font awesome icon, but the fa class overrode the hidden attribute, so the new icon was unexpectedly always visible.
You will likely improve the accessibility of that icon considerably if you use an inline SVG, although not knowing your exact situation, I can't say that with absolute certainty. Font icons typically don't play nicely with screen readers or Braille browsers, so that icon becomes effectively non-existent for people relying on that technology to browse the Web.
From an accessibility context, you can generally add a label to the control in any variety of ways, and show that instead of an icon. Which how I generally use fontawesome.
<button title="GitHub"><i class="fab fa-github"></i></button>
This gives the button a tooltip, which screen readers can read instead.
<button><i class="fab fa-github"></i><span class="visually-hidden">GitHub</span></button>
Or a "hidden" span using Bootstrap 5's utility classes.
Not all screen readers will read out
titleattributes, so you shouldn't be relying on that. You can use ARIA attributes instead, but therse should be used as a last resort.Also, inlining and SVG can be useful to avoid extra HTTP requests, all of which have a negative impact on the performance of the page, especially if the user is on a slow or metered connection (which is most of the world, including a lot of the USA). Again, I'm not saying always do this, but it can be used as part of an overall strategy.
Probably not necessary to include the whole of Bootstrap for what is effectively a 4-5 lines of CSS to set an item to be visually hidden but available to screen readers as well, that will be another performance hit.
Even if you can't inline the SVG, you can make it a background image and add it in as a data URL in the CSS. For icons this is generally fine, as icons are very simple, so the data URL is actually quite small. It's often more performant to do this than have the CSS reference external image files.
Good point on the title attribute.
I'm already using Bootstrap for many other things, when it comes to this. Plus I already compile the parts I need with SASS, and minify the whole thing with Webpack. So it's actually not that much of an issue.
Font-awesome is much smarter than it used to be. The npm/webpack version allows you to pick and choose which icons you need, so you don't have to ship the whole icon pack.
The size of the request isn't the only issue. The whole HTTP request has a connection negotiation step before content is transferred which also takes time. On a slow connection (such as dialup or a lot of lower end mobile phone plans) or on one with high latency (for example, satellite connection where upstream requests are done via dialup). The number of extra HTTP requests is a big drain on performance, and ultimately that affects the accessibility of the content too.
Try testing your site/webapp out on a browser with a throttled connection and see how well it performs. You'll see that it's those extra requests which can really have the biggest impact. And when content isn't loaded by a specific time, you can run into all kinds of issues with document reflow, hidden or missing content, and in the worse case, errors caused by code which expects the content to already be there.
I'm not trying to crap all over things like Bootstrap or Font-awesome, but I'm saying it helps to be aware of the issues they can cause and not just the issues they solve.