Accessibility Audit Checklist

An inaccessible website exposes your business to costly ADA Title III lawsuits and locks out more than 1.3 billion people with disabilities worldwide. This free, interactive accessibility audit checklist lets you evaluate websites, web applications, and UI components against the latest WCAG 2.1 and WCAG 2.2 Level A and AA standards. Paste an HTML snippet to run instant client-side code checks, track your live compliance score across the four POUR principles (Perceivable, Operable, Understandable, Robust), view code remediation snippets for every failure, and export a ready-to-share audit report. Everything runs 100% privately in your browser with zero data transmission.

What is an accessibility audit checklist?

An accessibility audit checklist is an operational evaluation framework used by web developers, QA engineers, digital product managers, and compliance teams to verify that a website, web application, or digital component conforms to the Web Content Accessibility Guidelines (WCAG). WCAG is published by the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) and serves as the legal, regulatory, and technical benchmark for digital inclusion across the globe, including under the United States Americans with Disabilities Act (ADA Title III), Section 508 of the Rehabilitation Act, and the European Accessibility Act (EAA 2025).

Unlike automated browser extensions that scan single DOM snapshots in isolation, an audit checklist combines structured automated checks with mandatory manual testing. It evaluates visual contrast, keyboard navigation mechanics, screen reader compatibility, cognitive focus sequencing, and dynamic error recovery. This tool organizes the 24 most critical WCAG success criteria across the four foundational POUR principles, providing live compliance scoring, automated static code sniffing, actionable remediation code snippets, and ready-to-share audit reports.

Why automated scanners only catch 30% of accessibility defects

Automated accessibility scanning tools (such as Axe Core, Google Lighthouse, and Wave) are invaluable for catching low-hanging technical defects in continuous integration pipelines. However, published empirical studies consistently demonstrate that automated scanners can only detect between 25% and 40% of all WCAG violations. Relying solely on automated audits creates a dangerous illusion of legal compliance.

What automated tools can detect	What requires manual human evaluation
Whether an <img> element has an alt attribute	Whether the alt text accurately conveys the image’s contextual purpose, or if a decorative image should have an empty alt=""
Whether an input has an associated <label>	Whether form instructions and validation error messages clearly explain how a user with cognitive impairments can fix formatting mistakes
Computed CSS foreground vs. background color contrast	Whether text rendered over dynamic background gradients, video backgrounds, or photographic heroes remains legible in all states
Presence of tabindex="0" or role="button"	Whether keyboard focus is trapped inside a custom modal dialog or whether focus order matches logical reading narrative
Presence of standard ARIA attribute strings	Whether dynamic screen reader announcements via aria-live convey the right information at the right time without interrupting user flow

True accessibility conformance requires combining automated syntax validation with disciplined manual testing using assistive technologies, keyboard-only traversal, and browser zoom stress testing.

The 4 POUR principles explained

The Web Content Accessibility Guidelines are built upon four fundamental design principles known by the acronym POUR: Perceivable, Operable, Understandable, and Robust. If a digital experience fails any single principle, users with specific disabilities are blocked from using the software.

1. Perceivable: Information must be presentable in multiple sensory modalities

Content cannot be invisible to all of a user’s senses. If information is presented visually through images, diagrams, or video, equivalent textual alternatives and synchronized captions must be provided for screen reader users and individuals with auditory disabilities. Perceivable criteria also mandate sufficient visual distinction, including a minimum 4.5:1 color contrast ratio for body text, a 3:1 ratio for user interface borders and icons, and flexible layouts that reflow cleanly at 320px width without horizontal scrolling.

2. Operable: Every interaction must work without a mouse or precise timing

User interface controls must be fully operable through multiple input mechanisms, especially the keyboard alone. Users with motor disabilities, repetitive strain injuries, or blindness cannot manipulate a mouse pointer. Operable criteria mandate that every interactive button, link, accordion, tab, and form control can receive focus, never trap the user, provide an unmistakable high-contrast focus indicator, and offer bypass mechanisms like “Skip to main content” links. WCAG 2.2 also mandates minimum target sizes of 24 by 24 pixels to prevent accidental taps on mobile touchscreens.

3. Understandable: Predictable interfaces, clear language, and robust error recovery

Both the information presented and the operation of the user interface must be coherent and predictable. Webpages must declare their natural language via <html lang="en"> so screen readers load the correct pronunciation dictionaries. Input fields must not trigger unexpected page reloads or context shifts upon receiving focus. When users make validation mistakes, the interface must identify the specific erroneous field in text and provide actionable correction guidance before submission.

4. Robust: Clean markup, valid semantics, and future-proof assistive tech compatibility

Code must be written cleanly so current and future user agents—including screen readers, braille displays, speech input engines, and alternative navigators—can parse and interpret the DOM reliably. While native semantic HTML elements (such as <button>, <nav>, and <dialog>) handle accessibility automatically, custom widgets must explicitly wire ARIA roles, states (such as aria-expanded and aria-checked), and dynamic announcements via role="status".

WCAG 2.1 vs. WCAG 2.2: What changed?

WCAG 2.2 became an official W3C Recommendation in October 2023. It builds directly on WCAG 2.1 by adding nine new success criteria targeted at mobile devices, cognitive disabilities, and keyboard visibility, while officially obsoleting one legacy criterion:

1. 4.1.1 Parsing was officially obsoleted: Because modern HTML5 parsers natively handle malformed markup and unclosed tags, WCAG 4.1.1 is now superseded by modern browser specifications.
2. 2.4.11 Focus Not Obscured (Minimum) (Level AA): When an interactive element receives keyboard focus, it must not be entirely hidden beneath sticky headers, floating cookie banners, or fixed footers.
3. 2.5.7 Dragging Movements (Level AA): Any feature relying on dragging (such as sliders, Kanban drag-and-drop, or reordering lists) must provide a simple single-pointer alternative (such as up/down buttons or click-to-move menus).
4. 2.5.8 Target Size (Minimum) (Level AA): Interactive pointer targets must measure at least 24 by 24 CSS pixels, or provide sufficient clear space around them so users with tremors or large fingertips do not trigger accidental clicks.
5. 3.3.7 Redundant Entry (Level A): In multi-step checkout funnels and onboarding flows, users must not be forced to re-enter the same information previously provided in the same session (e.g., shipping and billing address auto-population).
6. 3.3.8 Accessible Authentication (Minimum) (Level AA): Login flows must not rely solely on cognitive function tests (such as memorizing complex passwords or solving visual math captchas) without offering password manager auto-fill, copy-paste support, or WebAuthn biometrics.

How this checklist calculates your compliance score

Rather than treating all accessibility guidelines as equal checkboxes, this tool employs a mathematically rigorous, severity-weighted scoring algorithm. Each criterion is assigned an objective weighting based on its real-world impact on disabled users and ADA Title III litigation precedence:

Severity Tier	Weight	Criteria Examples	Impact on Users
Critical	4 points	Keyboard Accessible (2.1.1), No Keyboard Trap (2.1.2), Info & Relationships (1.3.1), Error Identification (3.3.1), Name/Role/Value (4.1.2)	Complete blocker. The user cannot navigate the page, submit forms, or exit dialogs.
Serious	3 points	Non-text Alt Content (1.1.1), Video Captions (1.2.2), Contrast Minimum (1.4.3), Focus Visible (2.4.7), Non-text Contrast (1.4.11)	Significant barrier. Content is illegible or essential information is lost without workaround.
Moderate	2 points	Page Titled (2.4.2), Link Purpose (2.4.4), Target Size (2.5.8), Language of Page (3.1.1), Input Autocomplete (1.3.5)	Usability friction. Causes orientation confusion, touchscreen mis-clicks, or slower task completion.
Minor	1 point	Text Spacing Overrides (1.4.12), Error Suggestions (3.3.3)	Visual polishing and layout adaptability edge cases.

The overall compliance percentage is calculated as:

Compliance Score = (Earned Points on Passed Criteria / Total Applicable Points) × 100

Treatment of Not Applicable (N/A) items: If a web page does not contain video media or auto-playing banners, marking 1.2.2 Captions or 2.2.2 Pause/Stop as “N/A” correctly removes them from both the numerator and the denominator. This ensures scores reflect genuine compliance without penalizing media-free static pages or artificially inflating numbers.

Critical Blocker Enforcement: If any single Critical criterion is marked as “Fail” (such as an un-exitable keyboard trap or unlabelled checkout form controls), the overall compliance status cannot achieve Grade A or B, regardless of how many other minor items pass. This directly mirrors how legal auditors and DOJ enforcement officers evaluate digital discrimination claims.

Step-by-step: How to perform a manual accessibility audit

1. Step 1 — Automated static markup review: Paste your HTML component into the tool above or run an automated scanner. Fix low-hanging errors: missing alt attributes on <img>, missing <html lang>, duplicate DOM ids, and unassociated form inputs.
2. Step 2 — Unplug the mouse for a keyboard-only walkthrough: Press Tab to move forward, Shift+Tab to move backward, Enter to activate links and buttons, Space to check boxes, and Esc to close dialogs. Verify every interactive control shows a distinct focus ring, no keyboard traps exist, and a “Skip to main content” link appears immediately on page load.
3. Step 3 — Screen reader audit with NVDA or VoiceOver: Turn on a native screen reader (NVDA on Windows with Chrome/Firefox, or VoiceOver on macOS with Safari). Navigate through headings (H), landmarks (D), and links (K). Confirm that all buttons announce meaningful names (not “button, unlabelled”) and that modal openings shift focus inside the dialog.
4. Step 4 — Viewport reflow & 400% zoom testing: Open browser developer tools and resize the responsive viewport down to 320 CSS pixels width, or zoom desktop text to 400% at 1280px. Confirm that all content reflows vertically without requiring horizontal scrolling, and that no fixed-height cards truncate text.
5. Step 5 — Color contrast and grayscale check: Sample body copy, muted captions, button labels, and input borders with an eyedropper. Verify body copy achieves 4.5:1 contrast against white backgrounds, large headlines achieve 3:1, and form borders achieve 3:1. Switch your display to grayscale to verify validation states do not depend on color alone.
6. Step 6 — Form error injection: Intentionally submit required forms with empty and invalid data. Ensure error messages appear in written text, aria-invalid="true" is toggled on the field, and screen readers immediately announce the corrective instructions.

Common accessibility barriers and how to fix them (with code examples)

1. Decorative images vs. informative graphics

Developers frequently omit the alt attribute entirely or populate it with file names like alt="banner1.jpg". Purely decorative elements must carry an empty alt="" or aria-hidden="true" so screen readers ignore them:

<!-- WRONG: Screen reader reads raw filename or image path -->
<img src="/images/hero-abstract.png">

<!-- CORRECT: Purely decorative background illustration -->
<img src="/images/hero-abstract.png" alt="">

<!-- CORRECT: Informative graphic with contextual summary -->
<img src="/images/q3-churn-graph.png" alt="Line chart showing customer churn decreasing from 4.2% to 1.8% over Q3">

2. Explicit form label associations

Placeholder text is not an accessible label. Placeholders disappear when the user starts typing, are ignored by some assistive technologies, and frequently fail 4.5:1 contrast standards. Always use explicit <label for="id"> tags:

<!-- WRONG: Placeholder used as the only visual label -->
<input type="email" placeholder="Enter your email">

<!-- CORRECT: Explicitly associated label with input and error announcement -->
<label for="user-email">Work Email Address <span aria-hidden="true">*</span></label>
<input id="user-email" type="email" name="email" autocomplete="email" required aria-describedby="email-hint">
<p id="email-hint">We will send your verification code to this address.</p>

3. Clickable <div>s vs. native <button>s

Binding an onclick listener to a <div> or <span> breaks keyboard navigation. Native <button> elements automatically handle Enter and Space activation, receive keyboard focus by default, and announce their role to screen readers:

<!-- WRONG: Unfocusable div without keyboard listeners or button role -->
<div class="custom-btn" onclick="submitOrder()">Complete Purchase</div>

<!-- CORRECT: Native HTML button with semantic role and native focus -->
<button type="button" class="btn btn-primary" onclick="submitOrder()">Complete Purchase</button>

Legal requirements: ADA Title III, Section 508, and the European Accessibility Act

Digital accessibility is no longer merely a best practice; it is a strict legal requirement across major global markets:

• United States (ADA Title III): Federal courts and the U.S. Department of Justice (DOJ) consistently interpret Title III of the Americans with Disabilities Act as applying to commercial websites and web apps. Over 4,000 federal web accessibility lawsuits are filed annually against businesses of all sizes, with courts overwhelmingly adopting WCAG 2.1 Level AA as the legal measure of reasonable accommodation.
• Section 508 of the Rehabilitation Act: Mandates that all electronic and information technology procured, developed, or used by federal agencies, contractors, and federally funded educational institutions must conform to WCAG 2.0/2.1 Level AA. Non-compliant vendors cannot bid on federal contracts.
• European Accessibility Act (EAA 2025): Directive (EU) 2019/882 comes into binding commercial enforcement on June 28, 2025. It mandates digital accessibility across all e-commerce stores, SaaS applications, banking services, and digital products operating within the 27 EU member states, carrying substantial financial penalties for non-compliant software.

Frequently asked questions (FAQs)

Does passing an automated accessibility scan guarantee legal compliance?

No. Automated testing tools only evaluate between 25% and 40% of WCAG criteria. Automated tools cannot determine whether alternative text accurately reflects image context, whether focus order makes sense, whether captions match spoken dialogue, or whether keyboard traps exist in complex widgets. A legally defensible audit requires human verification with screen readers and keyboard navigation.

What is the difference between WCAG Level A, AA, and AAA?

WCAG criteria are structured into three conformance tiers. Level A establishes the bare minimum baseline for essential accessibility (such as keyboard operability and text alternatives); failing Level A prevents users from accessing the content. Level AA is the universal legal and commercial benchmark required by the ADA, Section 508, and the European Accessibility Act. Level AAA represents the highest level of accessibility (including sign language interpretation and enhanced contrast), which is recommended for specialized applications but not legally mandated for general commercial websites.

Can third-party accessibility overlay widgets replace an audit?

No. Accessibility overlay widgets and AI plugins that inject automated styling over inaccessible websites do not make a website compliant. More than 800 lawsuits were filed in the United States against websites utilizing accessibility overlays in recent years. Overlays often interfere with users’ personal assistive technology (such as NVDA or JAWS) and fail to repair underlying semantic DOM defects.

How often should our organization perform an accessibility audit?

Enterprise teams should integrate automated testing into continuous integration (CI/CD) pipelines on every pull request to catch structural syntax errors early. A comprehensive manual audit using this checklist should be conducted prior to major product releases, design system overhauls, and at least once annually for ongoing legal defense.