Accessible font icons

[zwiastunsw]

We use icon fonts in many places. In this post I propose the consistent use of three patterns of embedding the font icons to ensure their accessibility.

There are basically two types of icon fonts:

• stand-alone icons that convey meaning, semantic icons
• decorative icons illustrating the accompanying words.

Decorative icon

Decorative icons express the same meaning as the accompanying words. We use them to visually enhance the meaning of the illustrated words. If we remove them from the page, users will still fully understand the content and will be able to use the page. Such icons do not have to be announced to users of screen readers. We should hide them from screen readers.
To hide the icon font from screen readers, we use the aria-hidden="true" attribute. Add it to the tag with the icon font.

For example:

<span class="icon-*" aria-hidden="true"></span>

Stand-alone icon

Stand-alone (semantic) icons convey meaning by themselves. They cannot be removed from the page without losing meaning or functionality. Since some users may not see the graphic symbols, we should pass their content in an alternative text. This is an elementary accessibility requirement specified in WCAG 2.1 by success criterion 1.1.1.
Stand-alone icons can be interactive elements, e.g. buttons, switches, links and "normal", non-interactive content elements.

Non-interactive icons

If the icon is not an interactive element:

• hide the icon from the screen readers using the aria-hidden="true" attribute,
• provide a label for sighted users of the mouse using title attribute,
• provide alternative text visible only to screen readers using sr-only class.

For example:

<span class="icon-*" aria-hidden="true"  title="Meaning of the icon"></span>
<span class="sr-only">Meaning of the icon</span>

Interactive icons

If the icon is an interactive element:

• provide the accessible icon name to the screen readers using the aria-label="ActionName" attribute.
• hide the icon from the screen readers using the aria-hidden="true" attribute.
• provide a label for sighted users of the mouse using title attribute,

Note that in this case you do not have to create a hidden element with alternative text only for screen readers.

For example:

<button class="icon-btn" aria-label="Action" onclick="action">
   <span class="icon-*" aria-hidden="true" title="Action"></span>
</button>

<a href="location" aria-label="Location name">`
 <span class="icon-*" aria-hidden="true" title="Location name"></span>
</a>

Note that the title attribute with label is added to the tag with the icon hidden from the screen readers, as opposed to the aria-label attribute. As a result, screen readers do not repeat the label twice.

Digression

In the discussion on PR Make ActionButton Featured accessible #23718 I withdrew from the suggestion to add a title attribute to provide an accessible name for sighted users.

The PR author's argument that the meaning of the icon would be understandable from the context (column name) seemed convincing.
After thinking about it, I have to say that it was a wrong decision.

The title attribute is necessary (or any other way of providing alternative text for sighted users). Otherwise, the meaning of the icon may be incomprehensible to some users. No alternative text violates the Success Criterion 1.1.1 Non-text Content:

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.
Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose.

Note: The problem can be solved using tooltips: https://codepen.io/dgrammatiko/pen/eGELjo

See:

• Font Awesome & Accessibility. Make your icons awesome for all of your users

About title attribute see:

• The Trials and Tribulations of the Title Attribute
• Don't Rely on the Title Attribute for Accessibility

[HarshCic]

Can I solve this @zwiastunsw

[zwiastunsw]

@HarshCic : You don't need a permission to do it. We are happy to help you. Prepare and report PR

[brianteeman]

I still dont agree with you that an icon needs to have a title for sighted users to understand the meaning of the icon. To me that just stinks of bad design if a sighted user cannot understand what the icon means from its shape and context

[zwiastunsw]

Dozens of icons and even hundreds can be used as buttons. Do you really think that everyone will always understand them the same way?

[chmst]

I think that there are icons which are so common use that we do not need a title attribute.
Or that, as for example, a table header gives the meaning for sighted users in the backend. If we assume that administrators know what they are doing, it is ugly and enerving to see everywhere the title.
In the frontend this might be more restrictive.

[zwiastunsw]

It is difficult to discuss with convictions. You have the right to think this way.
WCAG says clearly - provide a text alternative for every non-text content:
See:

• 1.1.1 Non-text Content (Level A)
• Understanding Success Criterion 1.1.1: Non-text Content

So let's agree that the WCAG requirements defined by the success criteria will simply be applied.
There is no discussion as to whether we should apply them. Let's look for a way to apply them.