Website accessibility checks to include before launch

Accessibility checks should be part of building and reviewing a website, not a last-minute scan. Before launch, test the important tasks with a keyboard, review headings and labels, check error messages and use a range of devices and assistive methods. Automated tools can find some problems, but they cannot prove the whole experience works.

Define the tasks to test

Choose journeys that matter: finding a service, using navigation, submitting a form, making a purchase or reading key information. Test them without a mouse. Can you see where focus is, reach every control and leave it again? Are menus and dialogs usable with a keyboard?

The Web Content Accessibility Guidelines provide the underlying criteria. For a business team, a practical test plan should translate those criteria into the site's actual pages and tasks, with a specialist review where the risk or complexity warrants it.

Check structure and content

Read pages with headings alone to see whether the order makes sense. Check that links describe their destination, images have appropriate text alternatives and instructions do not depend only on colour or position. Zoom text and inspect narrow screens to see whether content remains usable without losing important actions.

Ask whether video and audio content has suitable alternatives. Review the language of instructions: short, specific labels help many readers, not only people using assistive technology. The visitor-facing accessibility review offers another way to record barriers in common tasks.

Test forms and errors carefully

Every input should have a clear label and any required format should be explained before submission where possible. Submit invalid data deliberately. Does the page identify each error in text and show how to correct it? Is entered information retained so the user does not have to start again?

Test success as well as failure. A confirmation should be obvious and specific enough that the user knows whether an action completed. If a form has a challenge or timeout, check that people can understand and recover from it.

Record and retest findings

For each issue, note the page, task, device or input method, what happened and what should happen instead. Prioritise barriers that stop someone completing a task. Retest after fixes and after major content changes. Accessibility is an ongoing property of the service, not a badge earned once at launch.

Frequently asked questions

Is an automated accessibility scan enough?

No. It can identify some code patterns, but it cannot judge every interaction, instruction or user journey. Combine it with manual and, where appropriate, specialist testing.

Should accessibility be checked on mobile devices?

Yes. Text zoom, narrow layouts, touch targets and screen-reader behaviour can expose problems that are not visible on a desktop review alone.

Can we fix accessibility problems after launch?

Yes, but leaving serious barriers until later can exclude users from important tasks. Test early and make unresolved issues part of the launch decision.