Robust: your website also works with assistive technology

What it is

Robust is the fourth principle of WCAG. Your website must work in different browsers, on different devices and with assistive technology, now and also when that technology changes.

Assistive technology is software or equipment that helps people with a disability use the web. Examples are a screen reader that reads the page aloud, a screen magnifier, speech recognition, and a switch for people who cannot use a keyboard and mouse.

The principle has one guideline: Compatible (4.1). Under it, WCAG 2.2 has only two success criteria at level A and AA, requirements you can test a website against: 4.1.2 and 4.1.3. This principle is about code. You do not have to write it yourself, but you can ask your web developer or supplier about it.

Why it matters

Assistive technology only works well if the code is right. A button that looks like a button can be plain text to a screen reader, and then someone who is blind does not know there is something to choose. So a client gets stuck when signing up, while the page looks fine to you.

The same goes for messages. If “Your registration has been sent” only appears on screen, someone with a screen reader may not hear it, and does not know whether it worked. Good code also helps others, by the way, because a browser or password manager recognises fields with a good name in the code more easily, and can then fill them in itself.

How to do it

1. Use standard HTML elements. HTML is the language web pages are built in. A standard button, link or input field does what 4.1.2 asks by itself, if you use it properly.
2. Give custom-built elements a name, role and state (4.1.2 Name, Role, Value, level A). Take a block of frequently asked questions that opens up. The code then says: this is a button (role) with the question as its name, and it is open or closed (state).
3. Only use ARIA when it is needed. ARIA (Accessible Rich Internet Applications) is a set of extra code that tells assistive technology what something is, for example “this is a button” or “this block is open”. The rule of thumb is: no ARIA is better than bad ARIA. If you say in the code that something is a button, the web developer must also make sure it works with the keyboard like a button. ARIA does not do that by itself.
4. Make sure messages are read aloud (4.1.3, AA). Messages are, for example, “Your registration has been sent” or “12 results found” after a search. In the code, give such a message the role of status message, so that a screen reader can read it aloud without the focus jumping. The list of results itself is not a status message, but the sentence with the number is.
5. Test in more than one way. Try your website with a screen reader, on a computer and on a phone. Ask your web developer to do this too after every major update. The Structuurcheck finds buttons without a name and input fields without a label.

Example: questions about a neighbourhood calendar

A welfare organisation wants to put a neighbourhood calendar from a supplier on its website. Visitors can filter it by day and by type of activity, and use arrows to go to the previous or next week. WCAG looks at the whole page, so also at a calendar, chat or form from a supplier. So ask the supplier before you buy, and not only when a visitor gets stuck:

1. Are the filters and the arrows real buttons, or custom-built elements? And do they have a name, role and state?
2. Does the calendar give a message that a screen reader reads aloud when the list changes, such as “8 activities on Tuesday”?
3. Has the calendar been tested with a screen reader, and can we see the report?

Points to watch

• 4.1.1 no longer exists. This success criterion was about correctly built code and was removed in WCAG 2.2: browsers now deal better with errors in the code, and assistive technology leaves reading the code to the browser. Many problems that 4.1.1 found now fall under 1.3.1 or 4.1.2. Does an old checklist or report still mention 4.1.1, and do you have to meet WCAG 2.1? In the updated WCAG 2.1, 4.1.1 always counts as passed for HTML.

Find out more

• The other principles: perceivable, operable and understandable.
• Making your website accessible: the steps for your organisation.
• Accessible website checklist