Accessible website checklist

Go through the points on the pages people use most: the home page, the sign-up page and the contact page. The number of the success criterion in WCAG 2.2 is in brackets. Point 14 is not a requirement for level AA, but it is important in care and support. Point 20 is about documents, such as PDF leaflets.

Do it in pairs: one person tests, the other writes down what goes wrong and on which page. For each point, write “yes”, “no” or “don’t know”. Take any “don’t know” to your web developer.

Perceivable

1. Every image has suitable alt text. It says what the image means for people who cannot see it. If an image is only decoration, the alt text stays empty. For a button with a picture, the alt text says what the button does: “Search”, not “magnifying glass”. If there is text in the image, such as in a logo, that text is also in the alt text. (1.1.1)

2. Videos have captions. Live broadcasts too, such as a webinar. Do you see something important in a recorded video that nobody says, such as a phone number or a name on screen? Then there is also audio description: a voice that tells you what can be seen. (1.2.2, 1.2.4 and 1.2.5)

3. Text and buttons have enough contrast. Normal text has at least 4.5:1 with the background, large text at least 3:1. What you need to recognise a button or input field, such as its border, also has at least 3:1, as do important icons. In the Contrast step of the Colour-blind view you choose the colour of the text and of the background, and see whether they pass. Pay special attention to light grey text and to text on top of a photo. (1.4.3 and 1.4.11)

4. Colour is not the only signal. “Required fields are red” does not work for people who are colour-blind, so add a word or sign, such as “(required)”. Also underline links in running text, so you can see them without relying on colour. (1.4.1)

5. You can zoom in without anything disappearing. Zoom in to 200%: everything still works. Zoom further to 400%: you do not have to scroll sideways. You zoom in with Ctrl and + (on a Mac: Cmd and +), and you usually reach 200% after four to six presses. Watch for text that disappears or ends up on top of other text or an image. (1.4.4 and 1.4.10)

6. Headings are real headings. A heading is also made as a heading in the code, not just as large or bold text, so that people with a screen reader can jump from heading to heading. The headings are in a logical order and say what the section below is about. If you paste the code of a page into the Structuurcheck, you see what is missing in the structure, such as headings. (1.3.1 and 2.4.6)

Operable

7. Everything works with only the keyboard. Click in the address bar, put your mouse aside and go through the page with Tab. With Shift+Tab you go back. You reach every link, button and field, and you never get stuck. A well-known problem is a video player you cannot get out of with Tab. (2.1.1 and 2.1.2)

8. Nothing moves or runs out without you noticing. Does someone have to do something within a certain time, such as with a client portal that logs you out after a while? Then they can turn off the time limit or make it much longer, or they get a warning in time. After that warning, someone has at least 20 seconds to ask for more time with one action. A slideshow that starts by itself and moves for longer than five seconds has a button to pause or stop it. (2.2.1 and 2.2.2)

9. You can skip the menu. The menu is on every page, and with a keyboard or screen reader you otherwise have to go through it every time. A well-known way is a “Skip to content” link at the top of the page, which you sometimes only see when you press Tab for the first time. If you do not see such a link, ask your web developer how someone can skip the menu, because there are other ways too. (2.4.1)

10. Titles and link texts say what they are about. The tab names the page, such as “Sign up with the neighbourhood team”. The most important part comes first, so not “Welcome to the website of … | Sign up”. A link says where it goes, so not just “click here”. (2.4.2 and 2.4.4)

11. You can always see where you are. The link or button you have reached with Tab gets a clear outline or another marking. That outline does not disappear completely behind a fixed bar or chat button. And with Tab you go through the page in a logical order, the way you read: from top to bottom and from left to right. (2.4.3, 2.4.7 and 2.4.11)

12. Buttons are easy to hit, also without dragging. Buttons and links are at least 24 by 24 CSS pixels (the unit web developers use), or there is enough space around them. A link in the middle of a sentence does not count. That way, someone with a shaky hand is less likely to hit the wrong button. What you do by dragging, such as moving an appointment in a calendar, can also be done with a click or tap. (2.5.7 and 2.5.8)

Understandable

13. The website knows what language it is written in. Then a screen reader pronounces the words correctly. Is there a piece of text in another language? Then that is marked too. You cannot see this on screen, so check with your web developer. (3.1.1 and 3.1.2)

14. Your texts are in clear language. Write at language level B1 (a level from the European framework for language skills). The Plain language check (in Dutch) points out long sentences and difficult words, and the B1 checklist helps you further. For level AA this is not a requirement: Reading Level (3.1.5) belongs to AAA.

15. Menu and help are in the same place on every page. That applies to the menu, your phone number, the chat and the link to contact, so that someone who gets stuck can find the help again. It is about the order: if the phone number is below the menu on one page, it is there on the other page too. (3.2.3 and 3.2.6)

16. Forms explain what you need to do. Every field has a visible label. If you click on the label, you go into the field or tick the box, and that also helps with small radio buttons. An error message says in words which field is wrong and how to fix it, for example “Enter your date of birth as day-month-year, such as 03-11-1985”. (3.3.1, 3.3.2 and 3.3.3)

17. You do not have to fill in anything twice. Does a form have several steps? Then what you filled in earlier is already there, or you can copy it, for example with a tick box “My postal address is the same as my home address”. After an error message, what you already filled in also stays. Typing a new password a second time to check it is allowed. (3.3.7)

18. Logging in works without having to remember or retype anything. Test it: copy a password and paste it into the login field, and see whether a password manager is allowed to fill it in. That is a program that stores passwords. You must also be able to paste a login code from a text message. If that does not work, and there is no other way to log in without remembering something, then the login does not pass. (3.3.8)

Robust

19. The code tells assistive technology what is there. Assistive technology is software that helps people use a website, such as a screen reader. Custom-built buttons and menus have a name and role (4.1.2). A message such as “Your message has been sent” is marked in the code as a status message, so that a screen reader reads it aloud without you having to go to it (4.1.3). This is hard to see for yourself: check with your web developer.

Documents

20. PDFs and other documents are accessible too. A PDF must meet the same requirements as a web page. So first ask yourself whether it needs to be a PDF, because a normal web page is usually the better choice, partly because it works better on a small screen. If you have a lot of old PDFs, first clear out what is out of date.

Points to watch

• Also have a full audit done. A website can pass all the points and still have barriers. For a complete picture, a specialist tests your website against all the WCAG requirements.
• Judge for yourself what a testing tool cannot see. Automatic testing tools can see, for example, whether alt text is missing, but not whether it is right. A person judges that.
• Do not use a plug-in as a solution. There are plug-ins that promise to make your website accessible in one go. That does not work, and they can even cause new problems.
• Test with the people it is for. Ask a client or an expert by experience to request an appointment on your website. Watch where it goes wrong. One person does not speak for everyone with a disability, so if you can, invite people with different disabilities.
• Record what you found. In an accessibility statement, write down what already works well and what you are still going to improve. With the Accessibility statement generator (in Dutch) you make a statement in a few steps.

Find out more

• Making your website accessible: the steps for your organisation.
• What is WCAG?
• Explanation per principle: perceivable, operable, understandable and robust.
• Easy Checks from W3C ↗: more simple checks, step by step.