Accessibility issue with HTML icon: "i" tag used to format text

[pat-kavanagh]

Hello Font-Awesome,

On each Font Awesome icon page, it shows an HTML example of how to use the icon. For example, <i class="fa fa-plus"></i>

The current implementation of using the <i> tag does not meet accessibility standards as shown from the Siteimprove page scan attached and should be resolved immediately. If we used a <span> tag or another similar inline element it would be much more accessible. This is the greatest icon resource available online and it would be great to see it move in a more WCAG compliant direction.

Thank you!

[tagliala]

Hi!

Thanks for being part of the Font Awesome Community.

If we used a tag or another similar inline element it would be much more accessible.

I personally agree with you, but I should point out that the first page and first paragraph of our documentation clearly states that <i> should not be used.

Quote:

Font Awesome is designed to be used with inline elements, and we recommend sticking with a consistent HTML element to reference them by in your project. We like the <i> tag for brevity and because most folks use <em></em> for emphasized/italicized semantic text these days. If that’s not your cup of tea, using a <span> is more semantically correct.

Emphasis mine

Ref: https://fontawesome.com/how-to-use/on-the-web/referencing-icons/basic-use

Hope it helps

Closing here

[pat-kavanagh]

I would like to reopen this issue as it has not been resolved.

As you pointed out, the documentation says that the <i> tag should not be used so I find it concerning that FA is not following their own directions. Brevity, in my opinion, should be the lowest factor in making decisions for code especially as there are companies who are getting lawsuits filed against them for not following WCAG compliance.

• https://www.essentialaccessibility.com/blog/web-accessibility-lawsuits/
• https://www.cnbc.com/2019/10/07/dominos-supreme-court.html

By choosing brevity, we are saying that the following are not important and don't need to be followed:

• Font Awesome documentation
• HTML semantics
• WCAG compliance

Edit: This is the location of the <i> tag that I'd like to see replaced with a <span> or another inline element that adheres to WCAG compliance.

Please advise, thank you.

[tagliala]

@robmadole @talbs any second thoughts on this?

I've always been in favor of <span> in documentation

[robmadole]

@pat-kavanagh I appreciate you posting.

Here are my thoughts:

While I think that a <span> is more accessible we have to take into consideration the long history of using the <i> tag. It's been around since version 1 of Font Awesome and for individuals using existing tools, plugins, older versions, this would be a very difficult transition.

My question is if "bad practice" translates to the <i> tag being inaccessible or violating the WCAG standard. We outline our accessibility practices here: https://fontawesome.com/how-to-use/on-the-web/other-topics/accessibility. As far as we know (and we've worked with industry experts to get this as correct as we can) using the <i> tag is accessible when properly following the guidelines we document.

One thing we might consider is updating the accessibility page to mention that using a <span> is more semantically correct. Would this help?

[pat-kavanagh]

Hey Rob,

Thanks for the response.

I totally understand your concern about legacy code. It can definitely become an issue when it comes to adding new features, but I would consider WCAG support exactly that. A new feature. For a company like Font Awesome that is continually adding great new features, I have full faith in your team's ability to increase WCAG support!

Also, in looking at a version of Font Awesome 1, there are actually no references to an <i> tag. So I would love to know what concerns about legacy code around the <i> tag there are? (Please let me know if I am looking at an incorrect version) https://cdnjs.cloudflare.com/ajax/libs/font-awesome/1.0.0/css/font-awesome.css

While the documentation discusses using span tags as @tagliala quoted above, if we're going to be honest, developers don't typically take the time to read through all of a library's docs. They would trust that the information provided by a library, like Font Awesome, in its examples would be following its own semantic documentation.

For the discussion around the <i> tag usage, I found this great StackExchange post that discusses the usage of <i> and <b> vs the <em> and <strong> tags. While the <i> tag does still hold semantic meaning in HTML5, it is designed for italic text. If we use the <i> tag for an icon, it may create confusion for users with screen readers.

In doing some research on other icon libraries, Bootstrap changed their approach from using the <i> tag in v2 to using <span> tags in v3 https://getbootstrap.com/2.3.2/base-css.html#icons https://getbootstrap.com/docs/3.4/components/

If we need to continue legacy support for the <i> tag, the layout could change to show the legacy approach vs the updated approach. I took a quick take on what something like that could look like:

I appreciate your time on this matter, please let me know your thoughts. Thank you!

[tagliala]

Hi @pat-kavanagh

Also, in looking at a version of Font Awesome 1, there are actually no references to an <i> tag. So I would love to know what concerns about legacy code around the <i> tag there are? (Please let me know if I am looking at an incorrect version)

Font Awesome was born as a replacement of glyphicons for Bootstrap

You can see the use of <i> here: https://getbootstrap.com/2.0.0/base-css.html#icons

That's why Font Awesome used <i>

About span and accessibility, correct me if I'm wrong: turning <i> into <span> does not solve accessibility issues. You can still have buttons with just a semantic icon inside, or a decorative icon without the aria-hidden attribute.

Another question: does the tool in the first post show an issue for <i> elements with aria-hidden="true" attribute?

[kdmarks]

Agree. Automated accessibility checkers (like Wave, Siteimprove, etc.) mark every instance of <i> elements as a compliance issue with WCAG 1.3.1 Info and Relationships Level A as a result of not separating presentation from content. As popular and widespread a tool as FontAwesome should advocate the most accessible coding practices.

[pat-kavanagh]

Hi @tagliala,

That is great to know about the origins of Font Awesome, I was unaware! If Bootstrap glyphicons were the inspiration of Font Awesome and the reason the <i> tag was chosen, shouldn't Bootstrap's update to use the <span> tag instead of <i> in version 3 of glyphicons be all the more reason for Font Awesome to follow suit?

In doing some research on other icon libraries, Bootstrap changed their approach from using the <i> tag in v2 to using <span> tags in v3 https://getbootstrap.com/2.3.2/base-css.html#icons https://getbootstrap.com/docs/3.4/components/

If we can change the <i> to a <span>, it won't necessarily solve all the issues with accessibility. As @kdmarks noted, it will help resolve the issue of "separating presentation from content." It is a step in the right direction as we should be "advocate the most accessible coding practices."

i tag + aria-hidden='true' I just tried using aria-hidden="true" along with an <i> tag for a Siteimprove page scan and the issue is still present. While looking at the other icon below with the <span> tag, there are no issues flagged. Also, as you can see in the screenshot below, Siteimprove directly calls out the issue of using an <i> tag for icons as a bad practice.

@kdmarks, I see from your LinkedIn that you are an accessibility specialist. I would love to hear more of your thoughts on this issue if I am missing anything!

Thank you for the ongoing discussion!

[robmadole]

Ok. I'll get with @davegandy and @supercodepoet on this and we'll see if this is something version 6 needs to address. Thanks everyone for the great information. That will help a great deal as we discuss.

[pat-kavanagh]

Thank you @robmadole & @tagliala!

Please let me know if there's anything else I can do to help, I appreciate your consideration on this issue!

[OssiPesonen]

tl;dr

SonarCloud reports this as an issue also. The solution is to add aria-hidden="true" attribute for semantic purposes.

The <strong>/<b> and <em>/<i> tags have exactly the same effect in most web browsers, but there is a fundamental difference between them: <strong> and <em> have a semantic meaning whereas <b> and <i> only convey styling information like CSS.

Exceptions
This rule is relaxed in case of icon fonts usage.

<i class="..." aria-hidden="true" />    <!-- Compliant icon fonts usage -->

We noticed this and fixed it ourselves, but would be beneficial to add it to the documentation.

[robmadole]

@pat-kavanagh I am unable to reproduce this error with Siteimprove's Chrome extension or through their site. Can you provide reproduction steps please?

[pat-kavanagh]

@robmadole Steps to reproduce:

1. Navigate to an icon detail page: https://fontawesome.com/v5.15/icons/universal-access?style=solid
2. Enable the Siteimprove Chrome Extension
3. Scroll down the issues list to find the "Adaptable" section - issue type "1.3.1 Info and Relationships"
4. Click that issue to open the accordion. The accordion content will display all errors and warnings that violate that compliance piece, including: "'i' tag being used to format text"

[robmadole]

Are your results different than this? I'm using v2.0 of the extension.

[robmadole]

And here is SonarCloud's rule which as @OssiPesonen mentioned is relaxed if aria-hidden=true is applied.