Accessibility Testing You Can Start Without a Specialist
Accessibility testing is the pass that asks whether people can actually use the page, including people using a keyboard, a screen reader, or captions. WAI says to evaluate early, because problems found during design are cheaper than repairs after launch, and no tool by itself can decide if the site meets the guidelines [1].
What can you do before you hire anyone?
WAI publishes Easy Checks for a first look that does not require you to be a developer [1]. Tab through the menu. Zoom the text. Play a video with the sound off. Open one image and read its alt text out loud. Those are not a conformance audit. They tell you whether the obvious doors are shut.
What does a full check look like?
A method such as WCAG-EM, against the success criteria, done by a person who knows what they are looking at [1]. WCAG 2.2 is the standard W3C encourages: 13 guidelines, four principles, levels A, AA, and AAA [2]. The test is the criteria. A product score is not a substitute for them.
Why is the scanner not enough?
WAI says tools help and no tool alone determines accessibility. Human evaluation is required [1]. The U.S. Department of Justice says the same thing in its March 2022 guidance: an automated checker is not sufficient, and an overlay is not sufficient [3]. A report with zero errors can miss a form that makes no sense. A report with a few errors is not automatically a barrier. Read the page.
Which failures should the first pass hunt?
The ones the Justice Department lists: poor contrast, color used as the only signal, images with no text alternative, video without captions, forms without labels or error messages, and controls that need a mouse [3]. WAI's introduction puts the same ideas in one line: alt text, a keyboard path, and a transcript or captions [4]. If the first pass finds two of those, you do not need a score to know the page has work left.
How do you test a form specifically?
WAI's forms tutorial says to label every control, group related fields, give instructions, validate in a way people can fix, and tell them when it worked [5]. Only ask for what the transaction needs. A time limit should be avoidable or extendable, unless the limit is essential, such as an auction [5]. Complete the form with the mouse unplugged. That is the test.
Should you involve people who use the tools?
Yes. WAI says to involve users with disabilities, not only to run a checker [1]. One person who uses a screen reader will find a menu your tab pass missed. That session is not a certification. It is the part a tool cannot do [1].
What should you not do with the test site?
Hide it in robots.txt and call the public site done. A disallow does not reliably keep a page out of Google, and it is the wrong tool for an access fix anyway [6]. The page customers use is the page you test. A pretty report about a staging copy does not change the live form.
- Early — during the build, not the week after launch.
- Keyboard — every control reachable, focus visible.
- Alt text — read it aloud. If it is a keyword list, rewrite it.
- Form — labels, errors, no mouse required.
- A person — a tool report is not the evaluation.
Where does the pass sit in the project?
Inside website development, on the launch checklist, not as an optional PDF. Maintenance repeats a short version when a new form ships. If the scope is still being priced, say whether the evaluation is included so it is not a surprise invoice.
What do you write down?
The page, the thing you could not do, and whether a person would hit it or only a tool would. WAI's point is that a report tool does not check the site for you [1]. "Homepage, cannot reach Contact from the keyboard" is a finding. "Score 87" is not. Keep the list short enough that someone can fix it in the next build.
What is enough for this month?
Easy Checks on the homepage, the menu, and one form [1]. Write down what failed in plain sentences. Do not wait for a score of 100 [3]. If you need to claim a WCAG level later, that is a separate evaluation against the criteria [2]. The first pass is so you are not guessing.
Sources & references
- W3C WAI: Evaluating Web Accessibility.
- W3C WAI: WCAG 2 Overview.
- U.S. Department of Justice: Guidance on Web Accessibility and the ADA (18 March 2022).
- W3C WAI: Introduction to Web Accessibility.
- W3C WAI: Forms Tutorial.
- Google Search Central: Introduction to robots.txt.
Evaluation methods and ADA guidance are on the linked pages. This article is not a conformance certificate or legal advice.
If you want a first pass on the live pages before you hire an audit, we can walk the keyboard path with you.
Talk to us arrow_right_alt