The Accessibility Audit Checklist We Actually Use

Most accessibility checklists are written to be complete, which is why nobody uses them. Completeness is the wrong goal for a checklist. The right goal is that you actually run it. A fifty-item spreadsheet gets opened once, induces despair, and gets closed. The checklist that changes anything is the one short enough to run on every page you ship, so when I built the audit logic for GazeSite I started from a different question: not what could we check, but which few checks catch the most exclusion per minute of effort. It turns out a handful of them do most of the work, and you can run every one by hand.

The first check is the keyboard. Put the mouse out of reach and try to use the page with Tab, Enter, and the arrow keys. Two things fail constantly. Either something can’t be reached at all, because it’s a clickable div rather than a real button or link, or you can’t see where you are, because someone removed the focus outline for being ugly. Both are total failures for anyone who navigates without a pointer, and the second one is pure self-sabotage: a line of CSS deleting the one visual signal keyboard users depend on. This single check surfaces more real-world exclusion than any other, which is why it goes first.

The second is images. Look at the alt text, but don’t just check that it exists; automated scanners check existence, and existence is the shallow half of the problem. Read what it says. Alt text that reads “image” or “photo123.jpg” or restates the caption is present and useless. The question for each image is what a person who can’t see it needs to know, and the answer is sometimes “nothing,” in which case an empty alt attribute is the correct choice, so screen readers skip it instead of announcing a filename. Judgment, not presence, is the check.

The third is contrast, and here the failures cluster in a predictable place: gray. Designers love light gray text on white because it looks calm, and it’s precisely the choice that makes text vanish for low-vision users, older users, and anyone on a cheap screen in sunlight. WCAG’s baseline ratio of 4.5 to 1 for normal text sounds technical, but any free contrast checker gives you a pass or fail in seconds. Check the body text, the placeholder text, and the text on colored buttons, because those are where the gray hides.

The fourth is forms, and forms deserve outsized attention because they’re where visitors become customers. Click each field’s label; if the cursor doesn’t land in the field, the label isn’t programmatically attached, and a screen reader will announce an unlabeled box. Placeholder text is not a label, since it disappears the moment you type. Then submit the form wrong on purpose and look at the errors: are they announced, are they next to the field, do they say what to fix? A form that only signals errors by turning a border red is invisible to someone who can’t perceive red or can’t see the border.

The fifth is structure. Turn on any heading-outline view, or just read the heading tags in the source, and ask whether the outline describes the page. Screen reader users routinely navigate by jumping heading to heading; if your headings are chosen for font size rather than hierarchy, that navigation lands them in nonsense. While you’re in the source, check two one-liners: the lang attribute on the html element, and the page title, which should say what this page is, not just the company name repeated on every page.

The sixth is anything that moves or interrupts: carousels, autoplaying video, modals. Can the motion be paused? Does the popup trap keyboard focus inside itself, and does Escape close it? Moving content is disproportionately hostile to people with attention or vestibular issues, and broken modals strand screen reader users behind an overlay they can’t perceive. Each of those checks is ten seconds.

That’s the list. Six areas, maybe fifteen minutes for a page the first time, and much less once it’s habit. Notice what it doesn’t achieve: it will not make you WCAG-conformant, and it isn’t meant to. Formal conformance is a legal and contractual artifact with its own process. This list is aimed at something different, the handful of failures that actually eject users, and my experience running audits is that the site that passes these six is usually in decent shape overall, because the same care that fixes them tends to have fixed the long tail too. The correlation runs through culture: teams that never test with a keyboard also never test their forms, and teams that do one tend to do both.

The deeper argument is about what checklists are for. A checklist isn’t a body of knowledge; it’s a forcing function. Pilots don’t use short pre-flight checklists because flying is simple, but because a checklist you reliably run beats an exhaustive one you skip. The web would be measurably more accessible if every team ran even this minimal list on their top five pages, and almost none do. So my advice is to ignore the comprehensive spreadsheet for now. Unplug your mouse, load your checkout page, and start pressing Tab. You’ll know within a minute whether you have a problem, and knowing is the step everyone skips.