Practical guides

Test website accessibility through real tasks

A useful check follows the tasks visitors need to complete. It combines different ways of navigating and records where a person gets stuck.

Go to the method

Two people checking keyboard navigation on a website

Choose representative pages and tasks

Start with the home page, a long article, a filtered listing, a form and an error page. Include mobile layouts and published languages. For each journey, record its starting point, intended action and visible confirmation of success.

Keep the URL, viewport, browser and date with each finding. A screenshot alone cannot explain a keyboard trap or feedback announced at the wrong time.

  • Reach information from the menu.
  • Find a result with a filter.
  • Submit and correct a form.

Navigate without a mouse

Reload the page and use Tab, Shift+Tab, Enter, Space and arrow keys as appropriate. Focus should remain visible and move in a logical order. Open menus, change filters, reach links after cards and close dialogs without becoming trapped.

Check skip links and in-page anchors as well. After a jump, reading should continue from the intended section. The W3C preliminary checks are a useful start, not a full audit.

Read the page in other ways

Increase text size and browser zoom to 200%, then test a phone-sized viewport. Essential content and controls should remain available without forced horizontal scrolling. Measure contrast for text, focus indicators and important messages with an appropriate tool.

Use a screen reader to scan headings and links. Headings should describe sections, links should make sense outside their paragraph and informative images need useful alternatives. Decorative images can have an empty alt attribute.

Test errors and dynamic changes

Submit an empty form and then an invalid address. Feedback should identify the field to fix, stay associated with it and preserve valid answers. After submission, success or failure must be perceivable without relying on colour alone.

For search and filters, check the result count, empty state and announcement of changes to a screen reader. An interface can work with a mouse while its updates remain hard to understand in another mode.

  • Exact step that fails.
  • Effect on the visitor’s task.
  • Expected fix and repeat check.

Prioritise and seek a full evaluation

Fix barriers that prevent reading, navigation, comparison or contact first. Repeat the same journey after each correction. Automated tools can find some issues, but cannot judge whether an alternative text or a journey makes sense.

These preliminary checks do not establish compliance. If an accessibility standard or statement applies to the site, arrange an appropriate evaluation against the relevant standard, such as WCAG or the French RGAA. The prelaunch checklist helps include these checks in the release review.