Accessibility audit for a web app: the WCAG AA baseline, the keyboard walk, and the score to hit

An accessibility audit is a structured check of whether someone using only a keyboard, a screen reader or 200 percent zoom can finish your app’s core flows, measured against WCAG Level AA. For a small web app it is three passes: an automated scan taken to a score of 100, a keyboard-only walk through signup, checkout and the main task, and a short screen-reader pass.

What an accessibility audit is: three passes against WCAG AA

An accessibility audit tests whether people who use a keyboard, a screen reader or zoom can complete an app’s core flows, judged against WCAG Level AA. It runs as three passes, an automated scan, a keyboard-only walk and a screen-reader pass, because no tool alone can determine whether a site meets accessibility standards.

It belongs with the other measured checks in web performance optimization: like page speed, it has a score, a pass condition and evidence you can keep. Each pass catches a different class of problem, and each has a blind spot the next one covers. The time column is my working estimate for an app with a handful of core pages, not a standard.

W3C’s guidance on evaluating accessibility puts the limit of the first row plainly: “Knowledgeable human evaluation is required to determine if a site is accessible.” That is why the keyboard and the screen reader are part of the audit, not extras. Large audits add a fourth kind of testing, sessions with disabled people who use assistive technology every day, and nothing on this page replaces that.

In the stack, an audit reads the rendered HTML and the component library underneath it. That is why one library choice, a date picker or a modal, tends to repeat the same finding across every screen that uses it, and why fixing the component clears many findings at once (my reading). For a small app, scope the audit to the core pages and flows: sign-in and signup, the pricing or checkout path, and the one task people pay for. Every page of a marketing site is a different job.

What is WCAG AA compliance: the levels, the principles and the version

WCAG AA is the middle of three conformance levels in the W3C’s Web Content Accessibility Guidelines, and the level the laws and contracts in the table below most often point to. Meeting it means the page satisfies all the Level A and Level AA success criteria. W3C’s word for that is conformance, not compliance.

The current version is WCAG 2.2, a W3C Recommendation dated 12 December 2024. Its criteria sit under four principles: perceivable, operable, understandable and robust. The three levels stack: A is the lowest, AAA the highest, and AA includes everything in A. Counting the criteria in the 2.2 text, 31 are Level A and 24 are Level AA, so an AA target means 55 success criteria; 4.1.1 Parsing is marked obsolete and removed.

W3C’s WCAG 2 Level AA conformance page says “Many organizations strive to meet Level AA.” AAA is a different matter. The standard itself says “It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.”

Conformance is also a claim about named things. W3C says claims are optional, but a claim that is made must include its date, the guidelines’ title, version and URI, the level satisfied, a description of the web pages it covers, and a list of the web content technologies relied upon. So “the app is WCAG compliant” is not a sentence W3C’s model supports. “These five pages conform to WCAG 2.2 Level AA as of this date” is.

WCAG, ADA and Section 508: what a WCAG compliance audit is measured against

A WCAG compliance audit is measured against WCAG, because the rules point at it. The Revised 508 Standards require WCAG 2.0 Level A and AA, the 2024 ADA Title II rule names WCAG 2.1 Level AA for state and local governments, and the European Accessibility Act’s reference standard, EN 301 549, is based today on WCAG 2.1 Level AA.

Row by row, here is what is required and what is good practice. Section 508 binds federal agencies, and through them what they buy; Section508.gov’s laws and policies page says the law applies “when they develop, procure, maintain, or use” that technology, and the Access Board’s Revised 508 Standards set the WCAG 2.0 level. The Department of Justice’s ADA Title II web rule is a requirement for public entities, and an Interim Final Rule published on April 20, 2026 extended its compliance dates to the ones in the table. For businesses under Title III, the Department of Justice’s web accessibility guidance says the ADA’s requirements apply to what they offer on the web, but “The Department of Justice does not have a regulation setting out detailed standards”, so for businesses WCAG is named as helpful guidance, not as a regulation’s standard.

In the European Union, Directive (EU) 2019/882 applies to covered services from 28 June 2025 and exempts microenterprises providing services, meaning enterprises that employ fewer than 10 persons and have an annual turnover or an annual balance sheet total not exceeding EUR 2 million. The directive itself names no standard; it presumes conformity for services that meet harmonized standards published in the Official Journal. A new EN 301 549 v4.1.1 that adopts WCAG 2.2 was published in September 2026, and the European Commission’s AccessibleEU center says it is not yet the legal reference.

WCAG itself is a W3C standard, not a law: it becomes a legal requirement only where a law, a rule or a contract names it. ADA compliance and WCAG conformance are not the same thing either: the ADA prohibits discrimination against people with disabilities, and WCAG 2.1 Level AA is the technical standard its Title II rule adopts. This is not legal advice: which of these applies to a given company is a question for a lawyer.

The fifth row is the one a small B2B app is likeliest to meet first, in my reading. An enterprise buyer asks for a VPAT: per ITI’s VPAT page, a free template that, once completed with testing results, “is referred to as an Accessibility Conformance Report (ACR)”. Writing one is separate work from the audit on this page. It sits in the same vendor review file as the MVSP baseline and a security questionnaire.

What goes wrong without it

These six are the failures I look for first in a generated interface. They are my working list, not a count of how often each appears. The “who is blocked” and “where in the flow” cells are my reading; the criterion numbers are WCAG 2.2’s.

None of these stops someone demoing the app with a mouse. The business symptom arrives later, and I’d describe it as a paperwork failure more than a technical one: a public-sector or enterprise buyer’s procurement form asks for conformance evidence, and there is nothing to send.

These are not rare mistakes. WebAIM’s Million report, which scans the home pages of the top 1,000,000 websites, found in February 2026 that 95.9% of home pages had detected WCAG 2 failures, with low contrast text, missing alternative text, missing form input labels, empty links and empty buttons among the most common. Those are detected failures only; the same report says “Absence of detected errors does not indicate that a page is accessible or conformant.”

How to do it: the scan, the keyboard walk, the screen reader, the fixes

A do-it-yourself audit of a small web app runs in four steps: scan the core pages and clear every automated finding, walk each core flow with the keyboard alone, repeat one flow with a screen reader, then fix and retest. Each pass finds what the one before it cannot, so the order matters.

The procedure below comes from W3C’s guidance, Chrome’s Lighthouse documentation and Apple’s and NV Access’s screen-reader guides, each named where it is used. You need Chrome, a keyboard and either a Mac or a Windows machine.

The automated pass: a free WCAG and 508 checker, taken to 100

An automated accessibility scan checks the rules a machine can decide, such as missing labels, low contrast and invalid ARIA, and Lighthouse reports the result as a score out of 100. A score of 100 means no scored audit failed on that page in that state. It does not mean the page is accessible.

Start in the browser; nothing here needs a terminal. Lighthouse is an open-source tool built into Chrome DevTools, and it can audit pages that require you to be signed in.

1. 01 Open Chrome, sign in to your app and go to the first core page. Open DevTools and click the Lighthouse tab.
2. 02 In the Lighthouse panel, leave only the Accessibility category ticked, keep the default Navigation mode, and click Analyze page load.
3. 03 Put the page into each state that matters (a form with its errors showing, a modal open, a menu open) and run Lighthouse again in Snapshot mode, which audits the page in the exact state it is in without reloading it.
4. 04 Fix every failed audit, starting with the ones that repeat across pages, and re-run until the Accessibility category reads 100 on every core page and state.
5. 05 Save each report with the page name and the date. The record at the end of this page is built from them.

Per Lighthouse’s accessibility scoring page, the score is a weighted average of the accessibility audits, each audit is pass or fail, and “a page doesn’t get points for partially passing an accessibility audit.” Chrome’s Lighthouse 6.0 release notes say Lighthouse uses the axe-core library to power the accessibility category. Products sold as ADA compliance checklist software, or as a free 508 compliance checker, run automated WCAG rules of the same kind, whatever the label on the box says (my reading).

Two second opinions are worth one extra run each. Microsoft’s Accessibility Insights for Web is an open-source extension for Chrome and Edge whose FastPass runs automated checks and a Tab stops helper for keyboard traps and tab order. WebAIM’s WAVE extension is the other. An overlay widget that promises compliance through one line of code does not change the underlying markup these tools test, so it fixes none of these findings (my reading).

This pass reads the Accessibility category only; how the score is weighted and what the rest of the report means are part of how to run a Lighthouse audit as a whole. The same report’s performance side belongs to Core Web Vitals for AI-built apps.

Keyboard only accessibility test: the walk through signup, checkout and the main task

A keyboard only accessibility test walks a real flow using six keys: Tab, Shift+Tab, Enter, Space, the arrow keys and Escape. It passes when every control can be reached and operated, focus is always visible, the order follows the screen, and nothing traps the keyboard.

Unplug the mouse, or push it out of reach and leave the trackpad alone. The keys should behave the way W3C’s keyboard interface practices and its pattern pages describe:

Walk signup, checkout and the main task, and mark each check pass or fail for each flow:

1. 01 Every control can be reached with Tab and operated with Enter, Space or the arrow keys (2.1.1 Keyboard).
2. 02 Focus can always leave a component using the keyboard; nothing holds it (2.1.2 No Keyboard Trap).
3. 03 The focus indicator is visible on every control (2.4.7 Focus Visible), and a focused control is never entirely hidden behind a sticky header or cookie banner (2.4.11 Focus Not Obscured (Minimum), new in WCAG 2.2).
4. 04 Focus moves in an order that preserves meaning and operability, which in practice means it follows the screen (2.4.3 Focus Order).
5. 05 Pages with long navigation offer a skip link or another way to bypass the repeated blocks (2.4.1 Bypass Blocks).
6. 06 Dialogs move focus inside when they open, keep Tab inside while open, close on Escape, and send focus back to the control that opened them.
7. 07 Custom selects, date pickers and the payment form can be completed without the mouse.
8. 08 Any bot challenge on signup can be passed using the keyboard alone.

A modal that keeps Tab inside itself is not a trap: W3C’s dialog pattern wraps focus from the last element back to the first, and Escape is the way out. If a challenge widget fails check 8, choosing a different challenge is part of dealing with bots submitting your signup form. The card fields inside the payment form belong to the payment provider, so test them and report a failure upstream rather than patching someone else’s iframe. Record pass or fail per check per flow; that log is evidence later.

A regulator’s record shows why the walk and the screen-reader pass exist. In a settlement agreement signed in April 2022, the United States said a Justice Department compliance review under Title III of the ADA found portions of CVS Pharmacy’s online COVID-19 vaccine registration portal were not accessible to some people with disabilities. Screen reader users met radio buttons, checkboxes and form fields “that are not labeled correctly”, and an insurance-entry interface that did not give them complete information or let them navigate the options. People who navigate without a mouse “would need to press the Tab key hundreds, or potentially thousands, of times to move past one control, would be stuck in the control, and would unexpectedly navigate to other controls that are hidden from view.” CVS expressly denied violating Title III and admitted no wrongdoing; the settlement agreement requires the vaccine content to conform to WCAG 2.1 AA, automated accessibility tests before scheduled releases, and testing by people with different disabilities every thirty days.

The lesson I take from it: a keyboard trap and an unlabeled control can stop a person partway through a booking, and the keyboard walk and the screen-reader pass are the tests built to meet them. The agreement itself pairs automated tests with testing by people with disabilities, not one in place of the other.

Mac VoiceOver commands and NVDA keys for the screen-reader pass

Mac VoiceOver commands start with the toggle, Command-F5, and the VO modifier, Control and Option held together. My working rule is that a screen-reader pass of one core flow needs about ten commands: next and previous item, activate, the rotor for headings and links, and pause speech. NVDA is a free screen reader for the same pass on Windows.

The one Mac VoiceOver shortcut to learn before anything else is that toggle. Apple also lists a Mac screen reader shortcut for keyboards with Touch ID: hold Command and quickly press Touch ID three times. The second shortcut worth learning is the one that pauses the voice: press Control and VoiceOver stops talking over the page until you press Control again. On Windows, the NVDA user guide describes NVDA as “a free and open source screen reader for the Microsoft Windows operating system”, with Insert or Numpad 0 as its modifier key.

The keys come from Apple’s VoiceOver general commands and the related navigation, interaction and search pages in Apple’s guide, and from NV Access’s guide. Of the VoiceOver controls, the rotor does the most work in an audit: open it with VO-U and step through its lists, such as Headings and Links, to see the page’s outline the way a screen-reader user meets it. NVDA’s guide lists browse mode in Firefox, Chrome and Edge, among other programs.

On each core flow, listen for four things. Every control announces a name and a role. Every input announces its label and, after a failed submit, its error. The page has one h1 and headings that outline it. A status message such as “Saved” or “Added to cart” is announced without focus moving to it (4.1.3 Status Messages). I’d allow about ten minutes per flow once the keys are familiar. Treat this pass as a smoke test: it catches the barriers a tester can hear on a first listen, and it is no substitute for testing with people who use a screen reader every day.

Digital accessibility examples: the six fixes that close the common findings

Digital accessibility examples in a web app are mostly six small code fixes: real buttons instead of clickable divs, a visible label tied to every input, text contrast of at least 4.5 to 1, a visible focus ring, focus moved into and out of dialogs, and error messages announced in text.

The first two fixes, plus a name for an icon-only button, look like this in plain HTML:

<!-- Before -->
<div class="btn" onclick="submitOrder()">Pay now</div>
<input type="email" placeholder="Email">
<button><svg aria-hidden="true">...</svg></button>

<!-- After -->
<button type="button" onclick="submitOrder()">Pay now</button>
<label for="email">Email</label>
<input id="email" type="email" placeholder="you@example.com">
<button type="button" aria-label="Close"><svg aria-hidden="true">...</svg></button>

The rule behind the first fix is W3C’s first rule of ARIA use: “If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.” When web accessibility developers say “semantic HTML”, they mean exactly that: the element that already carries the right name, role and keyboard behavior, so the browser does the work.

Contrast is the one to fix at the source. Change the gray in the theme tokens once and every screen that uses it changes with it. Focus is the same story: find the global CSS reset that removed the outline and put a visible style back. For whoever does the fixing, web.dev’s Learn Accessibility course, “An evergreen accessibility course and reference to level up your web development”, covers keyboard focus, color and contrast, forms and testing in depth. Alt text that survives image conversion belongs on the image optimization checklist for websites your team keeps.

An accessibility checklist for web apps, by flow

Copy this into the audit record; it doubles as the record’s table of contents.

How to verify it

An accessibility baseline holds when two results hold together: a score of 100 on an automated accessibility check of each core page, and a keyboard-only walk that completes signup, checkout and the main task. The evidence is the saved report per page and a short recording or log of the walk.

Each check below can fail, and each leaves something you can show a buyer.

1. 01 The Lighthouse Accessibility category reads 100 on each core page in each key state. Evidence: the saved report for each page, with its date and Lighthouse version.
2. 02 The keyboard-only walk completes signup, checkout and the main task with no mouse. Evidence: a screen recording or a step log with pass or fail per check.
3. 03 One flow is repeated with VoiceOver or NVDA, and every blocker it found is listed and fixed. Evidence: the notes and the commits that fixed them.
4. 04 An automated accessibility check runs in CI on the core pages and fails the build on a new violation. Evidence: one run on a branch that failed on a deliberately missing label, then passed once the label was restored.
5. 05 Checks 1 and 2 are re-run after any design-system or component-library change. Evidence: the dated reports from each re-run.

Setting up that CI pipeline is its own piece of delivery work; the check that matters here is that it fails when it should. What the finished record is, and is not: evidence of a baseline on named pages at a named WCAG version. It is not a conformance claim for the whole product, and it is not a VPAT. The same three flows are also the ones worth scripting when load testing a web application.

In the Production Hardening Sprint, deliverable 9.7 is verified this way: Score 100 on an automated accessibility audit of the core pages and complete a keyboard-only walk through signup, checkout, and the main task.

Where the sprint does this

Deliverable 9.7 of the Production Hardening Sprint brings the core flows to WCAG AA: keyboard navigation, contrast, labels, and focus order. Deliverable 9.5 runs Lighthouse on representative pages, implements performance and accessibility improvements, and delivers a passing result against recorded acceptance targets. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables. Both deliverables are listed in the published sprint scope.

Common questions about WCAG and web accessibility

What are the four types of accessibility?

The four I plan an audit around are visual, auditory, motor and cognitive needs; that grouping is my working one, not an official list. W3C’s own pages name auditory, cognitive, physical, speech and visual disabilities, and WCAG organizes its criteria by four principles instead: perceivable, operable, understandable and robust.

Can you get sued for not having accessibility on your website?

Yes, in the United States it can happen: since 1996 the Department of Justice has consistently taken the position that the ADA applies to web content, and its guidance says it is committed to using its enforcement authority on website accessibility. The guidance’s sample cases include an agreement with Miami University in Ohio resolving the United States’ lawsuit, which alleged that the university discriminated against students with disabilities by providing inaccessible web content and learning management systems. This is not legal advice; ask a lawyer which rules apply to your company.

What are the new WCAG standards for 2026?

WCAG 2.2 is still the current W3C Recommendation, dated 12 December 2024, and WCAG 3 remains a draft. W3C calls WCAG 3 “an incomplete draft that will change” and says it is “not expected to be a completed W3C standard for a few more years.” Its advice on preparing for WCAG 3 is to meet WCAG 2.2 success criteria now, and W3C’s WCAG 3 introduction carries the current status.

What are 5 examples of assistive technology?

Screen readers, screen magnifiers, speech recognition software, switches and refreshable braille displays are five, and each appears on W3C’s pages about how people use the web. W3C describes screen readers as reading web pages aloud for people who cannot read the text, and speech recognition software and selection switches as serving people who cannot use a keyboard or mouse.

Does Microsoft have an accessibility checker?

Yes. For web apps, Microsoft makes Accessibility Insights for Web, an open-source extension for Chrome and Edge that runs automated checks and a guided Tab stops test for keyboard access. Microsoft Office’s Accessibility Checker is a different tool for Word, Excel, PowerPoint, Outlook and OneNote files, not for websites.