HTML & CSS Code Style: accessible icon themes

Development
#1

Hello!
A few years ago an idea of a code style practice has been written down (but never validated and/or respected) here.

The initial idea was:

Icon fonts must have a role=“img” attribute.
For example:
xwiki.iconset.render.wiki = <span class=“fa fa-$icon” role=“img”></span>

I’m proposing thereafter a revised version of this code style practice:

Icon themes must have an <img> nature and an alternative text.
For example:
xwiki.iconset.render.wiki = <img class=“fa fa-$icon” alt="$icon"></img>

Here are the points covered by this code style rule:

  • (the initial point) use semantic HTML instead of non semantic HTML. This is a good practice that’s particularly useful when asserting accessibility.
    Sources:
  • Icon fonts should always use semantic HTML to display their images. The role=img could do the same thing as an img HTML nature, however support is wider for the HTML balise.

If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible**, then do so**.

From aria specs

  • Images should be labelled:

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. (Level A)

From the Web Content Accessibility Guidelines (WCAG) 2.1

What do you think about using this rule for icon themes from now on?
I’m looking forward to your feedback about a rule that would make sure icon themes are accessible.

#2

I’ve just tried this and it just doesn’t work, the icon isn’t displayed. This is because font awesome uses a :before pseudo-element to display the icon, which doesn’t work on images. So while it sounds like a good idea, it doesn’t work, so -1 from me.

#3

It seems like there’s no clean solution for accessibility of font-awesome. On their a11y page they use extensive aria-markup to get better semantics, so even their recommendations don’t pass the rule above.

However, I found a wcag failure example from official doc that pretty much invalidated the solution proposed by FA on their accessibility page. Their solution is definitely better than nothing but it’s not perfectly WCAG compliant.

The CSS ::before and ::after pseudo-elements specify the location of content before and after an element’s document tree content. The content property, in conjunction with these pseudo-elements, specifies what is inserted. For users who need to customize style information in order to view content according to their needs, they may not be able to access the information that is inserted using CSS. Therefore, it is a failure to use these properties to insert non-decorative content.

From Failure of Success Criterion 1.3.1 due to inserting non-decorative content by using ::before and ::after pseudo-elements and the ‘content’ property in CSS

Unfortunately, there is no way to keep the third point mentioned in the opening message without also changing icon theme.
Here is an updated proposition for the code style:

Icon themes must have a role=“img” attribute and an alternative text.
For example:
xwiki.iconset.render.wiki = <span role=“img” class=“fa fa-$icon” alt="$text"> </span>

Note: The alternative text can be empty if the icon is not semantically relevant or already labelled by a text element next to it.

#4

This is not valid XWiki syntax, you cannot use HTML in place of XWiki syntax. Also, the span element doesn’t support the alt attribute.

I’m not sure if it makes sense to support alternative texts in icons or if we shouldn’t just say that icons are always decorative elements and an alternative text must be provided elsewhere, e.g., as an aria-label on the link that wraps the icon.

#5

Here is a revised version of the proposal:

Icon themes must have a role=“img” attribute and an alternative text.
**For example:
xwiki.iconset.render.wiki = {{html clean=“false”}}<span role=“img” class=“fa fa-$icon” aria-label="$text"> </span>{{/html}}

Note: The title attribute does not have perfect support on a11y technologies, and we don’t need a tooltip on all icons so using aria-label here must be better.

If we need to add an alternative text to icons systematically, I think we need to make it a best-practice too. Something like this:

Icon wrappers must have an accessible name describing the meaning of the icon. Accessible names can be be provided in multiple ways :

  • using a HTML <label> element with a for attribute which targets the icon when the label is a part of the interface
  • set an inner content between tags for wrappers of nature <a> , <button> and <td>
  • using an ARIA aria-label or aria-labelled attribute on the wrapper
  • using a HTML title attribute on the wrapper

See W3C practices on accessible names.

I thought having a best practice for the icon theme itself would be seen less frequently so it can be easier to apply (only when there’s a new icon theme instead of for every other icon). The practice for the icon theme would also be simpler to understand and faster to apply. The way to convey the semantics of the icon depends on the context (as seen above) and I think conveying it directly from the icon element would make more sense than systematically using a wrapper.

#6

Hello! Trying to use icons in the best way possible and so I got here.

Did we reach a conclusion on this? Should we always use the following format for icons?

<span role=“img” class=“fa fa-icon” aria-label="Text"> </span>

  • Text = a string that labels the interactive element on which it is set

If it helps in any way, the context in which I’m asking is: adding icons for the docExtra tabs.

Would it be better in this specific case to use aria-hidden=“true” because these icons could be considered decorative because they already have the text explaining them shown?

#7

You should always use the HTML or wiki syntax that is provided by the icon script service as it respects the current icon theme. Please don’t write custom HTML for icons.

1 Like
#8

Oki, oki, so I’d have to stick with what Font Awesome suggested to use which is:

<i class="fa fa-comment" aria-hidden="true"></i>

Thanks!

#9

No. Please do not write any custom HTML for icons. Use the icon script service to get the HTML for the icon. The HTML to use is provided by the icon theme. Thank you!