How to run a first-pass accessibility audit yourself

The short version: run an automated scanner (axe, WAVE, Lighthouse), which catches roughly a quarter to a third of WCAG issues, then do what it cannot: navigate by keyboard only, spot-check with a screen reader, verify contrast at 4.5:1 for text, 3:1 for large text and UI, and read alt text and labels like a stranger would. A real first pass, not a certificate.

Let me walk you through it the way I would if we were sitting at your screen together, because an afternoon of doing this properly teaches you more than any report I could hand you.

What does a first-pass accessibility audit actually check?

A first-pass audit has two halves, and most people only do the first one. Half one is automated: a scanner flags what a machine can verify with certainty, like a missing alt attribute. Half two is manual: a human checks what needs judgment, like whether that alt text actually describes the image, or the tab order makes sense to someone who cannot see the page.

Skip half two, and you have not audited your site. You have run a spell checker and called it an edit.

Why do automated scanners only catch a quarter to a third of your issues?

Here is the number that should recalibrate how much comfort you take from a green checkmark. Deque, the company behind the open-source axe-core engine that powers most scanners, states plainly that the accessibility industry has long treated automated coverage as sitting around 20 to 30 percent (Deque, to re-verify). A separate look at the criteria themselves lands close to the same place: only about 30 percent of WCAG 2.1 Level AA success criteria, roughly 15 to 16 of them, can be meaningfully tested by a machine at all (TestParty, to re-verify). Everything else needs a person.

Quick caution so you read tool marketing like a pro: Deque's own newer study of over 2,000 audits and nearly 300,000 issues found automated testing catches 57 percent of issues when you count by volume rather than by criteria (Deque, to re-verify). Both numbers are true, they just measure different things. Count by rule, and automation covers less than a third of the rulebook. Count by how often each issue shows up on a page, and it looks better, because a handful of high-frequency issues, contrast especially, inflate the total. Either way, a meaningful share of real issues need a human to find them.

None of this is a knock on axe, WAVE, or Lighthouse. Run one today. Axe DevTools and WAVE are free browser extensions, Lighthouse ships inside Chrome's DevTools, and each hands you fixable defects in minutes: missing labels, bad heading order, contrast failures, duplicate IDs. That is the fastest ten minutes of accessibility progress you will get all week. Just do not mistake a clean scan for a clean site. None of the three can tell you whether your alt text makes sense, or whether a keyboard-only visitor can get through your checkout (David Mello, to re-verify). That is the manual half, and it is where the real audit lives.

What should I test by hand, and in what order?

Five checks, in the order I run them. Each takes fifteen to thirty minutes on a typical page, and together they surface more real defects than any scanner alone.

Can you reach and operate everything using only a keyboard?

Put the mouse away. Use Tab to move forward, Shift+Tab to move back, Enter or Space to activate, and arrow keys inside menus and custom widgets. Ask three things as you go. Can you reach every link, button, and form field. Is there always a visible focus indicator showing exactly where you are. And can you get back out of anything you opened, a modal, a menu, a date picker, without getting trapped. A keyboard trap, where focus enters a component and cannot leave, is one of the most disabling defects a site can have: it does not inconvenience a keyboard user, it stops them cold.

What does your page sound like with a screen reader?

You do not need to become fluent. You need thirty honest minutes with the tool your users most likely run. NVDA is free and open source on Windows, and VoiceOver ships built into every Mac and iPhone, so neither costs you anything to try. That coverage matters: WebAIM's most recent Screen Reader User Survey found NVDA and JAWS nearly tied as the top primary desktop screen readers, at 38 and 41 percent, with NVDA leading once you count everyone who runs it at all (WebAIM, to re-verify). Turn one on, close your eyes, and try to complete your site's single most important task, submitting a form, reading an article start to finish. Note every moment of confusion. That confusion is your punch list.

Does your text and your controls meet contrast minimums?

This is the one check with a hard number, not a judgment call. WCAG's Contrast (Minimum) criterion requires at least 4.5:1 for normal text against its background, dropping to 3:1 for large text, roughly 18 point or 14 point bold and larger (W3C). A sibling criterion, Non-text Contrast, extends that same 3:1 minimum to the visual parts of UI components a user needs to identify and operate: input borders, icon buttons, toggle states (W3C). Check this carefully, because it is by far the most common failure on the web. WebAIM's latest analysis of the top one million home pages found low contrast text on 83.9 percent of them, averaging 34 instances per page (WebAIM, to re-verify). Any browser color picker or contrast extension gives you the ratio in seconds. Check body text, links, placeholder text, and button borders, not just the headline.

Would your alt text make sense read aloud, with no image in view?

Cover the picture and read only the alt text out loud. Does it convey the same information a sighted visitor gets. "Photo of a laptop" tells a screen reader user nothing. "Dashboard showing revenue up 12 percent quarter over quarter" does the job. Decorative images should have empty alt text (alt="") so screen readers skip them silently instead of announcing a filename. This matters more than most site owners assume: missing or unhelpful alt text turned up on 53.1 percent of home pages in that same WebAIM analysis, and nearly half of those were linked images, which breaks navigation entirely for a screen reader user, not just comprehension (WebAIM, to re-verify).

Do your forms label everything, and explain errors in words?

Click into every field with nothing but Tab and a screen reader running. Does it announce a real label, "Email address," not silence, not a placeholder that vanishes the moment you type. Submit the form with something wrong on purpose. Does the error say what is wrong and how to fix it, in text, not just a red border, which communicates nothing to someone who cannot see red or the border at all. This is not a minor gap: missing form input labels turned up on 51 percent of home pages (WebAIM, to re-verify), meaning one in two sites asks half its visitors to guess.

What did WCAG 2.2 add that most site owners have never heard of?

WCAG 2.2 added nine new success criteria on top of 2.1, and four of them are the ones I see missed constantly, because most existing checklists were written before 2.2 shipped and never got updated (W3C).

Target Size, 2.5.8. Interactive targets, buttons, links, icons you tap, need to be at least 24 by 24 CSS pixels, or have enough space around them that a 24 pixel circle centered on each does not touch its neighbor (W3C). This exists for anyone with limited fine motor control, and for every one of us holding a phone on a moving bus.

Focus Not Obscured, 2.4.11. When something receives keyboard focus, a sticky header, cookie banner, or chat widget must not hide it completely. If you cannot see where focus is, you cannot use the keyboard with confidence, and sticky headers are everywhere now.

Redundant Entry, 3.3.7. If a user already gave you a piece of information earlier in a process, do not make them type it again in the same session unless you auto-fill it or offer it as a selectable option. Multi-step checkouts and long applications are the usual offenders.

Accessible Authentication, 3.3.8. Logging in should not require solving a puzzle, transcribing a distorted image, or remembering something with no alternative. Password managers, "email me a link," and biometrics all satisfy this. A CAPTCHA with no alternate path does not.

None of these four show up reliably on an automated scan. All four are things you check yourself, by hand, in under ten minutes per page.

You found twenty issues. What order do you fix them in?

Do not work top to bottom. Work by how many people a fix helps versus how long it takes.

Start with the handful of error types that show up constantly, because fixing one pattern once usually resolves it everywhere it repeats. WebAIM's research found that just six error categories, low contrast text, missing alt text, missing form labels, empty links, empty buttons, and missing document language, account for 96 percent of all detected errors across the top one million home pages (WebAIM, to re-verify). That is rarely six separate jobs. It is usually one design token, one component, and one template fix each, repeated across your whole site the moment you land it.

A simple way to rank what you found:

1. Blocks a task completely. A keyboard trap, an unlabeled required field, a login a screen reader user cannot complete. Fix these first, always.
2. Affects most pages from one root cause. A global contrast token, a button component, a header template. One change clears dozens of instances.
3. Affects a single page or a rare path. A one-off image caption, an old landing page nobody links to. Fix as you next touch that page.
4. Cosmetic or AAA-level polish. Genuinely lower priority, fine to queue behind the first three.

What a first-pass audit is not

I want to be straight with you here, because overpromising is the one thing I will not do on this site. A first-pass self-audit is not a certification. It is not a VPAT (a Voluntary Product Accessibility Template), it is not a legal defense, and it will not replace testing with actual people with disabilities, who find things no checklist predicts, because they use assistive technology in real conditions you and I cannot fully simulate at a desk. W3C's own accessibility evaluation guidance says it plainly: no tool alone can determine whether a site meets accessibility standards, and knowledgeable human evaluation is required to make that call (W3C). An afternoon of the checks above gets you a real, honest first pass: the loudest problems found and fixed, and a clearer sense of where the deeper gaps probably are. That is worth doing today. It is not the finish line.

The pass I run on every page

The routine, so you can steal it:

• Run an automated scan. Fix every flagged issue; it costs nothing.
• Unplug the mouse. Tab through and note anything unreachable, invisible, or trapped.
• Turn on NVDA or VoiceOver and do your most important task with eyes closed.
• Check contrast on body text, links, placeholders, and button borders.
• Read your alt text and form labels aloud, as if seeing the page for the first time.
• Check the four WCAG 2.2 additions by hand: target size, obscured focus, redundant entry, accessible authentication.
• Rank what you found by how many people it blocks, not which page it is on.
• Fix the patterns doing most of the damage first, then work down.

Do this once, properly, and you will read your own site differently forever after.