You are here

Accessible names in all their states

When developing an interface in an accessible way, we must think about filling in relevant accessible names.

In addition to images with the alt attribute and form fields with label tags, elements that need it are links/buttons with icons (magnifying glass to launch a search, social network icons), buttons with short names like Send, Continue, etc.

There are several ways to add meaning to these elements.

In this article, I will list some of them, give their advantages, disadvantages and compatibility with screen readers.

What is an accessible name?

An accessible name is a text rendered by an assistive technology, for example, a screen reader. It can be the label of a field, the alt attribute of an image, the text of a button and many others. Let’s start with the first method.

Invisible text

Invisible text is often integrated with the sr-only or visually-hidden CSS class. The particularity of this CSS class is that the text is invisible on screen, but remains readable by screen readers. Here, we do not use display: none;; or visibility: hidden; because this would make the text impossible to read by a screen reader.

I invite you to read Gaël Poupard’s article (in French) to see the anatomy of this class in detail.

Advantages of invisible text:

Particularly robust, it has excellent (backward) compatibility with assistive technologies
If CSS is disabled, invisible text is displayed
A user using custom styles can choose to display the hidden text
It can be translated via online translation tools (such as Google Translate)

Disadvantage: This method requires more code than adding an ARIA or a title attribute, which is not always easy depending on the development.

Example of use:

<a href="https://twitter.com/24joursdeweb" class="twitter">
    <span class="sr-only">24 jours de web sur Twitter</span>
</a>

CSS is activated, only the Facebook icon is visible

CSS is disabled, the text of the icon appears: Terra potager sur Facebook

I recommend this technique because it offers the best compatibility.

Make sure you only apply this class to hidden text. Indeed, if it is added on an element positioned in absolute, there may be surprises (in French).

Aria-label

Another technique is to use the aria-label attribute.
The advantages of this technique are:

It is easier to add than a hidden text via sr-only or visually-hidden.
It has a very good support from screen readers

But has the following disadvantages:

Breaks the first ARIA rule
Has a little impact on SEO
aria-label is part of the translatable elements by tools like Google Translate, but it is still poorly supported.

Example of use:

<button aria-label="Add to cart Final Fantasy 7 Remake">
    Add to cart
</button>

Important note: a new WCAG criterion, 2.5.3 - Label in name, specifies that if an interface element (link, button, etc.) contains text or a text image, the accessible name must contain that text. Thus, the aria-label above must contain the words Add to cart.

This criterion allows users of speech recognition software to indicate on which button to click.

In the example above, we can imagine that there are several Add to Cart buttons and their aria-label allows to distinguish which one we want to click on.

Aria-labelledby / aria-describedby

The ARIA specification states that if the label text is visible on screen, authors SHOULD use aria-labelledby and SHOULD NOT use aria-label.

This alternative should therefore be used to link an element to on-screen text.

For example, on a modal window:

<dialog role="dialog" aria-labelledby="modalTitle">
    <h1 id="modalTitle">Modal title</h1>
    ...
</dialog>

or on a graphic element, here a red dot indicating a delay in payment:

User dashboard. The active tab is My Account. A red dot next to the label indicates that there is an overdue payment.

<button id="myAccount" aria-describedby="accountLabel dotTitle">
    <span id="accountLabel">My account</span>
</button>
    
<h2 id="dotTitle" class="error">Overdue payment</h2>

You can link several texts to an element. aria-labelledby (like aria-describedby), takes a list of identifiers as values.

The above example will be returned in order of calling identifiers; here, My account overdue payment.

Note that aria-labelledby can be accompanied by aria-describedby to give a more extensive explanation than a title.

We can also find it on SVG icons:

<svg role="img" aria-labelledby="fb" version="1.1" 
        xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" 
        x="0px" y="0px" viewBox="0 0 48 48" xml:space="preserve">
    <title id="fb">Facebook</title>
        ...
</svg>

Its advantages are:

Simplicity to add (more than .sr-only text)
This technique is well supported by assistive technologies
Text references (identifiers) can be placed anywhere in the page
Since identifiers point to visible text, translation is possible via online translation tools.

If we can speak about disadvantage, it is the attribute which has the highest priority in the calculation of the accessible name. It is necessary to test its restitution to avoid errors.

Title

The main advantage of the title attribute is that it displays additional information on mouseover. Thus, someone navigating with the mouse can have this information if they need it.
It can also be translated via online translation tools.

<button id="showPassword">
    <span title="Show password">
        <svg role="img" aria-label="Show password">
            <use xlink:href="#show-password"></use>
        </svg>
    </span>
</button>

The title is placed on a child container without semantics to avoid double restitution.

On the other hand, this technique has many disadvantages:

The information is invisible when browsing with the keyboard or on a cell phone
It is not or only slightly visible to screen magnifiers users
Compatibility with assistive technologies is limited
It does not impact SEO (in French)

It’s better to use title sparingly and with a more accessible alternative such as aria-label or hidden text.

Order of restitution by screen readers

I have mentioned several times a notion of priority or accessible name calculation.

Indeed, browsers make a calculation to know what is the accessible name of an element. So you have to be careful about using the different techniques I just listed.

To summarize the calculation method, aria-labelledby has priority over aria-label, which itself has priority over text inserted in an element.

For example :

<button class="error-dot" aria-labelledby="dotTitle" aria-label="Warning"> my button </button>

<h2 id="dotTitle" class="error">Overdue payment</h2>

Here, aria-labelledby is present, the result returned will be overdue payment.

In the following example, the text Continue will be completely ignored, in favor of Continue to payment step

<button aria-label="Continue to payment step">
    Continue
</button>

Conclusion

The first rule of ARIA is to not use ARIA and to favor native elements.

Indeed, HTML is a rich language and ARIA should only be used as a last resort.
Its support is not the same depending on the element on which it is used.

Therefore, if you really need to use one of these techniques, I recommend the hidden text technique for the majority of cases and to respect the semantics; for example, to use real label for form fields and to use the alt attribute of the img tag.

Even better, during the UX and/or design phase, check if it is possible to integrate the texts directly in a visible way. This will always be the best solution.

To go further:

Compatibility of screen readers with ARIA attributes

Thanks to Romain Gervois for his kind review and good advices as well as to Nicolas Hoffmann and the proofreaders :)

You can find this article and many other very interesting articles on 24 jours de web (in french only)