Understandable: clear language and predictable pages

What it is

Understandable is the third principle of WCAG. Two things must be clear: what is on the page, and how the website works. Pages behave the way you expect, and if something goes wrong, you understand what to do.

It has three guidelines: Readable (3.1), Predictable (3.2) and Input Assistance (3.3). Under these are 13 success criteria at level A and AA: requirements you can test a website against. The most important ones are below, with their numbers. Three of them are new in WCAG 2.2, so older rules and checklists based on WCAG 2.1 do not mention them. You can read which version the rules for government ask for in What is WCAG?

Why it matters

People with a cognitive disability, who for example find it hard to remember, learn or understand new information, can get stuck on a website. They no longer know what they filled in earlier, or cannot find the help again. A form with many steps is tiring, and that happens faster if you also have to remember things along the way. Without help, some people stop halfway, and so they do not sign up.

How to do it

You can check steps 3 to 6 yourself, even without knowing any code. For the rest, ask your web developer or supplier.

1. Set the language in the code (3.1.1, level A). Then a screen reader reads your text aloud in the right language. Is there a part of the page in another language, for example an explanation in Turkish? Mark that too (3.1.2, AA).
2. Do not let anything change by itself (3.2.1 and 3.2.2, A). Does someone choose a neighbourhood from a drop-down list? Then only go to a new page after they press the button, or say beforehand what will happen.
3. Keep the menu and the names the same everywhere (3.2.3 and 3.2.4, AA). The menu is in the same order on every page. If a button is called “Sign up”, do not call it “Register” somewhere else.
4. Always put help in the same place (3.2.6, A, new in 2.2). Help can be your phone number, the contact form, the chat or the frequently asked questions. If the link to contact is at the top of one page, put it at the top of the other pages too.
5. Give every input field a label (3.3.2, A). Add an explanation if needed: “Date of birth, for example 03-05-1980”. Grey example text in the field that disappears when you start typing is not a label.
6. Make error messages clear (3.3.1, A). Say in text which field is wrong and what is wrong with it, not only with red. “The email address is not correct” is enough for this requirement. Do you know how it could be put right? Then say that too (3.3.3, AA): “Enter your email address like [email protected]”.
7. Let people check important input (3.3.4, AA). Does someone change or delete data in the client portal? Then let that person check it first, or make it possible to undo it.
8. Do not ask for anything twice (3.3.7, A, new in 2.2). Has someone already entered their address in step 1? Then fill it in for them in step 3, or let them select it. A tick box “My postal address is the same as my home address” is also fine. You may ask people to type a new password twice if they cannot see it while typing.
9. Make logging in easy (3.3.8, AA, new in 2.2). Logging in must not depend only on remembering, retyping or solving a puzzle: there must be another way, or help with it. So allow password managers, programs that store your passwords and fill them in, and allow copy and paste. A login link by email is also an option. This also applies to a code you get by text message: you must be able to paste it.

Example: a text message code in six boxes

You are helping a client log in to your organisation’s client portal for the first time. She gets a code by text message. She has to type it into six separate boxes, and when she pastes it, only the first digit goes into the first box. Then, in her profile, she enters her phone number, with dashes. At the top, “Invalid input” appears, without any explanation.

Two of these things are WCAG requirements. The code must be possible to paste in one go (3.3.8). The error message names the field and says how to do it correctly (3.3.1 and 3.3.3). Accepting the phone number with or without dashes or spaces is not a hard requirement in WCAG, but it is a recommendation: a message like “Invalid input” can make someone doubt their own number, and give up.

If you take a screenshot for the supplier, make sure none of your client’s data is on it.

Points to watch

• Write at language level B1, even though it is not a requirement for level AA. The success criterion on reading level (3.1.5) belongs to AAA. Even so, in the Netherlands about 3 million people aged 16 to 75 have difficulty with reading, writing and/or maths.
• Also use the separate W3C guidance. It describes websites for people with cognitive or learning disabilities, and goes further than WCAG. It is not a requirement, but it does make your website usable for more people.
• Avoid a picture puzzle when logging in, such as “select all photos with a bicycle”. At level AA it is still allowed, as an exception.

Find out more

• What is language level B1? and Writing at B1
• Low literacy
• The other principles: perceivable, operable and robust.
• Accessible website checklist