26 items

Website Accessibility Compliance

A technical WCAG audit checklist with exact success criteria, contrast thresholds, keyboard test scripts, and screen reader verification steps — everything needed to reach and maintain Level AA compliance. For more background and examples, see the guidance below; for built-in tools and options, use the quick tools guide.

Author

Checklistify Editorial Team

Last Updated

Checklist Items

0 done•26 left•5 of 6 sections collapsed

Provide descriptive alt text for all informative images and empty alt (alt='') for decorative images.

WCAG 1.1.1 (Level A). Alt text should convey the same information or purpose as the image to someone who cannot see it. For informational images, describe the content specifically: 'Bar chart showing Q3 revenue increasing 23% year-over-year' conveys far more than 'chart.' For functional images used as buttons, describe the action: 'Submit form' for a submit icon. For linked images, describe the destination: 'Visit our Facebook page.' For decorative images — spacers, visual flourishes, background textures — use empty alt text (alt='') so screen readers skip the element entirely. For complex images like charts or diagrams, consider linking to a longer text alternative via aria-describedby or a visible caption below the image. Common anti-patterns: alt text saying 'image of' or 'photo of' (redundant — screen readers already announce element type), filename-based alt text like 'hero_banner_v2.jpg', and keyword-stuffed alt text written for SEO rather than user comprehension.

Verify the page uses a logical heading hierarchy — one H1, with H2 through H6 in correct descending order.

WCAG 1.3.1 (Level A). Screen reader users frequently navigate pages exclusively via heading structure — jumping heading-to-heading to understand a page's organization and reach the section they need, without reading content linearly. A valid hierarchy: one H1 per page (the main page title), H2 for major sections, H3 for subsections within H2 sections, and so forth. Common violations: skipping heading levels (H1 directly to H3, bypassing H2), using heading tags purely for visual styling (choosing H3 because 'the font size looks right'), and placing multiple H1 tags on a single page. Validation method: install the headingsMap browser extension (Chrome and Firefox) to visualize the heading outline of any page — the outline should read like a logical table of contents, independent of the page's visual design.

Write descriptive link text that makes sense read in isolation, without surrounding context.

WCAG 2.4.4 (Level A). Screen reader users can pull up a list of all links on a page — extracted from their surrounding context. Link text reading 'click here,' 'read more,' or 'learn more' becomes completely meaningless in this isolated list. A screen reader navigating by links might announce: 'Link: click here. Link: click here. Link: read more. Link: read more.' Fix: rewrite link text to describe the destination or action — 'Read the WCAG 2.1 accessibility guidelines,' 'Download the 2024 annual report (PDF, 2.3 MB),' 'View product pricing.' If visual design requires generic link text that cannot be changed, add visually hidden supplementary text using a CSS .sr-only class, or use aria-label on the anchor element — the aria-label value replaces (not supplements) the visible link text for screen readers, so make it complete and self-explanatory.

Set the primary language of the page on the HTML element using the lang attribute.

WCAG 3.1.1 (Level A). Screen readers use the lang attribute to select the correct pronunciation engine, voice, and accent model. Without it, a screen reader may apply the wrong language — pronouncing English with French phonemes, for instance — making content significantly harder to understand for listening users. The fix is a single attribute on one element: <html lang='en'>. For multilingual pages, set the primary language on the HTML element, then apply lang attributes to individual elements where the language switches: <p lang='fr'>Bonjour</p>. Common language codes: 'en' (English), 'es' (Spanish), 'fr' (French), 'de' (German), 'ja' (Japanese), 'zh' (Chinese). Regional BCP 47 subtags — 'en-GB' for British English, 'pt-BR' for Brazilian Portuguese — enable more precise pronunciation in advanced screen readers.

Provide a unique, descriptive page title in the <title> element of every page on the site.

WCAG 2.4.2 (Level A). The page title is the first thing a screen reader announces when a page loads — before any content, navigation, or headings. It also appears in browser tabs, bookmarks, and browser history. Requirements: each page must have a unique title (identical titles across pages make multi-tab navigation and browser history unusable for all users), the title must describe the specific page content, and it should follow the pattern '[Page Content] — [Site Name]' for inner pages. Well-formed examples: 'Contact Us — Acme Corporation' (inner page), 'Product Pricing — Acme Corporation' (pricing page), 'Acme Corporation — Industrial Equipment Manufacturer' (homepage). Common violation: every page on the site sharing the same generic title such as 'Home | My Website.'

Use semantic landmark elements — <nav>, <main>, <header>, <footer>, <aside> — to structure the page.

WCAG 1.3.1 (Level A) and WCAG 2.4.1 (Level A). Landmark elements create a navigable map of the page that screen reader users can jump between directly — most screen readers provide a keyboard shortcut to list and navigate landmarks, letting users skip directly to the main content, navigation, or a complementary sidebar without reading through everything in between. Required landmarks for most pages: <header> (maps to the 'banner' landmark role, used for the site header), <nav> (navigation landmark — use aria-label to distinguish multiple nav elements: aria-label='Primary navigation' vs aria-label='Footer navigation'), <main> (primary content landmark — only one per page), <footer> (contentinfo landmark). Avoid using <div> and <span> for structural regions when semantic elements exist. If a custom element must serve as a landmark, add the appropriate ARIA role explicitly: <div role='navigation' aria-label='Breadcrumb'>.

Do not rely on color alone to convey information — pair color with a text label, icon, or pattern.

WCAG 1.4.1 (Level A). Approximately 8% of men and 0.5% of women have some form of color vision deficiency — red-green color blindness being the most common. If a required form field is indicated solely by a red border, or an error state communicated only by turning text red, these users receive no indication at all. Every use of color to convey meaning must be accompanied by a second, non-color indicator. For form validation: use a colored border plus an error icon plus a text error message. For charts with multiple data series: use different colors and different line patterns (dashed, dotted, solid) or direct data labels. For status indicators: use color and a text label ('Active,' 'Inactive') or a distinct icon shape. Testing tool: Chrome DevTools 'Rendering' panel (More Tools → Rendering → Emulate vision deficiencies) simulates deuteranopia, protanopia, tritanopia, and achromatopsia on any page in real time.

Add a visible skip navigation link as the first focusable element on every page.

WCAG 2.4.1 (Level A). Without a skip link, a keyboard user visiting a page with a 40-item navigation menu must Tab through all 40 items before reaching the main content — on every page load. The skip link solution: add an anchor element as the very first element inside the <body> tag, pointing to an id on the main content container: <a href='#main-content' class='sr-only focus:not-sr-only focus:absolute focus:top-4 focus:left-4 focus:z-50 focus:p-2 focus:bg-card focus:text-foreground'>Skip to main content</a>. The .sr-only class hides the link visually until it receives keyboard focus — at that point it becomes visible and positioned, a pattern sighted keyboard users have come to recognize. The link target must carry a matching id: <main id='main-content'>. Test by pressing Tab immediately after page load — the skip link should be the very first element to receive focus.

Verify text and background color combinations meet WCAG AA contrast ratios — 4.5:1 for normal text, 3:1 for large text and UI components.

WCAG 1.4.3 (Level AA). Contrast ratio is calculated from the relative luminance of the foreground and background colors — 1:1 means identical colors (no contrast), 21:1 is maximum (black on white). Thresholds: 4.5:1 for normal text (below 18pt regular or 14pt bold), 3:1 for large text (18pt regular or 14pt bold and above), 3:1 for interactive UI components such as input borders and button outlines, and 3:1 for meaningful graphical elements like chart lines or status icons. Common failure: light gray body text on white — #767676 on white yields exactly 4.48:1, just below the 4.5:1 threshold. Testing tools: WebAIM Contrast Checker at webaim.org/resources/contrastchecker (enter foreground and background hex values); the TPGi Colour Contrast Analyser (free desktop app with an eye-dropper for picking colors from anywhere on screen); Chrome DevTools accessibility panel, which shows the computed contrast ratio for any element selected in the inspector. For AAA compliance: 7:1 for normal text, 4.5:1 for large text.

Test that all interactive elements — links, buttons, form controls, modals, and dropdown menus — are keyboard accessible.

WCAG 2.1.1 (Level A). Keyboard accessibility enables use by people who cannot operate a mouse (motor disabilities), power users, and provides the infrastructure on which screen reader navigation is built. Manual test procedure: set the mouse aside and use only Tab, Shift+Tab, Enter, Space, Escape, and arrow keys to complete the site's primary user tasks. Every interactive element must be reachable via Tab. Buttons and links must activate via Enter. Buttons must also activate via Space. Modals must trap focus inside when open — Tab inside an open modal must cycle through modal controls only, not the page behind it. Escape must close modals, dropdowns, and tooltips. Arrow keys must navigate within components designed for them: radio button groups, dropdown option lists, date picker calendars, tab panels. Common failures: interactive <div> elements that aren't keyboard focusable (use <button> instead, or add tabindex='0' plus keyboard event listeners), modals that don't trap focus, and hover-only dropdown menus with no keyboard equivalent.

#10

Verify the keyboard focus indicator is visually clear at all times — never suppress the focus outline without replacing it.

WCAG 2.4.7 (Level AA). The focus indicator — typically a colored ring or outline — is a sighted keyboard user's only signal of which element is currently active. CSS that removes this (outline: none; or outline: 0;) without providing a custom replacement makes keyboard navigation nearly impossible for sighted keyboard users. If the browser's default focus ring conflicts with your design: implement a custom high-visibility focus indicator using the :focus-visible CSS pseudo-class, which applies during keyboard navigation but not after mouse clicks — resolving the common complaint that focus outlines appear after clicking buttons. A compliant custom indicator: at minimum 2px solid, the indicator color must meet 3:1 contrast ratio against adjacent colors. WCAG 2.2 introduced Success Criterion 2.4.11 Focus Appearance (Level AA), which additionally specifies minimum focus indicator area and contrast — check this for new builds targeting WCAG 2.2.

#11

Confirm users can resize text to 200% without loss of content, functionality, or horizontal scrolling.

WCAG 1.4.4 (Level AA). Test using the browser's text-only zoom setting (in Firefox: View → Zoom → Zoom Text Only, then Ctrl+Plus to 200%) or operating system text scaling. Verify at 200%: all text remains readable, no content is clipped or hidden by fixed-height containers, no text overlaps other content, and no horizontal scrollbar appears at standard viewport widths. Root causes of failure: fixed-height containers that clip overflowing text (use min-height instead), text sized in px units (use rem or em so text responds to browser zoom settings), and text inside absolutely or fixed-positioned elements that overlap at larger sizes. Distinguish from WCAG 1.4.10 (Reflow): 1.4.4 concerns text-only scaling; 1.4.10 requires that content reflows to a single column at 320 CSS pixels wide, which addresses full browser zoom.

#12

Ensure no content on the page flashes more than 3 times per second.

WCAG 2.3.1 (Level A). Flashing content — animated GIFs, video clips, CSS animations, JavaScript-driven effects — can trigger photosensitive seizures in users with photosensitive epilepsy. The threshold: content that flashes more than 3 times per second at sufficient size and contrast is prohibited under WCAG. 'Sufficient size' approximates 10% of the visual field at typical viewing distance — a fairly large region on a standard desktop monitor. Red flashes carry a lower threshold than other colors due to their particular risk profile. Testing tool: the Photosensitive Epilepsy Analysis Tool (PEAT, free from the Trace R&D Center) analyzes video files for seizure risk. For CSS and JavaScript animations: honor the prefers-reduced-motion media query (@media (prefers-reduced-motion: reduce)) to disable or replace animations for users who have requested reduced motion in their operating system settings — this addresses both WCAG 2.3.1 and broader cognitive and vestibular accessibility concerns.

#13

Associate a visible label with every form control using the <label> element's for attribute or by wrapping the input.

WCAG 1.3.1 and 3.3.2 (Level A). Screen readers announce the programmatically associated label when a form field receives focus. Without one, the field is announced only as 'edit text' or 'text field' — no indication of what the user is expected to enter. Three correct association methods: (1) for/id pairing — <label for='email'>Email address</label><input id='email' type='email'> — the for attribute value must exactly match the input's id attribute. (2) Wrapping — <label>Email address<input type='email'></label> — the label wraps the input, creating an implicit association. (3) aria-label attribute — <input type='email' aria-label='Email address'> — for cases where no visible label is present. Critical failure pattern: using placeholder text as a label substitute. Placeholder text disappears the moment the user starts typing, leaving no visible reference for what the field contains — a severe usability problem for users with memory or cognitive disabilities, and a WCAG failure for all users.

#14

Provide specific, actionable error messages when form validation fails — programmatically associated with the relevant field.

WCAG 3.3.1 (Level A) and 3.3.3 (Level AA). Error messages must: identify which field is in error, explain what went wrong, and where feasible suggest how to correct it. Good example: 'Email address must include an @ sign — for example: name@domain.com.' Bad example: 'Invalid input.' Programmatic association ensures screen readers announce the error: add aria-describedby on the input element referencing the error's id, and add role='alert' to the error element so it is announced immediately when it appears without the user needing to navigate to it. Implementation: <input aria-describedby='email-error' aria-invalid='true'><span id='email-error' role='alert'>Email must include an @ sign — for example: name@domain.com</span>. Additional requirement (WCAG 1.4.1): error states must never be indicated by color alone — always accompany a colored border or highlighted field with an icon and a text message.

#15

Group related form controls using <fieldset> and <legend> — especially radio buttons and checkboxes.

WCAG 1.3.1 (Level A). When a screen reader announces a radio button or checkbox, it reads the control's visible label — but without a fieldset/legend grouping, it provides no context about what question or category the control belongs to. Without grouping, the announcement is: 'Yes, radio button.' With correct grouping, it becomes: 'Would you like to receive marketing emails? Yes, radio button, 1 of 2.' Implementation: <fieldset><legend>Would you like to receive marketing emails?</legend><label><input type='radio' name='marketing' value='yes'>Yes</label><label><input type='radio' name='marketing' value='no'>No</label></fieldset>. The fieldset/legend pattern applies to any group of form controls sharing a common question or category: shipping address fields (legend: 'Shipping Address'), payment method selectors, permission toggles. For standalone, clearly labeled inputs (a single email field with its own visible label), fieldset/legend is unnecessary and would add verbosity without clarity.

#16

Add autocomplete attributes to all form fields that collect personal information.

WCAG 1.3.5 (Level AA). The autocomplete attribute signals browsers and password managers to automatically populate fields with saved values — critically important for users with motor disabilities (reduces required keystrokes), cognitive disabilities (reduces memory load), and users employing switch access or other alternative input methods (reduces the time cost of each character). Required values for common personal data fields: autocomplete='name' (full name), autocomplete='given-name' (first name), autocomplete='family-name' (last name), autocomplete='email', autocomplete='tel', autocomplete='street-address', autocomplete='postal-code', autocomplete='country', autocomplete='cc-number' (card number), autocomplete='cc-exp' (expiration date), autocomplete='new-password' or autocomplete='current-password'. The complete list of valid token values is defined in the HTML Living Standard. Setting autocomplete='off' on personal data fields to force manual entry fails this criterion — there are very few legitimate reasons to disable autocomplete for personal information.

#17

Provide synchronized captions for all pre-recorded video content.

WCAG 1.2.2 (Level A). Captions benefit deaf and hard-of-hearing users primarily, but also people watching in noise-sensitive environments, non-native speakers, and users who absorb information better through reading. Caption requirements: synchronized (captions must appear at the same time as the corresponding speech), complete (all dialogue and important non-speech audio — [laughter], [applause], [door closes], [music playing]), and accurate. Auto-generated captions from YouTube, Zoom, and Otter.ai typically achieve 80–90% accuracy — sufficient for drafting, not for publication. Proper nouns, technical terms, and low-audio-quality recordings degrade accuracy significantly. Always review and correct auto-generated captions before publishing. Standard caption file formats: SRT (SubRip Text) and WebVTT (.vtt) — both plain text files with timestamps, supported by HTML5 video elements and most major video hosting platforms.

#18

Provide a full text transcript for all audio-only content — podcasts, recordings, and interviews.

WCAG 1.2.1 (Level A). A transcript is the complete text equivalent of audio content — providing access for deaf users, users in environments where audio isn't practical, and users who process text faster than real-time audio. Transcript requirements: include all spoken content, identify speakers where relevant, and note meaningful non-speech audio such as [laughter] or [applause]. Unlike captions, transcripts are standalone text documents — they can be published as a page section below the audio embed, linked as a downloadable file, or provided in a collapsible panel. Transcripts carry a significant secondary SEO benefit: audio content is not crawlable by search engines, so a full transcript makes the content's complete value searchable and can substantially increase organic traffic from long-tail queries that appear verbatim in the conversation. Auto-transcription tools: Whisper (OpenAI, free and open-source, self-hostable), Otter.ai, Descript — always review accuracy before publishing.

#19

Provide audio description or a full text alternative for pre-recorded video that contains visual-only information.

WCAG 1.2.5 (Level AA). Audio description provides narration of visual information that appears on screen but is not conveyed in the existing audio track — the actions, on-screen text, facial expressions, scene changes, and visual events that a blind viewer would otherwise miss entirely. Common examples requiring audio description: a cooking video that shows ingredients added without narrating what they are; a software tutorial that demonstrates UI interactions without describing what is happening on screen; a recorded presentation where slides contain text not read aloud. Implementation options: (1) create a separate video file with added audio description narration woven into pauses in the existing audio; (2) produce an extended description version where video playback pauses to allow narration of dense visual content; (3) publish a full text alternative that describes all visual content in writing. WCAG 1.2.3 (Level A) allows a full text alternative in lieu of audio description — satisfying both 1.2.3 and 1.2.5 with a detailed written transcript is permissible and often the most practical path.

#20

Use native HTML elements before reaching for ARIA — apply ARIA only to genuinely custom components with no HTML equivalent.

WCAG 4.1.2 (Level A). The W3C ARIA specification's own first rule: 'If you can use a native HTML element or attribute with the semantics and behavior you require, instead of re-purposing an element and adding an ARIA role, state, or property to make it accessible, then do so.' Native HTML elements carry built-in keyboard behavior, focus management, and accessibility semantics that browsers have refined for decades. A <button> element is keyboard focusable, activatable via both Enter and Space, announced as 'button' by screen readers, and styled by OS conventions — all without a single line of JavaScript. A <div role='button' tabindex='0'> replicates some of this manually and is more fragile — commonly missing Space key activation, no OS-level styling, no automatic form association. Reserve ARIA for components with no native HTML equivalent: custom comboboxes, disclosure widgets, carousel regions, tree views, custom tab panels. Incorrect ARIA actively harms users — a role applied to an element that doesn't implement the corresponding keyboard interaction misleads screen reader users into expecting behavior that isn't there.

#21

Implement aria-live regions for dynamic content that updates without a full page reload.

WCAG 4.1.3 (Level AA). When content updates dynamically — a success message appears after form submission, a notification arrives, a cart item count changes, live search results update — screen reader users receive no indication of the change unless it is explicitly announced. The mechanism: add aria-live='polite' to the container that will receive dynamic updates. 'Polite' means the screen reader waits until the user finishes their current reading before making the announcement — appropriate for non-urgent status messages. Use aria-live='assertive' only for time-critical alerts (a session expiring in 60 seconds) — it interrupts the user immediately. For status messages specifically, WCAG 4.1.3 requires that messages confirming successful actions (form submitted, item added to cart, filter results count) are surfaced to screen readers without the message element receiving focus. Use role='status' (equivalent to aria-live='polite') for confirmations and role='alert' (equivalent to aria-live='assertive') for errors. Common mistake: using aria-live on elements that already receive focus — focus movement itself notifies the screen reader, making aria-live redundant and potentially causing double announcements.

#22

Run an automated accessibility scan using WAVE or Axe DevTools as a first-pass audit before manual testing.

Automated tools reliably detect approximately 30–40% of WCAG success criteria — those that can be algorithmically verified without human judgment. The most reliable free tools: WAVE (browser extension from WebAIM — webaim.org/resources/wave) overlays a visual report directly on the page showing errors (red icons), alerts (yellow icons), and structural information (green/blue icons) in context; Axe DevTools (free browser extension from Deque, available for Chrome and Firefox) integrates with browser DevTools and reports each issue with the specific WCAG criterion reference, severity, and remediation guidance; Lighthouse (built into Chrome DevTools — open DevTools, select the Lighthouse tab, run an Accessibility audit) provides a scored report with a categorized issue list. What automated tools reliably catch: missing alt text, missing form labels, insufficient color contrast, missing page language, missing document title, duplicate id attributes, empty links. What automated tools cannot catch: whether alt text is accurate and descriptive, whether the focus order is logical, whether keyboard navigation through a custom component is usable, and whether the reading order matches the visual layout.

#23

Perform keyboard-only navigation testing — complete all primary user tasks using only Tab, Shift+Tab, Enter, Space, Escape, and arrow keys.

Keyboard testing reveals a class of failures that no automated tool detects. Illogical focus order: Tab moves focus in a sequence that jumps erratically rather than following the visual or logical reading flow. Focus traps: Tab becomes stuck inside a component with no exit route — distinct from intentional focus trapping inside modals, which is required correct behavior. Missing keyboard interactions: a custom dropdown that opens only on mouse hover with no keyboard trigger. Broken modal behavior: focus not programmatically moved to the modal on open, page content accessible behind an open modal, Escape does not close the modal. Systematic keyboard test procedure: starting from the browser address bar, Tab through every interactive element on the page in order. Verify every link, button, and form control is reachable; every element activates correctly; no Tab gets stuck; dropdown menus open and accept arrow key navigation; form submission completes without a mouse. Document every element that requires mouse interaction — each instance is a WCAG 2.1.1 failure and must be remediated.

#24

Test with a screen reader — VoiceOver (macOS/iOS, built-in) or NVDA (Windows, free) — to verify the experiential quality of the page for blind users.

Screen reader testing reveals the experiential reality of the site for non-sighted users — it catches issues that automated tools and keyboard testing both miss, including whether announced content is accurate, complete, and logically ordered. Getting started: VoiceOver on Mac activates with Command+F5 (or System Settings → Accessibility → VoiceOver); it pairs with Safari for best results. NVDA (free download at nvaccess.org) runs on Windows with Firefox or Chrome. Essential screen reader test script: load the page and confirm the page title is announced immediately; press H to navigate by headings (NVDA shortcut) and verify the heading structure matches the visual layout; press K to navigate by links and confirm all link text is descriptive and unambiguous without surrounding context; Tab through all form fields and confirm each label is announced clearly; deliberately trigger a form validation error and confirm the error is announced without needing to navigate to it. The learning curve is real — budget at least an hour of practice before attempting a meaningful audit. Even an hour of screen reader experience produces results that no automated tool can replicate.

#25

Verify that page content reflows to a single column at 320 CSS pixels wide without horizontal scrolling.

WCAG 1.4.10 (Level AA). Reflow ensures that users who require extreme magnification — typically 400% browser zoom — can read all content in a single scrolling direction without horizontal scrolling. At 400% zoom on a 1280px-wide monitor, the effective viewport is 320 CSS pixels — equivalent to a narrow mobile screen. Testing method: in Chrome DevTools, open the device toolbar (Ctrl+Shift+M on Windows, Cmd+Shift+M on Mac) and manually set the viewport width to 320px; alternatively, zoom the browser to 400% on a 1280px monitor and check for horizontal scrollbars. All content must remain accessible: no text clipped by overflow:hidden containers, no absolutely positioned elements pushed off screen, all navigation accessible (a hamburger menu pattern is acceptable at this width). Common failures: fixed-width layouts that don't scale, data tables that require horizontal scrolling at narrow widths (acceptable fix: wrap the table in a container with overflow-x:auto, which allows the table to scroll within a defined region — the table itself can scroll as long as the page doesn't require horizontal scrolling), and multi-column layouts that don't stack at 320px.

#26

Understanding WCAG Conformance Levels — What A, AA, and AAA Actually Mean

Level A — The Non-Negotiable Floor

Failing any A-level criterion creates a complete or near-complete barrier for certain users. No site should ship without clearing all Level A criteria. These are the baseline requirements the spec considers essential.

Level AA — The Target ✅

The standard referenced in ADA litigation, EU accessibility law, Section 508 compliance, and enterprise procurement requirements. Meeting AA also requires meeting all A criteria. This is the goal for virtually all commercial sites.

Level AAA — Aspirational

Not achievable for all content types — the W3C explicitly notes this in the spec. Treat AAA as meaningful improvements to pursue where feasible, not as a compliance requirement for most organizations.

⚠️ The Legal Landscape Has Shifted — And It's Global

Over 4,000 federal ADA web accessibility lawsuits were filed in 2023 alone. US courts have consistently held that commercial websites constitute "places of public accommodation" under Title III of the ADA. In April 2024, the DOJ finalized a rule requiring state and local government websites to conform to WCAG 2.1 Level AA. The EU's European Accessibility Act — which extends obligations to private-sector companies offering digital products and services in Europe — became enforceable in June 2025. In the UK, the Equality Act 2010 applies similar requirements. Average settlement ranges for ADA web accessibility cases: $25,000–$100,000 plus legal fees and remediation costs, before accounting for reputational impact.

On VPATs: If you sell software to enterprise or government clients, expect to be asked for a Voluntary Product Accessibility Template — a self-assessment of WCAG conformance formatted as an Accessibility Conformance Report (ACR). The current template version is VPAT 2.4, based on WCAG 2.1, published by the IT Industry Council at itic.org. A credible VPAT requires an actual audit to support its claims. Listing all criteria as "Supports" without evidence is discoverable and creates both legal and commercial exposure.

🚨 Accessibility Overlays Are Not a Compliance Solution

Products like accessiBe, UserWay, and EqualWeb market themselves as one-line-of-JavaScript WCAG compliance. The National Federation of the Blind, the American Council of the Blind, and more than 800 blind and low-vision users have formally opposed these products via the Overlay Fact Sheet (overlayfactsheet.com), citing the harm they cause.

The core problem: overlays cannot repair broken HTML structure — they layer JavaScript patches over inaccessible markup and frequently interfere with the screen readers, zoom tools, and browser extensions users have already customized for their own needs. Several companies that deployed overlays as their sole accessibility strategy have still faced successful ADA lawsuits. Genuine compliance requires fixing the underlying HTML, CSS, and interaction patterns — not masking them.

💰 The Cost Curve of Accessibility Debt

IBM accessibility research produced a widely cited finding on remediation cost: fixing an issue during the design phase costs roughly $1 in relative effort. The same fix costs $10 during active development — and $100+ after launch, because retrofitting often requires reworking component templates, updating CMS output configurations, and retraining content authors.

Accessibility integrated at the design and component-building phase produces semantic HTML as a natural byproduct. Accessibility bolted on post-launch means auditing legacy code, fighting technical debt, and negotiating with stakeholders who experience it as pure cost with no perceived benefit. Running this checklist during development — not before a launch deadline — is what makes it economically rational.

🔍 The Screen Reader Ecosystem — Who Uses What, and Why Testing Scope Matters

The WebAIM Screen Reader User Survey (run annually at webaim.org/projects/screenreadersurvey) is the most credible source of real-world screen reader usage data — not vendor claims. The survey consistently reveals a fragmented ecosystem, with implications for how broadly you test.

Primary screen readers and their user populations

JAWS (Windows, paid ~$95/yr) — historically dominant; heavily used by employed blind professionals and in workplace, government, and education contexts where IT purchasing pays the license
NVDA (Windows, free) — open-source, rapidly growing; widely used by students, consumers, and developers doing accessibility auditing
VoiceOver (macOS / iOS, built-in) — second most-used overall; the primary tool for all Apple device users and critical for mobile accessibility testing
TalkBack (Android, built-in) — dominant on Android mobile; often overlooked in desktop-first testing workflows despite Android's global market share

What the fragmentation means for testing scope

Screen reader behavior varies meaningfully between software and browser combinations — a fix verified in one pairing may not work in another. JAWS and NVDA handle certain ARIA attributes and focus management edge cases differently. Behavior that appears correct in VoiceOver on Safari may produce unexpected announcements in NVDA on Firefox.

Practical recommendation: test with at least one Windows screen reader (NVDA is free) and VoiceOver on iOS (covers a substantial share of mobile screen reader users). Enterprise SaaS products with government or corporate clients should additionally test with JAWS — it remains dominant in those procurement contexts.

🧮 After the Audit: A Rational Fix-Order Framework

Most audits surface more issues than a single sprint can absorb. Prioritize along two axes: severity (how completely does this block access for affected users?) and scope (how many pages or user flows are affected?).

Fix in Current Sprint

Complete keyboard inaccessibility of primary user flows
Unlabeled form fields across key forms
No page language set sitewide
Focus management failures in modal dialogs
Content exceeding the photosensitive flash threshold

Next Sprint

Color contrast failures on primary content areas
No skip navigation link sitewide
Broken heading hierarchy on high-traffic pages
Generic link text ('click here,' 'read more')
Uncaptioned video content

Backlog

AAA criterion improvements
Caption accuracy review and correction
Audio descriptions for supplemental video
Enhanced focus indicator aesthetics
Extended language region tag support

🔧 Shifting Left: Integrating Accessibility into the Build Pipeline

Running this checklist manually before a launch catches issues that should have been caught during development. The most mature accessibility programs integrate automated checks into the CI/CD pipeline so regressions are detected before they ever reach production.

CI/CD integration tools

axe-core — the engine behind Axe DevTools, available as an npm package for integration into Jest, Cypress, or Playwright test suites; surfaces violations as test failures in the CI run
Pa11y — a command-line accessibility testing tool that runs against URLs or HTML files and can be configured as a step in any CI pipeline
Storybook a11y addon — runs axe checks directly on component stories during development, catching violations at the component level before they propagate to pages

What CI/CD catches — and what it doesn't

Automated pipeline checks catch the same approximately 30–40% of issues that browser extension tools catch: missing labels, contrast failures, ARIA attribute errors, missing document structure. They do not catch whether the focus order is intuitive, whether alt text is accurate and meaningful, or whether keyboard navigation through a custom component is actually usable.

The value of CI/CD integration is preventing regression — catching when a previously passing accessibility criterion breaks during a future code change. It doesn't replace the manual testing in this checklist; it protects the results of that manual testing over time.

💡 Compliance Is Not the Same as Usability

A page can technically pass every WCAG 2.1 AA success criterion and still be genuinely difficult — even painful — to use for people with disabilities. WCAG is a technical specification that defines minimum machine-verifiable requirements. It cannot fully capture whether the reading order is intuitive, whether instructions are cognitively clear, whether a custom widget is learnable, or whether error recovery is graceful under real-world conditions.

The organizations with the most genuinely usable accessible products treat WCAG compliance as a floor, not a ceiling — and complement audit-based testing with usability research that includes participants who are blind, have low vision, use keyboards only, or have cognitive disabilities. Services like Fable (makeitfable.com) facilitate access to paid testers with disabilities. This checklist achieves compliance; inclusive usability research takes you the rest of the way to a product that people with disabilities actually want to use.

Master This Checklist Quickly

Every important button and option for this pre-made checklist, shown in a glance-friendly format.

Start Here

1
Click any item row to mark it complete.
2
Use the note row under each item for quick notes.
3
Use the tool row for undo, redo, reset, and check all.
4
Use Save Progress when you want to continue later.

Checklist Row Tools

UndoRedoResetCheck allCollapse/Expand sectionsShow/Hide detailsInline notes

Top Action Buttons

Open all sharing and export options in one menu.

Email DraftContinue on another devicePrint or Save as PDFPlain Text (.txt)Word (.docx)Excel (.xlsx)

Add & Ask

Open one menu for apps and AI guidance.

NotionTodoist CSVChatGPTClaude

Copy and customize

Create a new editable checklist pre-filled with your chosen content.

Save Progress

Adds this checklist to My Checklists and keeps your progress in this browser.

Most Natural Usage

Track over time

Check items -> Add notes where needed -> Save Progress

Send or export

Open Share -> Choose format -> Continue

Make your own version

Copy and customize -> Open create page -> Edit freely