In short
Automated scanners detect roughly a third of accessibility issues — they find missing labels, contrast failures and structural errors, but cannot judge whether alt text is meaningful or whether a custom control behaves sensibly. The four manual checks worth running are keyboard operability, zoom to 200%, a short screen reader session, and viewing the page without CSS.
Start with the keyboard
Put the mouse away and use the site with Tab, Shift+Tab, Enter, Space and the arrow keys.
Can you reach everything interactive? Every link, button, field and control.
Can you see where you are? Focus must be visible at every step. If it disappears, that is a serious failure — and if it disappears behind a sticky header, that is a specific WCAG 2.2 criterion.
Can you operate everything? Menus, dropdowns, modals, custom controls.
Can you escape? From a modal, a menu, a date picker. Focus traps are among the most severe problems, because someone using only a keyboard cannot leave the page.
Does the order make sense? It should follow the visual layout. If it jumps around, the DOM order is wrong.
This check takes five minutes, requires nothing, and finds a surprising share of real problems — particularly on interfaces built with custom components.
Run an automated scanner
Browser extensions such as axe DevTools, or Lighthouse's accessibility audit, catch a specific class of issue quickly: missing form labels, insufficient contrast, missing alt attributes, incorrect heading structure, and missing document language.
Understand the ceiling. Automated tools detect roughly a third of accessibility issues. They can tell you an image has alt text; they cannot tell you the alt text is meaningless. They can tell you a button exists; they cannot tell you it does something unexpected.
So treat a clean automated report as the floor, not a pass. A site can score 100 in Lighthouse and be unusable with a screen reader.
Zoom to 200%
Increase browser zoom to 200% and look at your main pages.
Text must remain readable, nothing should overlap, nothing should be cut off, and no content should require horizontal scrolling. Fixed-height containers and absolute positioning are the usual causes of failure here.
This is quick and catches problems that affect a large number of people — many of whom would not describe themselves as having a disability, but who do increase text size.
Try a screen reader
This is the check people avoid, and it is the most informative.
VoiceOver is built into macOS and iOS. NVDA is free on Windows. Both take a few minutes to start using badly, which is enough.
You will be clumsy. That is fine — you are not testing your own proficiency. Close your eyes or turn off the screen and try to complete one task: find a piece of information, submit a form, navigate to a section.
What you are listening for: are links and buttons announced meaningfully, or as "link" and "button" with no context? Are form fields announced with their purpose? Do headings describe the structure? Does anything read as an unlabelled element? Is anything announced twice?
Ten minutes of this teaches more than reading the specification.
View it without CSS
Disable stylesheets and read the page.
If the content still makes sense in order, your document structure is sound. If it becomes incoherent, the visual layout is doing work the markup should be doing — which means assistive technology, search engines, and reader modes all get the incoherent version.
Test with real content
Many accessibility problems only appear with realistic data.
Long names that wrap. Text in a language with longer words. Empty states. Error states. A list with one item and a list with two hundred. Content someone else wrote, with headings they chose.
Placeholder content is uniformly short and tidy, which is why interfaces built against it break on contact with reality.
What still needs a specialist
Be honest about the limits of self-testing.
Complex custom widgets — a rich text editor, an interactive chart, a drag-and-drop board — have genuinely difficult accessibility requirements. Getting a custom combobox right is specialist work.
A formal conformance audit, if you need a defensible statement for a contract or legal requirement.
Testing with disabled users, which is different from testing with assistive technology yourself. People who use these tools daily navigate in ways you will not think to try, and they find problems that pass every technical check.
That last one is the most valuable and the most skipped. If accessibility genuinely matters for your product, budget for it.
A realistic routine
Keyboard test on your three most important journeys. Automated scan on the main templates. Zoom check. One screen reader session per significant release.
That is perhaps an hour, it fits into normal work, and it prevents most of what would otherwise accumulate — which matters because accessibility problems are far cheaper to fix while building than to retrofit afterwards.
If you have a contractual requirement and need to know where you stand, book a call.
Common questions
How much can automated accessibility tools detect?
Roughly a third of issues. They reliably find missing labels, contrast failures, missing alt attributes and structural errors, but cannot judge whether alt text is meaningful or whether a custom control behaves sensibly. A site can score 100 in Lighthouse and still be unusable with a screen reader.
What is the quickest useful accessibility test?
The keyboard test. Put the mouse away and check that you can reach every interactive element, see where focus is at all times, operate every control, escape from modals and menus, and that the tab order follows the visual layout. It takes five minutes and finds a large share of real problems.
Do I need to know how to use a screen reader properly?
No — you are not testing your own proficiency. Ten minutes with VoiceOver on macOS or NVDA on Windows, attempting one task with the screen off, teaches more than reading the specification. Listen for whether links, buttons and fields are announced meaningfully rather than as bare element names.
Why test a page without CSS?
Because it reveals whether your document structure carries the meaning. If the content still reads coherently in order, the markup is sound. If it becomes incomprehensible, the visual layout is doing work the markup should do — and assistive technology, search engines and reader modes all receive the incoherent version.
When do I need an accessibility specialist?
For complex custom widgets such as rich text editors or interactive charts, for a formal conformance audit you need to defend contractually, and for testing with disabled users — which is different from testing with assistive technology yourself, and finds problems that pass every technical check.
