Font-awesome: False positive accessibility error on Site Improve

[brian909]

Hello, We just started using fontawesome 5 'SVG with JS' at our org and we noticed that our accessibility checker, Site Improve, is flagging all fontawesome svgs as an error.

We are just using the icons as decorative.
<i class="fas fa-tty"></i>

Should decorative icons be role='presentation' instead?

Below is a screenshot of the error.

WAI-ARIA image is missing alternative text
1.1.1 Non-text Content
The WAI-ARIA image, created with role="img", does not have an accessible name.

[gtibrett]

SVG with JS adds aria-hidden="true" which sufficiently indicates to assistive technologies that the element is decorative and can be ignored. Our testing tool does not flag FA SVGs as violations of 1.1.1

[DM2489]

Yeah, this is a strange one that I've just come across. Seems like a bug with the Site Improve tool, I'm going to try and report it to them.

[tagliala]

@DM2489 please let us know

[DM2489]

@tagliala Unfortunately, despite trying, I've been unable to find a way to report this to SiteImprove :(

[karento]

It looks to me like Siteimprove has addressed this. We are Siteimprove customers and our dashboard was previously flagging this error but isn't anymore.

[tagliala]

@karento glad to know

Closing here

[brysonca]

This is still being picked up SiteImprove for me. Wouldn't it make since to change role='img' to role='presentation' when the icon can be bypassed by screenreaders? Having aria-hidden="true" & role='img' is probably confusing screen readers & siteimprove. Removing the role='img' or replacing with role='presentation' should help. Would this cause in additional issues?

aria-hidden="true" - basically says display:none; to screen readers
role='img' - says treat me link an IMG tag
role='presentation' - says forget about my semantic meaning (you’d use it when it doesn’t make sense for an image to have alternative text so it can be removed from the tree) https://timwright.org/blog/2016/11/19/difference-rolepresentation-aria-hiddentrue/

[DM2489]

@brysonca Yeah, I've been in touch with SiteImprove, trying to get them to fix it but thing's aren't really getting anywhere.

[DM2489]

@tagliala @brian909 @brysonca Just heard back from SiteImprove - they recognise this is a bug but will not fix it in the current version of the tool. They say they will fix it in a future release, that could come any time in the first 6 months of 2019.

[tagliala]

@DM2489 thanks for the heads-up

[arunvisvajeetrs]

@tagliala Our company is also using siteimprove and we have the exact same issue, is it possible to override the auto-accessibility of fontawesome to role="presentation" instead of role="img"?

[tagliala]

@arunvisvajeetrs sorry, I'm not an accessibility expert

Please take a look at this comment: https://github.com/FortAwesome/Font-Awesome/issues/12492#issuecomment-448146160

[anevaude]

@karento @DM2489 - Well, it's April 2020 and I landed here because I had the same issue with SiteImprove's Chrome tool. SiteImprove has not fixed this issue regarding FontAwesome and WAI-ARIA.

[kasperisager]

A colleague of mine sent this issue my way and I'd love to provide some background and hopefully some insights into the current situation. For reference, I work at Siteimprove as the product owner for Alfa, our open source accessibility engine which is in the process of replacing our proprietary engine currently in use.

The crux of the matter is really a question of architecture. While I can appreciate that this issue seems like it would be easy to fix–why can't we simply ignore things with aria-hidden="true" or role="presentation"?–the way things work in practice are much more complex than they may seem. Semantic roles, of which img is one, are a property defined for nodes in the accessibility tree. The accessibility tree is essentially a structure parallel to, and constructed based on, the DOM and is what assistive technologies, such as screen readers, rely on for navigation. Semantic roles are one property defined for nodes in this tree; names and descriptions are two other, and important, properties.

Here's where things get tricky: There are _a lot_ of rules, and exceptions to those rules, on what, when, and how various types of content are included in the accessibility tree, as specified by the Core AAM. For example, elements with aria-hidden="true" _should not_ be included in the accessibility tree, as per this issue, but there are exceptions to that rule. The same applies to role="presentation"; only under specific conditions are elements allowed to be included in the accessibility tree with a presentational role. All this to say that ignoring things with aria-hidden="true" or role="presentation" isn't as simple as it would seem. The best solution would of course be to actually consult the accessibility tree rather than try to infer these things ad-hoc from the DOM. Unfortunately, there aren't _yet_ stable browser APIs available for inspecting the accessibility tree and so we're really out of luck unless we want to go to the lengths of building an accessibility tree of our own.

That's where Alfa comes in as it does precisely that! That is, Alfa builds an accessibility tree of its own that it uses for these kinds of queries. However, in order to do so Alfa relies on a ton of other architectural decisions that are fundamentally different from how our proprietary engine operates. That's the reason why it has been communicated that this won't be fixed in the current engine; it simply isn't feasible to do so.

I know it's a pain having to deal with false positives like this and I promise you that we're hard at work on rolling out Alfa across our various products, starting with the Siteimprove platform and from there continuing on to the Siteimprove checker for Chrome. I don't have any forecasts on when the latter will be finished, though I do hope that it's sooner rather than later.

I hope this helps clarify some things and let me know if you have any other questions on the matter!

[tagliala]

Hi @kasperisager, thanks for the thorough explanation!

[tagliala]

@kasperisager hi, I have another question and I hope you could help

The following snippet can be found under our Accessibility Docs:

<svg class="svg-inline--fa fa-camera-retro fa-w-16" aria-hidden="true" data-fa-i2svg="" data-prefix="fas" data-icon="camera-retro" role="img" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512">
  <path fill="currentColor" d="M48 32C21.5 32 0 53.5 0 80v352c0 26.5 21.5 48 48 48h416c26.5 0 48-21.5 48-48V80c0-26.5-21.5-48-48-48H48zm0 32h106c3.3 0 6 2.7 6 6v20c0 3.3-2.7 6-6 6H38c-3.3 0-6-2.7-6-6V80c0-8.8 7.2-16 16-16zm426 96H38c-3.3 0-6-2.7-6-6v-36c0-3.3 2.7-6 6-6h138l30.2-45.3c1.1-1.7 3-2.7 5-2.7H464c8.8 0 16 7.2 16 16v74c0 3.3-2.7 6-6 6zM256 424c-66.2 0-120-53.8-120-120s53.8-120 120-120 120 53.8 120 120-53.8 120-120 120zm0-208c-48.5 0-88 39.5-88 88s39.5 88 88 88 88-39.5 88-88-39.5-88-88-88zm-48 104c-8.8 0-16-7.2-16-16 0-35.3 28.7-64 64-64 8.8 0 16 7.2 16 16s-7.2 16-16 16c-17.6 0-32 14.4-32 32 0 8.8-7.2 16-16 16z"></path>
</svg>

It has both role="img" and aria-hidden="true", and apparently is getting flagged by SiteImprove.

Is this another example of false positive?

[kasperisager]

That's indeed the same issue, yes.

[tagliala]

@kasperisager thanks for the clarification and for the quick reply, really appreciate