Accessibility is one of those website topics that can sound technical until you remember what it is really about: whether people can use your website. The tools are useful, the standards matter, but neither replaces testing the experience itself.
Passing a checker is not the same as being accessible
Automated accessibility tools are brilliant at spotting certain classes of problem. They can flag missing alternative text, some colour contrast failures, missing form labels and other common issues.
But automation has limits. A tool can tell you that an image has alt text. It cannot reliably tell you whether the alt text is useful. It can identify a button without an accessible name. It cannot understand whether the button's purpose makes sense in the wider journey.
That distinction matters because accessibility is ultimately about people, not scores.
Start with the basics
A good accessibility review should look at the fundamentals of how a page is structured and operated.
- Keyboard access: can you reach and operate interactive elements without a mouse?
- Focus: can you see where keyboard focus is, and does it move in a sensible order?
- Headings: do headings create a logical structure rather than simply making text look bigger?
- Links and buttons: can you tell what each control will do from its accessible name and context?
- Forms: are fields properly labelled and are errors clearly explained?
- Images: does alternative text communicate the useful meaning of an image where needed?
- Contrast: is text and essential interface information sufficiently distinguishable?
- Responsive behaviour: does the interface remain usable when text is enlarged or the viewport changes?
Semantic HTML does a lot of heavy lifting
One of the best accessibility techniques is also one of the least glamorous: use the right HTML element for the job.
A real <button> behaves differently from a clickable <div>. A real heading gives assistive technology useful structure. A proper form label connects a field to its purpose. Native HTML elements come with behaviour that developers otherwise have to recreate.
ARIA has an important role when native HTML cannot express the required interaction, but it should not be used to reinvent standard controls unnecessarily.
Think about the whole journey
Accessibility problems often appear between components rather than inside them. A form might have perfectly labelled fields but show an error message that is impossible to find. A menu might open correctly but trap keyboard focus somewhere unexpected. A cookie banner might technically be operable but make the rest of the page difficult to reach.
Test the journeys that matter. Search for a service. Read an article. Submit an enquiry. Book something. Change a preference. Then repeat those tasks using only a keyboard and, where possible, assistive technology.
Do not forget the content
Accessibility is not only a development task. Content can create barriers too.
Long blocks of dense copy, vague link text, unexplained jargon, videos without captions and images containing important text can all make information harder to consume.
Plain language is not about making content simplistic. It is about removing unnecessary effort.
What WCAG gives you
The Web Content Accessibility Guidelines, usually shortened to WCAG, provide a common framework for evaluating web accessibility. They organise requirements around four principles: content and controls should be perceivable, operable, understandable and robust.
Conformance levels are useful because they give organisations a shared target. But a conformance claim should be based on meaningful evaluation, not simply the output of one browser extension.
W3C also provides techniques and supporting material because accessibility is not something that can be reduced to a single test.
Use automated tools properly
Think of an automated scan as the first layer of an accessibility review. It is excellent for scale and consistency. It is particularly useful for finding repeated issues across many pages.
Then add manual checks. Keyboard testing, zoom and text resizing, content review and user testing can reveal issues that automation cannot understand.
A practical accessibility checklist
- Run an automated accessibility scan across representative pages.
- Fix repeated issues at the component or template level where possible.
- Navigate key journeys using only a keyboard.
- Check visible focus states and logical focus order.
- Review headings and page landmarks for sensible structure.
- Test forms, including validation and error handling.
- Check images, links, buttons and other interactive content in context.
- Test at different viewport sizes and with enlarged text.
- Review videos, animations and other media for accessibility needs.
- Where appropriate, include people with disabilities in user testing.
The goal is not a green score
A perfect automated score can be reassuring. It is not the definition of an accessible website.
The better question is whether someone can actually complete the tasks the website exists to support. If they can, and if the site is built on sound accessible foundations, you are much closer to the outcome that matters.