Making iconography accessible through after and before pseudo-elements

A few years ago we talked in an article about the accessibility of CSS-generated content using before and after pseudo-elements. This technique, even after so many years, is still used relatively frequently due to the existence of iconography in the style of Font Awesome or similar, so it is interesting to know what could be the alternatives to make this content accessible.

We will use this service as an example since it is one of the most common, in addition to the fact that it provides information on accessibility in Font Awesome, which speaks very well in its favor, but this could be applied to any similar system, even a corporate iconography that is implemented using this same technique.

There are several methods of adding Font Awesome iconography to a web page. One of them can be directly using CSS pseudo-elements, however, the most practical thing is to use the classes already provided directly through HTML <span> or <i> tags, which already handle the pseudo-elements behind.

Adding an icon

The syntax to add an icon is normally the following:

<i class="fa-solid fa-user"></i>

Although it should be used, as previously stated, using the <span> tag, since the <i> tag has a semantic meaning that is not applicable in this case:

<span class="fa-solid fa-user"></span>

An icon added in either of the above two ways will not be detected by assistive technologies as a screen reader, and even depending on which screen reader is used, the icon will be detected as an unknown character.

Decorative iconography 

The first thing to determine to know what accessibility solution will be given to the icon is if it fulfills a merely decorative function, or is indicating some action to be carried out or providing some information.

Basically and functionally, we could determine that an icon is decorative when:

• It does not convey any additional information to that conveyed by its context
• It has no action assigned to it when pressed with the keyboard or the mouse.
• In case of performing an action when pressed, it is accompanied by a text that describes it, for example, forming part of a button or textual link.

If these conditions are met, the element should be marked as decorative, and for this the Font Awesome accessibility recommendation can be used, which is through the aria-hidden attribute.

<span class="fa-solid fa-user" aria-hidden=”true”></span>

The most current versions of this library already do this by default, but it is better to make sure of this by applying it expressly.

Although the use of role=”presentation” or role=”none is recommended on some pages, this technique does not prevent the icon from being detected as an unknown character by some screen readers, so we do not recommend it.

Informative or action iconography

In the event that the image does not meet the above characteristics, it means that it is either transmitting some additional information to its context, or performs some action when clicked by itself.

Some examples of this case would be:

• An image of a star that accompanies some elements of a list, to indicate that they are favorites, although it is not interactive by itself.
• An icon of a magnifying glass inside a button, link or any other element, that when clicked performs a search action, and that is not accompanied by any text that describes it.

For these cases, some of the following techniques can be used

Image Role 

This technique consists of making use of the image aria role, in addition to the title attribute, in order to provide an accessible tag, accompanied by a visible tooltip. An example could be the following:

<span class="fa-solid fa-user" role=”img” title=”User”></span>

In this case, the alt attribute should not be used, since it is only typical of native images, and is not detected as a standard by all browsers and screen readers when used in a non-native element.

Using Aria Tagging Attributes

According to aria-24 technique of WCAG 2.1, the aria-label and aria-labelledby attributes can also be used.

<span class="fa-solid fa-user" aria-label=”User”></span>

In this case, just keep in mind that the aria-label attribute does not provide a visible label, which is not essential yet, it provides a better user experience, while the aria-labelledby attribute does, in which case it only care must be taken that the information is not redundant.

Accessibility tags hidden by CSS

This other technique consists of hiding the icon from accessibility using the aria-hidden attribute, but accompanying it with an element hidden from view by CSS that transmits the same information in an accessible way.

The element that transmits the information can be hidden from view, but not from accessibility, so the display rule should never be used: 'none'; CSS, but rules like those included in Bootstrap 5's visually-hidden class should be used.

<span class="fa-solid fa-user" aria-hidden="true"></span>
<span class="visually-hidden">User</span>
If Bootstrap is not being used, the class can be added to the CSS:

.visually-hidden,
.visually-hidden-focusable:not(:focus):not(:focus-within) {
  position: absolute !important;
  width: 1px !important;
  height: 1px !important;
  padding: 0 !important;
  margin: -1px !important;
  overflow: hidden !important;
  clip: rect(0, 0, 0, 0) !important;
  white-space: nowrap !important;
  border: 0 !important;
}

Keyboard Role and Focus

It is not a good practice to assign events directly to <span> or <i> elements that display an icon, as they themselves are not capable of taking keyboard focus, so they also do not provide visible focus, and they do not have an interactive role such as buttons or native links.

The recommendation will always be to use these icons within an element that already provides the necessary accessibility apis for keyboard and focus, such as native HTML links or buttons.

However, if they are used without any of these elements, the ability to be focused using the keyboard using the tabindex attribute must also be added, a role that allows identifying that they can be interacted with through the role attribute, in addition to designing a focus visible with any of the techniques recommended by WCAG criterion 2.4.7.

Conclusion

The use of content through pseudo-elements after and before is not recommended since some users may need to overwrite the CSS rules with custom ones that better meet their needs, in addition to the fact that users of screen readers will not perceive these contents properly.

However, these recommendations can be used to provide some accessibility alternatives to these elements.

• Be sure to mark as decorative those elements or icons that are.
• Provide accessible and visible alternative texts to those icons that require it.
• Make sure that those icons that require user interaction can also be accessed by keyboard, have a certain role, in addition to providing adequate visible focus.

Finally, emphasize that classes have been used in the suggestions presented in this article, since if the pseudo-elements are established directly using other types of CSS selectors such as the ID itself, it becomes more complex then to locate the HTML elements to those elements. that accessibility features should be added.

If this content has been useful, do not forget to share it on social networks.

 

Ernesto Blanco