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 is often integrated with the
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:
CSS is activated, only the Twitter icon is visible
CSS is disabled, the text of the icon appears
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).
Another technique is to use the
The advantages of this technique are:
- It is easier to add than a hidden text via
- 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-labelis part of the translatable elements by tools like Google Translate, but it is still poorly supported.
Example of use:
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
This alternative should therefore be used to link an element to on-screen text.
For example, on a modal window:
or on a graphic element, here a red dot indicating a delay in payment:
You can link several texts to an element.
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.
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:
Its advantages are:
- Simplicity to add (more than
- 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.
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.
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 :
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
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
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 :)