How to Check if a Website Is Accessible

To check whether a website is accessible, you combine two kinds of testing: automated scans and manual checks. Automated tools like axe DevTools, WAVE and Lighthouse catch machine-detectable problems in seconds, but they find only a fraction of all issues — commonly estimated at around 30 to 40% of WCAG problems. The rest require human judgement: navigating with a keyboard, listening with a screen reader, checking contrast, and testing zoom. Relying on a scanner alone gives a false sense of safety; pairing it with manual testing is the only way to really know. This guide walks through both, step by step.

It is the practical companion to what WCAG is and the difference between A, AA and AAA, and it leads into the repeatable process in how to run an accessibility audit.

Why a single tool is not enough

It is tempting to run one scanner, see a green score, and move on. The data says otherwise. WebAIM's annual Million report — which analyses the home pages of the top one million websites — has consistently found detectable WCAG 2 failures on roughly 95 to 96% of those pages. And that figure only counts the issues automated testing can detect; the true rate of problems, including those only humans can spot, is higher still.

So two things are true at once: automated testing is genuinely useful (it reliably surfaces a large volume of real, fixable issues), and automated testing is nowhere near sufficient (it misses most of the picture). The right mental model is that an automated scan is a smoke detector, not a full safety inspection. It tells you something is wrong fast, but a clean scan does not mean the building is safe.

The two-layer approach

A complete check has two layers that do different jobs:

Layer	What it does	Strengths	Limits
Automated scanning	Machine checks the code against rules	Fast, repeatable, scales to many pages, catches clear violations	Only finds machine-detectable issues (~30-40%); no judgement of meaning or usability
Manual testing	A person operates and inspects the page	Catches meaning, context, logic and real usability; covers the criteria automation cannot	Slower, requires skill and time, harder to scale

You need both. Automated scanning narrows the field and catches the obvious; manual testing verifies the experience and catches what matters most. The sections below cover each, then show how to combine them into a single pass.

Step 1: Run automated scans

Start here because it is fast and free, and it clears out the low-hanging fruit before you spend time on manual work.

• axe DevTools — a browser extension built on the widely used open-source axe engine (also embedded in many other tools). It scans the current page, lists violations grouped by severity, and crucially tends to minimise false positives, so what it flags is usually real.
• WAVE (WebAIM) — a browser extension and web tool that overlays icons directly on the page to show errors, alerts and structural features. Its visual approach makes it easy to see where on the page an issue lives.
• Lighthouse accessibility audit — built into Chrome DevTools (and PageSpeed Insights). It runs a set of automated accessibility checks and gives a score with explanations. It is convenient because it sits alongside performance and SEO audits.

Run at least one of these on each template type — home page, article, product page, form, search results — because different page types have different problems. Record what each flags. Common automated findings include missing alt attributes, form fields without labels, insufficient colour contrast, empty links and buttons, missing document language, and duplicate IDs.

A broad site-intelligence tool can fold this in too: StackOptic includes a WCAG accessibility check as part of its single report, so you can see accessibility flags next to performance, SEO and other signals without running a separate tool.

Step 2: Test with a keyboard only

This is the single most revealing manual test, and it costs nothing. Unplug your mouse (or put it aside) and try to complete a real task — sign up, search, add to cart, submit a form — using only the keyboard. Use:

• Tab and Shift+Tab to move forward and backward between interactive elements.
• Enter to activate links and buttons; Space to activate buttons and toggle checkboxes.
• Arrow keys within components like menus, radio groups, sliders and some custom widgets.

As you go, watch for failures that automation cannot reliably catch:

• Can you reach everything? If a control cannot be focused, keyboard users cannot use it.
• Is the focus order logical? Tabbing should move through the page in a sensible reading order, not jump around.
• Can you always see where you are? A visible focus indicator is required at WCAG AA; if focus is invisible, keyboard users are lost.
• Are there keyboard traps? If focus enters a component (a modal, a widget) and cannot get out with the keyboard, that is a serious failure.
• Do skip links work? A "skip to content" link should let you bypass repeated navigation.

If you cannot complete the task with a keyboard, neither can a large group of real users. We cover the fixes in how to make a website keyboard accessible.

Step 3: Do a screen-reader pass

Next, experience the page the way a blind or low-vision user does. You do not need to be an expert; a basic pass surfaces a lot.

• NVDA — free, on Windows, the most widely used screen reader for testing.
• VoiceOver — built into macOS (press Command-F5) and iOS, so every Mac user already has it.
• JAWS — a powerful commercial Windows screen reader used heavily in enterprise and assistive contexts.

Learn a few commands for navigating by heading, by link, and by form field, then turn off your screen (or close your eyes) and listen. Check that:

• Headings form a logical outline you can navigate and that reflects the content's structure.
• Images are described meaningfully — not "image", not a filename, but the actual purpose or content (see how to write good alt text for images).
• Links make sense out of context — a screen-reader user may pull up a list of links, so "click here" five times is useless.
• Forms announce their labels and that error messages are read out and clearly associated with the right field.
• Dynamic updates are announced — if content changes (a filter applies, a message appears), the user should be told.

Listening to your own site is often a humbling, clarifying experience, and it reveals problems no scanner will.

Step 4: Check colour contrast

Low contrast is one of the most common and most automatically detectable issues, but it is worth checking deliberately because design changes reintroduce it constantly. WCAG AA requires 4.5:1 for normal text and 3:1 for large text and meaningful UI components. Use a contrast checker — the one in Chrome DevTools, the WebAIM Contrast Checker, or the contrast feature in axe/WAVE — and test your body text, link text, button labels, placeholder text and text over images. Also confirm you are not using colour alone to convey meaning (for example, a form field marked as invalid only by turning red is a problem for colour-blind users; pair it with an icon or text).

Step 5: Test zoom and reflow

People with low vision often zoom. WCAG AA requires that text can be resized up to 200% without loss of content or functionality, and that content reflows so it does not require two-dimensional scrolling at typical mobile widths. Zoom your browser to 200% and narrow the window: does text stay readable, do columns collapse gracefully, does anything get cut off, overlap, or disappear? Horizontal scrolling, clipped content and overlapping elements at zoom are common failures that frustrate real users and breach AA.

Step 6: Review forms, headings and landmarks

A few structural checks round out a solid pass:

• Forms: every input has a visible, programmatically associated label; required fields and formats are communicated in text; errors are specific and helpful, not just "invalid input".
• Headings: there is a single logical h1, and headings nest sensibly (you do not skip from h1 to h4); headings describe the sections they introduce.
• Landmarks: the page uses semantic regions (header, nav, main, footer) so assistive-technology users can jump between major areas.

These overlap heavily with SEO structure, which is part of why accessible markup also helps machines parse your content — a theme we explore in how to check if your site is ready for AI search.

Putting it together: a quick check sequence

For a fast but genuine check of any single page, run this sequence:

1. Automated scan with axe DevTools or WAVE — note every violation.
2. Keyboard pass — complete a key task with no mouse; check reachability, order, focus visibility and traps.
3. Screen-reader pass — listen to headings, images, links and a form with NVDA or VoiceOver.
4. Contrast check — verify text and UI meet 4.5:1 / 3:1 and that colour is never the only cue.
5. Zoom and reflow — test at 200% and at a narrow width.

This sequence takes a focused session per template and gives you a far more honest picture than any single tool. To turn it into a structured, prioritised, repeatable programme — with issue logs, severity and remediation tracking — move on to how to run an accessibility audit.

Common mistakes when checking accessibility

A few errors recur. Trusting a green automated score — remember the ~30-40% ceiling and WebAIM's ~95-96% finding; a clean scan is a starting point, not a verdict. Testing only the home page — issues hide in forms, checkouts, dashboards and deep templates. Skipping the keyboard test because it feels too simple — it is the most revealing test there is. Never using a screen reader — the experience is the point of accessibility, and you cannot infer it from code alone. Checking once and forgetting — every release can regress, so testing has to be ongoing, ideally baked into the workflow.

The bottom line

Checking accessibility properly means accepting that no single tool can do it. Automated scanners (axe DevTools, WAVE, Lighthouse) are fast and find a real share of issues — but only a share, around 30 to 40%, which is exactly why WebAIM's Million report still finds detectable failures on the overwhelming majority of top sites. Pair those scans with manual testing — keyboard-only navigation, a screen-reader pass, contrast checks and zoom/reflow — and you get an honest picture of whether real people can use your site. Then formalise it with a repeatable audit process and ground it in the WCAG standard.

Want a WCAG accessibility check on any URL, alongside performance, SEO and more, in one report? Analyse any URL with StackOptic — free, no sign-up.