How to Test a Website for Accessibility

This is the methodology we run on client audits, written out so you can run it yourself.

That is a deliberate choice. Accessibility firms tend to treat methodology as proprietary, which is strange, because the method is not the hard part — doing it consistently, knowing what the result means, and fixing what it finds are the hard parts. A published method is also the only honest way to answer the question you should be asking any vendor: what exactly did you test, and how?

Budget half a day for a first pass on a representative set of templates. You need a keyboard, a browser, and a screen reader you are willing to learn badly.

Before you start: pick pages, not a site

Do not try to test everything. Pick a representative set and test it properly:

• Your homepage. Not because it matters most, but because it usually contains the most component types.
• A form. Whichever one matters — contact, application, checkout, permit. Forms are where accessibility fails most often and most consequentially.
• A content page. An article, a policy, a service description. This tells you about your authoring habits rather than your code.
• A listing or search results page. Dynamic content, filters, pagination.
• Your most complex interactive thing. A map, a scheduler, a data table, a configurator.

Five pages tested seriously beat five hundred scanned. Templates repeat; if the navigation is broken on one page it is broken on all of them, and you only need to find it once.

Step 1: Run an automated scan, then set it aside

Run a scanner first. It takes minutes, it is free, and it gives you a map of the mechanical problems — missing alt attributes, contrast failures, absent labels, invalid ARIA.

Then set it aside, because it has told you roughly a third of the story. Automated tools evaluate the criteria that have deterministic rules. They cannot judge whether alt text is meaningful, whether focus order preserves meaning, or whether someone can complete a task.

The dangerous outcome is not a scanner missing something. It is a scanner reporting zero errors on a page built entirely from div elements with click handlers — no missing alt text, no invalid ARIA, because there is no ARIA at all, and no keyboard access whatsoever. A clean scan is a starting signal, not a result.

Step 2: The keyboard pass

This is the highest-value fifteen minutes in accessibility testing. Put the mouse away — physically, if you have to. Everything below uses only Tab, Shift+Tab, Enter, Space, the arrow keys and Escape.

Tab from the top of the page and watch. You are asking five questions:

1. Can you see where you are? At every single stop. If focus disappears even briefly, that is WCAG 2.4.7 and it is usually one outline: none in a stylesheet with nothing replacing it.
2. Does the order make sense? Focus should follow the visual reading order. If it jumps from the header to the footer and back, someone has used positive tabindex values or the CSS has reordered content away from the DOM order.
3. Can you reach everything? Every button, link, menu, tab, accordion and control. Anything you can click with a mouse but cannot reach with Tab fails WCAG 2.1.1.
4. Can you operate what you reach? Reaching a custom dropdown is not the same as being able to open it. Try Enter and Space.
5. Can you get out? Open a modal, a date picker, a video player. Can you close it with Escape? Can you Tab back out? If not, that is a keyboard trap — WCAG 2.1.2, and one of the few failures that can strand someone completely.

Specific things to try, because they break most often:

• Open a modal. Focus should move into it, stay inside while it is open, and return to the control that opened it on close.
• Use the main navigation, including any dropdown menus.
• Open and close every accordion and tab set.
• Reach the skip link. It should be the first thing Tab lands on, and it should become visible when focused.
• Submit a form with errors and see where focus goes.

Record it like this: the page, the element, what you expected, what happened. "On /permits/, the 'Apply online' button cannot be reached by keyboard — focus skips from the phone number link to the footer." That sentence is directly actionable. "Keyboard issues on permits page" is not.

Step 3: The screen reader pass

This is the step people skip, and it is the one that finds what nothing else does.

You do not need to be proficient. You need to be able to start it, move through a page, and notice when what you hear does not match what is on screen. An hour of fumbling will teach you more about your site than a year of reading about accessibility.

Pick one to start: VoiceOver on macOS (Cmd+F5, built in) or NVDA on Windows (free). For a first pass, either is fine. For an audit you would test more than one, because implementations differ.

Listen for these five things:

Do images say anything useful? Navigate to an image. "Image, chart dot png" tells the user nothing. So does "image, image". You are listening for alt text that serves the same purpose the image serves.

Do controls announce what they are? A button should announce as a button, with a name describing what it does. "Button" on its own, or "clickable", means the control has no accessible name — extremely common with icon-only buttons.

Does the heading structure make sense? Most screen readers can list the headings on a page. Pull that list up. It should read like an outline of the document. If it is empty, or full of styling choices rather than structure, that is WCAG 1.3.1 — the most-cited criterion in accessibility audits.

Do form fields announce their labels? Move to each field. You should hear the label, the type, whether it is required, and any format instructions. If you hear only "edit text", the field is unlabeled and the user is guessing.

Do changes get announced? Add something to a cart. Filter a list. Submit a form with an error. If the screen appears to change but you hear nothing, the update is invisible to the user — WCAG 4.1.3. This is the single most common failure in modern JavaScript applications.

Step 4: Zoom and reflow

Two related tests, both quick.

Zoom to 200% (Ctrl/Cmd and +). Text should get bigger without content disappearing, overlapping or being cut off. Fixed-height containers are the usual culprit: the text grows, the box does not, and the text is clipped.

Narrow the browser to 320 pixels wide, or zoom to 400%. Content should reflow into a single column with no horizontal scrolling. This is WCAG 1.4.10, and the usual causes are a fixed-width element, a wide table, or a long unbreakable string — an email address will do it.

We found eight pages on our own site failing this, caused by a button label set never to wrap. It is an easy failure to introduce and an easy one to miss, because nobody browses their own site at 320 pixels.

Step 5: Forms, in detail

Forms deserve their own pass because they concentrate the failures that matter most. A broken form does not degrade the experience; it ends it.

For each field:

• Is there a visible label, and is it associated? Click the label text. If the field focuses, the association works. If nothing happens, the for attribute is missing or wrong, and the screen reader will not announce it either.
• Is the placeholder doing the label's job? Placeholder text disappears when typing starts, usually fails contrast, and is not a label. Common and consequential.
• Are required fields marked in text, not only with a red asterisk whose meaning is explained nowhere?
• Are format requirements stated before the error? "Date (DD/MM/YYYY)" prevents the error; "invalid date" after the fact does not.

Then submit it wrong, deliberately:

• Does an error message appear in text, not as a colour change alone?
• Does it say what is wrong and how to fix it? "Invalid input" fails WCAG 3.3.3.
• Is the error associated with its field, so a screen reader user hears it when they reach the field?
• Does focus move to the first error, or are they left to hunt?

Then submit it right and check the confirmation is announced, not just displayed.

Step 6: Media and documents

Video: are there captions, and are they accurate? Auto-generated captions are a starting point, not a result — they reliably mangle names, jargon and numbers, which is most of what matters in a council meeting or a product demo. Is there an audio description or transcript for visual information the narration does not cover?

Audio: is there a transcript?

Anything that plays automatically with sound fails WCAG 1.4.2 unless there is a control to stop it. Worse, it competes with the screen reader the user needs in order to find that control.

Documents: open a PDF and try to select the text. If you cannot, it is a scanned image and completely inaccessible. If you can, check it has real heading structure rather than just large bold text. Most organisations' largest accessibility liability is the document library, and most accessibility programmes quietly skip it.

Step 7: Write it down so someone can act on it

A finding that a developer cannot act on is not a finding. Each one needs:

• Where. The page, and enough detail to find the element.
• What happens. Observed behaviour, not interpretation.
• What should happen.
• Which criterion. The WCAG number, so it can be checked against the standard rather than argued about.
• How bad. Does it block a task outright, make it harder, or is it a defect nobody trips over?
• How many. One instance, or the same component on every page?

That last one changes the work more than anything else. Twenty missing labels are usually one form component rendered twenty times — one fix, not twenty. Page counts are a poor guide to effort, which is why remediation estimates based on them are usually wrong in both directions.

What this method does not cover

Being straight about the limits is part of the method.

It is not conformance certification. There is no such thing. What you can produce is a conformance claim against a specific standard at a point in time, supported by evidence.

One screen reader is not enough for an audit. Implementations differ. A serious audit covers more than one combination of assistive technology and browser.

You are not the user. You are testing whether the mechanics work. Whether the experience is good is a different question, and the only way to answer it is usability testing with disabled people. Conformance is the floor, not the goal.

Cognitive accessibility is under-served by this checklist, and by WCAG 2.1 generally. Plain language, consistent patterns and forgiving error handling matter enormously and are poorly captured by a criterion list. WCAG 2.2 starts closing that gap.

Run it, then decide what you need

Work through this on five pages and you will know more about your site's accessibility than most organisations know about theirs. You will also have a list, in your own words, that you can hand to a developer or bring to a conversation.

If the list is short, fix it and re-test. If it is long, that is normal and not an emergency — start with anything that blocks a task outright.

If you would rather not do it yourself, that is what our audits are — this method, run properly across your whole property, with the findings written for the people who have to act on them. And if you want the automated third of it covered in ten minutes first, our checker runs in your browser with no email required.