Cory LaViskaTo make websites as usable to as many people as possible, following accessibility standards is key. So it’s important for developers to get into the technological weeds to create with accessibility in mind. That means their HTML needs to be semantically on-point. But sometimes “letter of the law” conformity produces more heat than light. One case in point: the debate over <i> tags vs. <span> tags. But does an <i> tag degrade a site’s accessibility?
TL;DR
Jump to section titled: TL;DRUsing <i> is an abuse of HTML semantics, but it doesn’t result in any accessibility problems that would adversely affect users under most circumstances. Even in screen readers configured to highlight emphasis, nothing would be announced when 1) the Unicode character is unknown and 2) the icon doesn’t have an aria label attached to it. If the icon had an aria label attached, it would read something like: “[Label], emphasized,” but it will still ignore unknown symbols. Check the end of this article for caveats. (BONUS: We make accessibility easier!)
To <span> or not to <span> that is the question.
Jump to section titled: To or not to that is the question.One common and ongoing debate in the world of Web accessibility is whether or not it’s important to use <span> tags instead of <i> tags since it’s believed that <i> tags degrade the accessibility of a website.
This is a common complaint, and I’ve seen much digital ink spilled about this over the years. In this case, <i> is all but deprecated in HTML5 in favor of the more semantic <em> element, so many automated a11y checkers falsely call it out just for being on the page, as shown in this issue from 2020.
There’s some good info in that thread, and, as Font Awesome’s Principal Software Engineer Rob Madole points out in the final comment, applying <i aria-hidden="true"> will hide it from assistive devices, often allowing it to “pass” these automated tests. This doesn’t fully solve the problem, though, especially if you want the icon to include a label like <i aria-label="Mark as favorite" class="fa fa-heart"></i>
For a more concrete answer, I created a simple test page with the following:
Jump to section titled: For a more concrete answer, I created a simple test page with the following:<button type="button"><i class="fa fa-heart"></i> Favorite 1</button>
<button type="button"><span class="fa fa-heart"></span> Favorite 2</button>First, I scanned the page with Microsoft’s Accessibility Insights plugin. This is the plugin that Microsoft uses to ensure they’re meeting their contractual obligations for accessibility in their Web products. The FastPass result, which will highlight many accessibility issues ranging from contrast problems to missing/invalid aria attributes, had zero concerns with this markup (see attached image #1).
I then turned on VoiceOver and navigated to both elements — which also gave my test page a pass.
Then I inspected the accessibility tree in Chrome. This shows the exact information that assistive devices use to navigate a webpage in, for example, a screen reader. Again, they are identical (see the below attached image; focused: true is because the second button was focused when I took the snapshot).
Lastly, I compared the following HTML in VoiceOver:
<p>The dog ran <i>fast</i> to the park.</p>
<p>The dog ran <em>fast</em> to the park.</p>
<p>The dog ran <span>fast</span> to the park.</p>Again, they announce exactly the same. Even with <em>, the screen reader says, “the dog ran fast to the park” with no change in inflection for the word “fast.” This page from Siteimprove explains why.
In most cases, tags and markup code used to emphasize text get ignored by screen reader software with the default settings.
You may have noticed a [?] symbol in attached images #2 and #3. This is the only potential accessibility concern because Font Awesome maps Unicode characters to symbols in the font, like all icon fonts. In this case, the character is unknown and thus ignored. This is fine as long as all icons are in the extended/unknown range. However, if they mapped to something like an emoji or another recognizable character, that character would be announced unexpectedly.
Caveats — with respect to the web standards purists.
Jump to section titled: Caveats — with respect to the web standards purists.Screen readers often behave in weird, inconsistent ways depending on your OS, browser type, and browser version. NVDA, for example, has an open issue about Font Awesome icons + aria-label.
Some screen readers might announce unknown characters, but this will affect all elements, so it’s a moot point in terms of <i> vs. <span>.
This assessment may not ring true in the hearts of Web Standards purists because we’re using the <i> element against spec. While I appreciate Web Standards, I prefer function and convenience over dogmatic principles. In the same way that misusing language can reshape the meaning of words, using <i> for icons has somewhat redefined its purpose and has become an acceptable use, As long as there are no valid accessibility hurdles.
Users may not take the time to read through or understand the many counterpoints. If their tool erroneously states that <i> is an accessibility violation and they just want it to work, it’s absolutely fine to use <span> as a more comfortable equivalent.
Font Awesome makes auto accessibility easier!
Jump to section titled: Font Awesome makes auto accessibility easier!The easiest way to support accessible icons is by using the Auto-Accessibility feature included in Font Awesome’s web software.
