Making your website accessible

What it is

A website is accessible if everyone can use it. That includes people who are blind or deaf, cannot use a mouse or find reading hard. Some use assistive technology: software or devices that help them use a computer, such as a screen reader that reads the page aloud, a screen magnifier or voice control.

What makes a website accessible is set out in an international standard: the Web Content Accessibility Guidelines (WCAG). It rests on four principles: perceivable, operable, understandable and robust. If you do not know WCAG yet, first read What is WCAG?

It is about more than the pages you see when you open your website. Your registration form, PDF leaflets, videos, apps and the client portal are part of it too. That is why the European standard for digital accessibility, EN 301 549, covers not only websites but also apps and documents.

Why it matters

In the Netherlands, 4.5 million people have a disability or chronic illness. On top of that, about 3 million people aged 16 to 75 have difficulty with reading, writing and/or maths, and they often find a computer or smartphone hard to use as well. An accessible website also helps people with a temporary impairment, such as a broken arm.

For people with a disability, arranging things online by themselves is still often hard or even impossible. That applies to dealing with the government, banking, education and care. For example, someone cannot make an appointment online because the patient portal is not accessible.

If people can arrange more themselves, your organisation will probably get fewer questions at the front desk, by phone or by chat. And if a client can change an appointment or fill in a form themselves, it no longer has to go through you.

How to do it

1. Make someone responsible. Agree who in your organisation is in charge of accessibility. Make sure the management supports it, and ask for set time and a budget. That person keeps the overview and the planning up to date, and is the point of contact when someone reports a problem.

2. Make an overview of everything you have online. This includes your website, the registration form, PDF leaflets, videos and apps. And the client portal: the secure area where clients log in. For each part, write down who manages it and who built it. At the same time, look at which parts you can close down or replace. What you remove, you no longer need to make accessible.

   Look critically at PDFs in particular, because it is rarely necessary to put information in a PDF. An ordinary web page usually works better: it adjusts to a small screen, and a form is easier to fill in on a web page.

3. Do a first check yourself. You do not need technical knowledge for this. Go through our accessible website checklist. For example, try to fill in your registration form using only the Tab key. Then zoom in to 200% and see whether everything still works. The Colour-blind view shows you whether your text stands out enough against the background.

   Do it in pairs: one person tests, the other writes down where things go wrong. You will need that list later for your web developer.

4. Have a full audit done. A specialist then checks your whole website against all the WCAG requirements. Ask whether they follow the WCAG-EM evaluation method. That method comes from the World Wide Web Consortium (W3C), the organisation behind WCAG. Automated testing tools help, but a person has to judge the results. For government organisations, the advice is to have such an audit done at least once every three years.

   A full audit looks at the technical side, such as the form fields, the menu and the search function, and at the content you add yourself: texts, images, videos and PDFs. An audit of only the technical side, or only the content, is not enough. Also ask whether the auditor tests whole tasks, such as registering from start to finish. A task that runs over several pages only meets WCAG if every one of those pages meets it.

5. Test with the people it is for. Ask clients or experts by experience to do something on your website, such as requesting an appointment. Say beforehand that you are testing the website, not the people taking part. Watch and ask where they get stuck. Care organisations can also request the Pharos-praktijkcheck for this, from Pharos (a Dutch knowledge centre on health inequalities). Two experts by experience and an adviser from Pharos then visit the organisation, and look at the website and the patient portal, among other things. Also read Designing a digital tool together with clients.

   Start early, not when everything is finished, because that gives you a better website and takes less effort while building. But one person does not speak for everyone with a disability. So invite people with different disabilities, and combine what they say with a WCAG audit. Be careful with their time, and pay them fairly.

6. Start with what people need most. Make a plan with an order of priority. First deal with the pages where people need to get something done: registering, contact and urgent help. You do not have to do everything at once. But make sure you make progress every year.

7. Make agreements with your web developer. Agree that new work meets WCAG 2.2 level AA. Ask for proof, such as an audit report. Or have someone else check the work. Make these agreements from the start, because many problems already arise in the design, and fixing them afterwards usually costs more than building accessibly straight away. Also make agreements with the suppliers of other systems, such as the client portal.

   Does a supplier send a general audit of their system? Then check whether it also covers your version. If you add your own logo and brand colours, you need to have those audited separately. The texts and images you add yourself are not covered either. Questions you can ask a web developer or supplier:

   • Does what you build meet WCAG 2.2 level AA, and how do you show that?
   • Do you test with only the keyboard and with a screen reader yourself?
   • Can we add accessible headings, texts and alt texts ourselves?
   • What do you do if a problem turns up after delivery?

8. Teach your colleagues to publish accessibly. Everyone who puts texts on the website needs to know a few things. How to write alt text: a short description of an image for people who cannot see it. How to use real headings. And how to write link texts that say where they go. Write at language level B1 (everyday language that most adults understand), see Writing at B1 level for your clients.

   Good alt text says what the image means, not just what it looks like. For a button with a magnifying glass, “Search” is better than “magnifying glass”. So ask yourself what you would say about the image if you were helping someone who cannot see the page. The Alt text helper helps you write one by asking a few questions. Also have editors take a training course, or read up on Digitoegankelijk (the Dutch government website on digital accessibility).

9. Put an accessibility statement on your website. It says how accessible your website is and what you are still going to improve. It also says how visitors can get in touch or make a complaint. Government organisations must publish such a statement, and use the online assistant (invulassistent) from Digitoegankelijk to do so. Many businesses that sell something online must also have a statement. For other organisations it is good practice. You can write a statement with the Accessibility statement generator (in Dutch).

10. Keep checking. Every new page and every update can cause new problems. So check at least once a year, and update your statement at the same time. In that yearly update, government organisations must show that they are making progress, for example because they have fixed problems that were found. That is a good standard, even if you are not a government body.

Example: a registration form clients get stuck on

Clients call your organisation because they cannot get through the registration form on the website. Then that is where you start. Using only the Tab key and at 200% zoom, you might find a date-of-birth calendar that only works with a mouse, and a wrongly filled-in field that only gets a red border.

Then a few clients fill in the form while you watch. Someone who uses a screen magnifier sees only part of the screen and misses an error message at the top of the page. You will not find something like that with a checklist.

Points to watch

• Look further than a quick test. A website can pass such a test and still have major barriers. Automated testing tools can even give the wrong result.
• Do not rely on a plug-in. Some buttons and plug-ins promise to make your website accessible in one go. But they do not make an inaccessible website accessible, and they can even cause new problems. For example, they can spot missing alt text, but they cannot reliably write good alt text.
• Test on a phone as well. WCAG covers every version of a page, including the version you see on a small screen.
• Check whether the law applies to you. The Besluit digitale toegankelijkheid overheid (the Dutch decree on digital accessibility for government) applies to government organisations and bodies governed by public law. These are organisations with a task in the public interest that are mainly funded or run by the government. Social and community organisations are not covered, unless they provide services on behalf of the government, and nor are care organisations that are not bodies governed by public law. Not sure? Read the explanation on Digitoegankelijk and get legal advice.
• Even without that obligation, keep the law in mind. That is the Wet gelijke behandeling op grond van handicap of chronische ziekte (the Dutch Equal Treatment on the Grounds of Disability or Chronic Illness Act). It asks service providers to make what they offer gradually more accessible, including their digital services, unless that is too heavy a burden. On top of that, someone with a disability can ask you for an adjustment.

Questions

Do we need to meet WCAG 2.1 or WCAG 2.2? If you are having something built, ask for WCAG 2.2, because a website that meets it also meets 2.1. You can read which version the rules for government currently require, and when that is expected to become 2.2, in What is WCAG?

Do our PDF leaflets have to be accessible too? For government organisations, yes: all PDFs and other documents they put online after 23 September 2018. Older files only if people still need them to get something done. A PDF has to meet the same requirements as a web page. Do you have a lot of old PDFs? Then first clear out what is out of date, and then make the most important files accessible. For the rest, offer an accessible version if someone asks for one. You can read how to make a document accessible in Making accessible documents.

How do I read an audit report? Look at the scope: which pages, or which version of an app, the auditor looked at. In the WCAG-EM method this is the first step, so it should be in the report. If your registration form or your version of the portal is not in it, the report says nothing about them.

Find out more

• What is WCAG?: the standard, the levels and the rules in the Netherlands.
• The four principles of WCAG: perceivable, operable, understandable and robust.
• Accessible website checklist: 20 points to check yourself.
• Writing an accessibility statement
• What is digital inclusion?
• Digitoegankelijk ↗ (in Dutch): an explanation of the rules, from the Dutch government.