How to make a website accessible: 8 steps

You can make a website accessible in 8 steps: choose the key pages, test them with an automated tool, a keyboard and a screen reader, fix the issues, publish accessibility information and keep checking the website regularly. The goal is a website that people can use without a mouse, with a screen reader, with enlarged text and without telling colours apart. You can work through the steps yourself or together with your web developer. When accessibility is a legal requirement is covered in our article on the European Accessibility Act.

1. Choose the key pages

You do not need to test every page at once. It is enough to test one example of each template: the home page, a category page, a product or service page, the basket and checkout, the enquiry form and the login page. If the website has PDF documents or videos, include them too.

Start with the path a visitor takes to reach their goal: finding a product, filling in a form, paying. An issue on that path matters more than one in the blog archive.

2. Run an automated test

Free tools find some of the issues in a few minutes: missing alt text, low contrast, form fields without labels and skipped heading levels. Commonly used tools include:

• WAVE – a browser extension that marks issues directly on the page;
• axe DevTools – an extension for the browser’s developer tools;
• Lighthouse – built into Chrome, under the Accessibility category.

Automated tools do not find every issue. They cannot judge whether alt text makes sense or whether a form error message is clear. That is why manual testing is essential.

3. Test the website with a keyboard

Put the mouse aside and move through the page with the Tab key, and back with Shift+Tab. Check:

• whether you can clearly see which element is in focus (the focus outline);
• whether the order is logical – top to bottom, left to right;
• whether menus, drop-down lists and pop-ups open with Enter or the space bar and close with Esc;
• whether focus gets stuck in the cookie banner or a chat window;
• whether you can get to checkout and complete an order.

At the same stage, zoom the browser to 200% (Ctrl and +). Text should not overlap, and the menu and buttons should stay within reach. Then open the website on a phone and turn it sideways: the content should adapt, and it should be possible to zoom in on the text with your fingers.

4. Listen to the website with a screen reader

A screen reader reads the page aloud – this is how blind people use websites. You can try one for free: NVDA on a Windows computer, VoiceOver on a Mac or iPhone, TalkBack on an Android phone. Listen for whether:

• images have meaningful descriptions and decorative ones are skipped;
• buttons and links have clear names rather than ‘click here’, or silence where an icon is;
• form fields are read out together with their labels, and error messages are announced;
• headings let you jump between parts of the page.

5. List the issues by priority

Not all issues are equally important. It helps to sort them into three groups:

For the full list of criteria with explanations, see WCAG requirements in plain English.

6. Fix the code, the design and the content

Some issues are fixed by a developer, some by a designer, and some you can sort out yourself.

Code

A developer fixes keyboard navigation and focus order, adds form labels and clear error messages, and sets the page language and button names. A ‘Skip to content’ link also helps, so users do not have to go through the whole menu on every page.

Design

A designer replaces colours that are too faint, enlarges text that is too small, adds a clear focus outline and makes sure buttons are easy to tap on a phone. Information must not be conveyed by colour alone: mark a form field with an error in text as well.

Content

In the content management system you can write image descriptions yourself, put headings and link text in order and add captions to videos. Important information locked in PDFs is worth moving to an ordinary web page.

A few rules for whoever writes the content:

• Alt text describes what the image conveys, not what the file is called: not ‘IMG_2045’ but ‘Red children’s jacket with a hood’.
• Headings go in order: an H3 follows an H2, rather than jumping straight to H4. Do not choose a heading level just for its font size.
• Link text says where the link goes: ‘Delivery terms’, not ‘click here’.
• Text uses short sentences and paragraphs, and explains difficult terms.

What about accessibility widgets?

An accessibility toolbar lets visitors enlarge the text or change the colours, but it does not fix errors in the code. A button without a name or a menu that does not work with a keyboard stays inaccessible, so a widget can only complement the work. We integrate ready-made accessibility widgets too: we install them on the server and connect them to the website template, which can also be done while a new website is being built. But we always offer a widget as an addition to making the website itself accessible, not as a replacement.

7. Publish accessibility information

Create an Accessibility page (often called an accessibility statement) and include:

• the level you are aiming for, such as WCAG 2.1 AA;
• what has already been made accessible and which known issues remain;
• how visitors can report a problem – by email or phone.

Write plainly and honestly. If, for example, old PDF catalogues have not been made accessible yet, say so and offer an alternative, such as sending the information by email. The Accessibility page itself must meet the same accessibility requirements. The easiest place for the link is the footer, so it can be reached from every page.

For businesses covered by the European Accessibility Act, information on the accessibility of the service is mandatory.

8. Keep the website accessible

Accessibility is not a one-off job. Every new page, photo or plugin can bring issues back, so:

• add the accessibility rules to the instructions for everyone who updates the website;
• repeat steps 2–4 after any major update;
• when building a new feature, put the accessibility requirements in the brief;
• before installing a new plugin, chat window or cookie banner, check that it works with a keyboard.

It is worth repeating the full test at least once a year, even without major changes: browsers, plugins and the content itself change over that time.

Regular checks and small fixes are easy to include in website maintenance.

When to call in specialists

You can usually fix content issues yourself, but keyboard navigation, forms and the design system need a developer and a designer. If the website is built on old technology, rebuilding it is sometimes cheaper than fixing it – this only becomes clear after an audit. An accessibility audit costs from €120; fixes are priced based on the audit report.

If you would like us to test your website and fix the issues we find, get in touch about website accessibility.