Before the Website Goes Live: A Practical Accessibility Acceptance Test

Category: Accessibility

Accessibility is often treated as a final check at the end of a website project. By then, navigation, colours, components and forms have already been decided. As a result, the errors discovered can be unnecessarily expensive to fix.

A better approach is to use a standard acceptance test before new page types, features and forms are approved. The test does not need to be extensive every time. It does, however, need to be specific, repeatable and carried out by people who know what to look for.

This testing process covers key aspects of WCAG in practice: keyboard navigation, focus, contrast, zoom, screen readers, forms and understandable content. The goal is not just to tick off requirements, but to investigate whether people can actually use the solution.

Start with representative tasks

Do not test the website as a collection of isolated elements. Choose a few tasks that represent what users come to do. These could include finding contact information, navigating to a service, submitting an enquiry, registering for an event or completing a purchase.

For each task, the team should write down:

• Where the user starts.
• What the user should find or do.
• Which pages and components the task involves.
• What constitutes successful completion.

This makes the test more realistic. A menu may work in isolation, for example, but cause problems when the user has to open a submenu, understand which page is selected and then find the right button in the content.

Test 1: Put the Mouse Aside

The simplest manual test is to use the website with a keyboard. Start at the top of the page and use the Tab key to move between interactive elements. Use Shift and Tab to move backwards, Enter to activate links and buttons, and the arrow keys where the component expects them.

Check the order

Focus should follow a logical order. It should normally move through the top menu, main content and further functions in a way that corresponds to the page structure. If focus jumps randomly between areas, the task becomes difficult to understand.

Pay particular attention to menus, search fields, dialogue boxes, tabs, dropdown lists and carousels. These components may look correct but be difficult or impossible to use without a mouse.

Look for visible focus

It must always be clear which element has keyboard focus. A subtle colour change is often insufficient. A clear outline, underline or other visible marker makes it easier to orient yourself.

Also check that the focus indicator is not hidden behind a fixed top menu, information banner or other elements positioned over the content.

Watch out for keyboard traps

Users should be able to move into and out of components. If focus becomes stuck in a menu, video player or dialogue box, the solution has a keyboard trap. When a dialogue box opens, focus should move into it and return to a sensible location when it closes.

Test 2: Examine Contrast and Visual Comprehension

Good contrast is not just about body text. Also test navigation, buttons, links, form fields, error messages, icons and focus indicators. Small text and thin symbols are particularly vulnerable when the colour difference is weak.

Use a suitable contrast tool to measure the combinations, but also assess the page visually. Text placed over photographs or colour gradients may have good contrast in one area and poor contrast in another. A solid background behind the text often produces a more robust result.

Do Not Use Colour Alone

Information must be understandable without requiring users to distinguish between specific colours. A required field should not be marked only in red. An error message should include text explaining the problem. A chart should use labels, patterns or symbols in addition to colour.

Links in running text must also be easy to recognise. Underlining is usually a clearer indicator than a small colour difference.

Test 3: Zoom the Page and Change the View

Zoom the website significantly in the browser and repeat the same tasks. The content should adapt without text, buttons or form fields disappearing. Users should not have to scroll both sideways and downwards to read ordinary text pages.

Look for headings that are cut off, buttons where the text does not fit, menus that cover the content and dialogue boxes that become taller than the screen. Also test a narrow viewport. Accessibility and responsive design often encounter the same problems.

Test 4: Listen to the Page with a Screen Reader

A screen reader test reveals whether the technical structure conveys the same information as the visual design. Not everyone on the project needs to be an expert, but at least one person should be able to perform a basic check with a commonly used screen reader.

Check the page structure

Listen to the page title and navigate between the headings. Headings should describe the content and form an understandable outline. They should not be chosen based on the desired font size. Visual size belongs in the design, while heading levels describe structure.

Then check landmarks, menus, links and buttons. A button labelled “Read more” may be visually understandable, but become unclear when the screen reader presents it without its surrounding context. The text should explain what the user can read more about.

Assess images and icons

Meaningful images need a text description that conveys their purpose. Decorative images should not create noise. Icons that function as buttons must have an accessible name. A magnifying glass may be obvious to someone who can see it, but the function must also be conveyed as, for example, “Search”.

Avoid describing everything in the image if the details are not relevant. Good alternative text conveys what the user needs in the context.

Test 5: Complete the form with errors

Forms should not only be tested with correct information. Enter the wrong format, skip required fields and try to submit. It is in error situations that many accessibility issues become visible.

Labels must be clear

All fields need a visible label that remains in place when the user types. Placeholder text alone is a weak solution because it disappears during completion and often has low contrast.

Instructions should be provided before they are needed. If a password, organisation number or date must follow a specific format, this should be explained next to the field before submission.

Errors must be easy to find and correct

A good error message says which field contains an error, what the problem is and how it can be fixed. “Invalid value” is rarely enough. “Enter the date as day, month and year” gives the user a clear way forward.

After submission, focus should move to an error summary or another clear starting point. The error message must be technically associated with the correct field so that screen reader users receive the necessary information.

Test 6: Assess language and inclusive design

A solution can meet many technical requirements and still be difficult to use. Therefore, read the page with understanding and decision-making in mind.

• Do buttons have specific names that describe the action?
• Are long texts divided by descriptive headings?
• Are technical terms explained when they are necessary?
• Is important information placed before the user has to make a choice?
• Can the task be completed without time pressure or unnecessary interruptions?
• Are contact options and help easy to find?

Practical inclusive design is also about accommodating variation. Users may have impaired vision, motor difficulties, reading difficulties or temporary limitations. They may use the website in bright sunlight, with one hand or under time pressure. A robust interface helps more people than those covered by one specific target group.

Make the findings actionable

Record each issue with the page, component, task, expected result and actual result. You may also attach a screenshot, but make sure the text description is sufficient. “The form does not work” is difficult to fix. “Focus does not move to the error message after submission” is specific.

Prioritise problems that prevent the user from completing a task first. Next come errors that make the task significantly more difficult, followed by improvements that make the experience clearer and more comfortable.

Automated tests can identify some technical issues, but they cannot by themselves determine whether the focus order is logical, whether alternative text is useful or whether an error message is understandable. Therefore, combine automated checks with manual testing.

Assign responsibility before the next release

Accessibility should not be one developer’s checkpoint. The designer must ensure sufficient contrast and clear states. The developer must build correct structure and keyboard support. The content owner must write understandable headings, link text and image descriptions. The product owner or project manager must allocate time for testing and fixes.

The most useful acceptance testing takes place continuously. Test the navigation when it is built, the form when it works and the content templates before many pages are produced. This makes accessibility part of quality assurance, not a clean-up task just before launch.