Website Accessibility Self-Audit Checklist: A Practical Checklist

Summary. This checklist lets a business, its developers, or its lawyer test a website against WCAG 2.1 Level AA, with the WCAG 2.2 additions, before a plaintiff does. It starts with scoping and tool setup, then works through the success criteria grouped by the four POUR principles, each with a concrete test and the legal reason it matters. Separate phases give scripted keyboard and screen reader walk-throughs of the pages that generate claims, and dedicated sections cover forms and checkout, media, PDFs, mobile apps, and third-party widgets. A governance phase covers the policy, accessibility statement, pipeline checks, training, vendor contracts, and records that make remediation durable. Red-flag boxes, a deadlines table, common failure points, and a short worked example close the checklist.

Marisol Vega runs operations for a three-store bike shop with a busy online parts catalog. After a competitor across town received an ADA demand letter, she unplugged her mouse, opened her own site, and pressed Tab. The focus ring vanished after the second press. She found it again, eleven presses later, somewhere inside the footer. She could not open the "Shop" menu at all. The whole exercise took four minutes and told her more than the automated scan her agency had sent the month before, which reported a "92 percent accessibility score."

This checklist turns those four minutes into a structured self-audit. It is the expanded version of the quick test in Website Accessibility Lawsuits: What the ADA Requires, What Breaks in the Code, and What to Do When the Letter Arrives, which explains the law and the code behind each item. If a demand letter or complaint has already arrived, stop and read Responding to a Website Accessibility Demand Letter or Lawsuit: A Practical Guide first, because the audit should then run through counsel.

How to use this checklist

Who should run it. A developer or QA tester comfortable with browser developer tools, paired with someone who knows the business's key user journeys. A lawyer can run Phases 5 and 6 (the keyboard and screen reader walk-throughs) without technical training, and should, before advising on any claim.

What it measures. WCAG 2.1 Level AA is the benchmark courts, DOJ settlements, and the federal Title II and Section 504 rules use. No regulation imposes it on private businesses, but Title III's equal-access mandate, 42 U.S.C. § 12182, is measured against it in practice, together with the DOJ's effective-communication regulations in 28 C.F.R. part 36. Items marked (2.2) are WCAG 2.2 additions; build to them if you are rebuilding.

How to record results. For each item, record Pass, Fail, or Not Applicable, the page or template, a screenshot or recording, the WCAG criterion number, and a severity: Blocker (a user cannot complete a task), Serious (a task is possible only with significant difficulty), or Minor. Blockers in the transaction path are the legal priority.

Privilege. A self-audit done before any claim is ordinary business work and may be discoverable later. That is not a reason to skip it; a business that finds and fixes defects is in a far better position than one that never looked. But once a claim is reasonably anticipated, route the audit through counsel under Fed. R. Civ. P. 26(b)(3) and keep counsel's analysis separate from the remediation log. See Attorney-Client Privilege and Work Product for Businesses: Upjohn, In-House Counsel, and the Common Interest.

Tools you need. All are free or built in except JAWS.

Red flag: the automated score. Automated tools find perhaps a third to a little under half of WCAG issues, depending on the study. A high score is not evidence of conformance, and a plaintiff's expert will say so. Every phase below includes manual tests for that reason.

Phase 0: Scope and inventory

• List the user journeys that matter. At minimum: find a product (navigation and search), evaluate it (product page), buy it (cart, checkout, payment), create or log in to an account, contact the business, and book or schedule anything the business offers. Note: the journey that ends in a transaction is where the "denial of goods and services" theory under § 12182(a) is strongest.
• Inventory page templates, not pages. Homepage, category, product, search results, cart, checkout steps, account, content article, store locator, contact, and any landing-page template. Fixing a template fixes every page built on it.
• Inventory third-party components. Payment iframe, reviews widget, chat, cookie banner, email capture pop-up, maps, video player, scheduling, loyalty, and any accessibility overlay. Record the vendor and contract.
• Inventory documents. PDFs and other downloadable files that customers need (menus, price lists, forms, manuals, terms).
• Inventory mobile apps and any kiosk or in-store digital interface.
• Identify federal funding and federal customers. A recipient of federal financial assistance is subject to Section 504, 29 U.S.C. § 794; a vendor selling to federal agencies must meet Section 508, 29 U.S.C. § 794d, and will be asked for a VPAT.
• Identify where customers are. Sales into California bring the Unruh Act, Cal. Civ. Code § 51, and its $4,000-per-offense minimum in § 52 into play; sales into New York bring the State and City Human Rights Laws, N.Y. Exec. Law § 296. Prioritize accordingly.
• Identify physical locations. If the business has stores, the website's nexus to them brings it within Title III in every circuit under Robles v. Domino's Pizza, LLC, 913 F.3d 898 (9th Cir. 2019). Note any store locator, pickup ordering, or in-store gift card feature. If the business is online-only, coverage depends on the circuit; the Eleventh Circuit's physical-place ruling in Gil v. Winn-Dixie Stores, Inc., 993 F.3d 1266 (11th Cir. 2021), was later vacated as moot, 21 F.4th 775, and some courts treat a website as covered on its own.
• Record the test environment: browser and version, screen reader and version, operating system, date. A finding without its environment is hard to reproduce or defend. The same discipline cuts the other way: a complaint that does not identify the barrier actually encountered is vulnerable under Whitaker v. Tesla Motors, Inc., 985 F.3d 1173 (9th Cir. 2021), and a precise record of your own testing is what lets you show that an alleged barrier does not exist.

Phase 1: Perceivable

Text alternatives and media

• 1.1.1 Non-text Content (A). Every meaningful image has alt text that conveys its purpose; product images describe the product (color, style), not the SKU. Decorative images have alt="". Icon-only buttons (search, cart, close) have an accessible name. Test: inspect images; with a screen reader, listen to how each is announced.
• Image links. An image that is a link has alt text describing the destination, not the image.
• CAPTCHA. Any CAPTCHA offers an alternative mode (audio, or a non-visual challenge).

Structure and relationships

• 1.3.1 Info and Relationships (A). Headings are marked up as headings (h1 to h6), lists as lists, tables with header cells, and form fields with associated labels. Test: view the heading outline; there should be one h1, and levels should not skip for styling reasons.
• Landmarks. The page has header, nav, main, and footer regions (or equivalent ARIA roles), so screen reader users can jump between them.
• 1.3.2 Meaningful Sequence (A). Reading order in the DOM matches visual order; CSS reordering does not scramble it.
• 1.3.3 Sensory Characteristics (A). Instructions do not rely solely on shape, position, or sound ("click the round button on the right").
• 1.3.4 Orientation (AA). Content works in portrait and landscape unless one orientation is essential.
• 1.3.5 Identify Input Purpose (AA). Personal-data fields use autocomplete values (name, email, tel, street-address, postal-code, cc-number).

Color, contrast, and resizing

• 1.4.1 Use of Color (A). Color is not the only cue: required fields, errors, links within text, and sale prices have a non-color indicator too.
• 1.4.3 Contrast (Minimum) (AA). Text contrast is at least 4.5:1, or 3:1 for large text (about 18.66px bold or 24px regular). Check placeholder text, disabled-looking but active buttons, text over images, and sale badges.
• 1.4.4 Resize Text (AA). At 200 percent zoom, nothing is cut off or overlapping and all functions still work.
• 1.4.5 Images of Text (AA). Text is real text, not pictures of text, except logos.
• 1.4.10 Reflow (AA). At a 320 CSS pixel wide viewport (about 400 percent zoom on a 1280px window), content reflows into one column without horizontal scrolling, except for things like data tables and maps.
• 1.4.11 Non-text Contrast (AA). Form field borders, focus indicators, icons, and chart elements have at least 3:1 contrast against adjacent colors.
• 1.4.12 Text Spacing (AA). Content survives increased line height (1.5), paragraph spacing (2x), letter spacing (0.12em), and word spacing (0.16em) without loss. Test: apply a text-spacing bookmarklet.
• 1.4.13 Content on Hover or Focus (AA). Tooltips and hover menus can be dismissed (usually with Escape) without moving the pointer, stay visible while the pointer is over them, and do not disappear on their own.

Red flag: the "92 percent" alt text. Automated tools pass any alt attribute, including alt="image", alt="IMG_4471.jpg", or alt="product". Read the alt text of your top 20 products aloud. If it would not help a blind shopper choose, it fails 1.1.1.

Phase 2: Operable

Keyboard

• 2.1.1 Keyboard (A). Every function works with the keyboard alone: menus, filters, carousels, quantity selectors, size and color swatches, "Add to Cart," the cart drawer, checkout, and account functions. Test: Phase 5 script.
• No clickable divs or spans. Interactive controls are native button, a href, input, select, or have a role, tabindex="0", and Enter and Space handling.
• 2.1.2 No Keyboard Trap (A). Focus can always leave a component (modal, menu, embedded video, chat widget, map) using standard keys.
• 2.1.4 Character Key Shortcuts (A). Single-key shortcuts, if any, can be turned off or remapped.

Timing and motion

• 2.2.1 Timing Adjustable (A). Cart holds, checkout sessions, and login timeouts warn the user and allow extension.
• 2.2.2 Pause, Stop, Hide (A). Auto-rotating carousels, auto-playing video, and animated banners lasting more than five seconds can be paused.
• 2.3.1 Three Flashes or Below Threshold (A). Nothing flashes more than three times a second.

Navigation and focus

• 2.4.1 Bypass Blocks (A). A "Skip to main content" link is the first focusable element and works.
• 2.4.2 Page Titled (A). Each page, and each checkout step, has a unique, descriptive title.
• 2.4.3 Focus Order (A). Focus moves in a logical order; opening a modal moves focus into it, and closing it returns focus to the trigger.
• 2.4.4 Link Purpose (In Context) (A). Link text makes sense ("Read the sizing guide," not a row of "Click here").
• 2.4.5 Multiple Ways (AA). Pages can be found more than one way (navigation plus search or a site map).
• 2.4.6 Headings and Labels (AA). Headings and labels describe their content.
• 2.4.7 Focus Visible (AA). A visible focus indicator appears on every focusable element. Test: search stylesheets for outline: none and outline: 0 without a :focus-visible replacement.
• 2.4.11 Focus Not Obscured (Minimum) (AA) (2.2). A focused element is not entirely hidden behind a sticky header, cookie banner, or chat bubble.

Pointer and touch

• 2.5.1 Pointer Gestures (A). Pinch, swipe, and multi-finger gestures have a single-pointer alternative (buttons).
• 2.5.2 Pointer Cancellation (A). Actions fire on release (click), not on press, so users can slide off a mistaken tap.
• 2.5.3 Label in Name (A). The accessible name of a control contains its visible label (critical for voice-control users who say "click Add to Cart").
• 2.5.4 Motion Actuation (A). Shake-to-undo or tilt features have a button alternative.
• 2.5.7 Dragging Movements (AA) (2.2). Sliders, drag-to-reorder lists, and map panning have a non-drag alternative.
• 2.5.8 Target Size (Minimum) (AA) (2.2). Touch targets are at least 24 by 24 CSS pixels or have equivalent spacing.

Red flag: the timed pop-up. An email capture overlay that appears after a few seconds, does not take focus, and cannot be closed by keyboard fails 2.1.2 and 2.4.3 at once, and "focus management during automatic pop-ups" is one of the most frequently alleged defects in demand letters. Test every overlay your marketing team runs, including seasonal ones.

Phase 3: Understandable

• 3.1.1 Language of Page (A). The html element has a correct lang attribute.
• 3.1.2 Language of Parts (AA). Passages in another language are marked with their own lang.
• 3.2.1 On Focus (A). Moving focus to a control does not by itself submit a form, open a new window, or move focus elsewhere.
• 3.2.2 On Input (A). Changing a select menu or checkbox does not navigate away or submit without warning (watch "sort by" and country selectors).
• 3.2.3 Consistent Navigation (AA). Navigation appears in the same order across pages.
• 3.2.4 Consistent Identification (AA). The same function has the same label everywhere ("Cart" is not "Bag" on another page).
• 3.2.6 Consistent Help (A) (2.2). Help mechanisms (contact link, chat, phone) appear in the same relative place across pages.
• 3.3.1 Error Identification (A). Errors are described in text and identify the field, not just shown as a red border.
• 3.3.2 Labels or Instructions (A). Every field has a visible label; required fields and formats ("MM/YY") are stated before input.
• 3.3.3 Error Suggestion (AA). Error messages suggest the fix ("Enter a five-digit ZIP code").
• 3.3.4 Error Prevention (Legal, Financial, Data) (AA). Orders and account changes can be reviewed and corrected before submission, or reversed.
• 3.3.7 Redundant Entry (A) (2.2). Information already entered (shipping address) is not required again in the same process, or can be auto-filled ("Billing same as shipping").
• 3.3.8 Accessible Authentication (Minimum) (AA) (2.2). Login does not require a cognitive test (memorizing or transcribing a code) without an alternative; password managers and paste work.

Phase 4: Robust

• 4.1.2 Name, Role, Value (A). Every custom control exposes a name, a role, and its current state to assistive technology. Menus and accordions use aria-expanded; toggles use aria-pressed or are real checkboxes; tabs use the tab pattern. Test: inspect the accessibility tree in browser developer tools.
• 4.1.3 Status Messages (AA). "Added to cart," "3 results found," and form error summaries are announced by a screen reader without moving focus, using role="status", role="alert", or an aria-live region.
• ARIA is not overused. Native elements are preferred; aria-hidden="true" is never on a focusable element; ARIA roles match behavior.
• Parsing is no longer a separate criterion in WCAG 2.2 (4.1.1 is obsolete), but duplicate IDs still break label associations and aria-describedby links. Fix them.

Phase 5: Keyboard walk-through script

Unplug the mouse or turn off the trackpad. Use only Tab, Shift+Tab, Enter, Space, the arrow keys, and Escape. Record every place you get stuck, lose sight of focus, or land somewhere unexpected.

• Homepage load. First Tab press reveals a skip link. Second reaches the logo or first navigation item. Focus is visible at every step.
• Primary navigation. Each top-level item can be reached. Each submenu opens with Enter or Space (not only on hover), its links can be reached in order, and Escape closes it and returns focus to the parent.
• Search. The search field can be reached and used; suggestions can be navigated with arrow keys; results load and focus lands sensibly.
• Category page. Filters and sort controls work by keyboard; applying a filter does not throw focus to the top of the page without warning; product tiles are reachable once each, not three times (image, title, price) unless each is meaningful.
• Product page. Size, color, and quantity controls work; "Add to Cart" is reachable and activates with Enter and Space; the confirmation is announced or focus moves to it.
• Cart drawer or page. Opens by keyboard; focus moves into it; quantity and remove controls work; Escape or a close button closes it; focus returns to where it was.
• Pop-ups. Every automatic overlay (email capture, promotions, cookie banner, chat invitations) can be reached, operated, and dismissed by keyboard, and does not trap focus.
• Checkout. Every field, step, shipping option, and payment field is reachable in order; errors can be found and corrected; the order can be placed. Stop before submitting payment on a live site.
• Account. Create an account, log in, reset a password, and view an order by keyboard.
• Footer and contact. Contact form, phone link, and accessibility statement link work.

Red flag: the invisible focus. If you lose track of where focus is for more than two Tab presses anywhere in the transaction path, treat it as a Blocker. Keyboard and screen magnifier users cannot recover from it.

Phase 6: Screen reader walk-through

Run the same journeys with NVDA and Firefox or Chrome on Windows, and VoiceOver and Safari on macOS or iOS. Listen rather than look; close your eyes or turn the screen brightness down.

• Page title and language are announced correctly on load.
• Headings list (NVDA: Insert+F7; VoiceOver: the rotor) shows a sensible outline you could navigate by.
• Landmarks are announced and allow jumping to main content.
• Links and buttons have names that make sense out of context; no "button, button, link, link" with no label.
• Images announce useful descriptions; decorative ones are silent.
• Menus and accordions announce "collapsed" and "expanded."
• "Add to Cart" announces as a button, and the result is announced.
• Cart count changes are announced.
• Form fields announce their labels, required status, and any instructions.
• Errors are announced when they appear, and each field's error is read with the field.
• Payment fields inside an iframe announce a meaningful frame title and labeled fields.
• Order confirmation is announced and readable.
• Time it. Note how long a full purchase takes compared with a sighted mouse user. A purchase that is technically possible but takes 25 minutes and three restarts is a Serious finding.

Phase 7: Forms and checkout deep check

• Every input has a <label for> or aria-labelledby; placeholders are not used as labels.
• Required fields are marked in text (not only with color or an asterisk without explanation) and with required or aria-required.
• Field groups (shipping method, payment method) use fieldset and legend or an equivalent group label.
• On submit with errors, focus moves to an error summary or the first invalid field, and each invalid field has aria-invalid="true" and aria-describedby pointing to its message.
• Inline validation does not announce an error on every keystroke.
• Address, phone, email, and card fields use autocomplete and appropriate inputmode.
• Promo code, gift card, and shipping calculators work by keyboard and announce results.
• Multi-step checkout moves focus to the new step's heading and updates the page title.
• Session timeouts warn before expiring and allow extension (2.2.1).
• Order review step allows correction before purchase (3.3.4).
• Guest checkout is available or account creation is itself accessible.
• Third-party payment (wallet buttons, card iframes, buy-now-pay-later widgets) is tested end to end.

Red flag: the checkout that cannot be finished. A blind user who cannot complete a purchase has been denied the business's goods entirely, the core fact pattern under 42 U.S.C. § 12182. If your Phase 6 purchase failed, stop the audit and fix checkout first.

Phase 8: Media

• 1.2.1 Audio-only and Video-only (Prerecorded) (A). Podcasts have transcripts; silent videos have a text or audio description.
• 1.2.2 Captions (Prerecorded) (A). All prerecorded video with audio has accurate, synchronized captions (not unedited auto-captions).
• 1.2.3 Audio Description or Media Alternative (A) and 1.2.5 Audio Description (Prerecorded) (AA). Visual information not conveyed by the soundtrack (product demonstrations with no narration) is described.
• 1.2.4 Captions (Live) (AA). Live streams have real-time captions.
• 1.4.2 Audio Control (A). Nothing auto-plays sound for more than three seconds without a pause or mute control.
• The video player's controls are keyboard operable and labeled.

Phase 9: PDFs and documents

• Documents customers need (menus, forms, warranties, terms, size charts) are available as accessible HTML or as tagged, accessible PDFs.
• PDFs are tagged, have a logical reading order, a document title, a language set, and alt text for images. Test: run the PDF accessibility checker in a PDF editor and read the document with a screen reader.
• Scanned PDFs have real text (OCR), not only images.
• Fillable PDF forms have labeled fields and a logical tab order, or an HTML alternative.
• Links to documents say what they are ("Return form (PDF, 2 pages)").
• For public entities and HHS recipients: the Title II rule in 28 C.F.R. part 35 and the HHS rule in 45 C.F.R. part 84 contain specific, narrow exceptions for archived content and preexisting documents. Do not assume a document is exempt without checking the conditions.

Phase 10: Mobile apps

• Run iOS VoiceOver and Android TalkBack through the same journeys as Phases 5 and 6.
• Every control has an accessibility label; images have descriptions; decorative elements are hidden from the accessibility tree.
• Dynamic Type and system font scaling enlarge text without truncation.
• The app works in both orientations (1.3.4).
• Touch targets meet minimum size (2.5.8 (2.2); platform guidelines recommend larger).
• Gestures have alternatives (2.5.1, 2.5.7).
• An external keyboard and switch control can operate the app.
• Web views inside the app meet the same web criteria.
• Note: the DOJ Title II rule and the HHS Section 504 rule apply WCAG 2.1 AA to mobile apps expressly, and Robles involved both a website and an app.

Phase 11: Third-party widgets and vendors

• Inventory every third-party script that renders content (Phase 0) and test each in Phases 5 and 6.
• Request a current VPAT or Accessibility Conformance Report from each vendor, and compare it with your own test results. A VPAT is a vendor's self-assessment; treat it as a starting point.
• Chat widget. Can be opened, used, and closed by keyboard; messages are announced; it does not obscure focused content (2.4.11).
• Reviews widget. Star ratings have text equivalents; "Write a review" works by keyboard.
• Cookie banner. Receives focus or is reachable early, can be accepted or rejected by keyboard, and does not trap focus. See Drafting and Maintaining a Privacy Policy: A Practical Guide for the consent side.
• Maps and store locators. Provide a text list of locations alongside the map.
• Overlay widgets. If one is installed, test with it on and off. Overlays do not repair underlying code, can interfere with users' own screen reader settings, and have drawn FTC enforcement under 15 U.S.C. § 45 for unsubstantiated compliance claims. Do not rely on one as remediation.
• Contract terms. Vendor contracts contain an accessibility warranty (WCAG 2.1 AA), a duty to remediate within a set time, cooperation in claims, and an indemnity or remedy. See Template 11 in the Website Accessibility Defense Toolkit: Demand Responses, Privileged Audit Engagements, and Remediation Records and Building a Vendor and Third-Party Risk Management Program.

Red flag: the serial template. If your audit happens because a demand arrived, compare the letter's allegations to your findings line by line. Template complaints with allegations that do not match the site support a standing challenge, as the Second Circuit held in Calcano v. Swarovski North America Ltd., 36 F.4th 68 (2d Cir. 2022). Allegations that do match are the ones to fix first.

Red flag: "that's the vendor's problem." The experience on your website is your responsibility to your customers under Title III, whoever wrote the code. The DOJ Title II rule makes the point expressly for public entities, covering content provided through contractual, licensing, or other arrangements, and courts treat private businesses the same way in practice.

Phase 12: Governance and durability

These items are what turn a one-time fix into a defense. Courts applying the voluntary cessation doctrine of Friends of the Earth, Inc. v. Laidlaw Environmental Services (TOC), Inc., 528 U.S. 167 (2000), look for evidence that a defendant will not slide back.

• Written accessibility policy adopted by management, naming an owner, the standard (WCAG 2.1 AA, with 2.2 AA as the target), and the testing cadence.
• Accessibility statement on the site, linked from every page footer, with a monitored email and phone number, a response-time commitment, an honest conformance status, and the date of last review. Do not claim full conformance you have not verified. A model is Template 9 in the toolkit.
• Feedback channel routes accessibility complaints to someone who acts on them, with a log.
• Prior settlements tracked. Any remediation promised in a past settlement is scheduled, completed, and verified. A promise to one plaintiff does not moot another plaintiff's claim if the work was never done, Haynes v. Hooters of America, LLC, 893 F.3d 781 (11th Cir. 2018).
• Definition of done for development includes keyboard and screen reader checks for new components.
• Automated checks in the deployment pipeline (an axe-core based test suite) fail the build on new violations.
• Manual retest schedule: at least annually and after any redesign, platform migration, or theme change.
• Content training for marketing and merchandising on alt text, headings, link text, captions, and accessible PDFs.
• Design system components (buttons, menus, modals, forms) are accessible by default, so teams cannot easily build inaccessible ones.
• Procurement: accessibility requirements in RFPs and contracts for anything that renders on the site.
• Records: a remediation log (finding, criterion, fix, date, verification, verifier) kept as a business record you are prepared to produce, separate from any privileged legal analysis. Retain prior versions under your normal schedule, and suspend deletion under a litigation hold when a claim arrives; Fed. R. Civ. P. 37(e) governs the consequences of losing that evidence. See the Litigation Hold and Evidence Preservation Checklist: A Practical Checklist.
• Insurance review: confirm whether any policy covers third-party discrimination claims, and note notice requirements.
• Response plan: who receives a demand letter, who calls counsel, and who sends the hold. The steps are in Responding to a Website Accessibility Demand Letter or Lawsuit: A Practical Guide.

Deadlines and key dates

Both extensions were issued as interim final rules with post-publication comment periods, so check the agency's current compliance date before relying on either.

Common failure points

1. Custom controls built from divs (2.1.1, 4.1.2). The most common Blocker.
2. Hover-only navigation menus (2.1.1).
3. Email capture and promotional pop-ups that do not take or release focus (2.1.2, 2.4.3).
4. Cart drawers that drop focus to the top of the page on close (2.4.3).
5. outline: none with no replacement (2.4.7).
6. Placeholder-only form labels and red-border-only errors (1.3.1, 3.3.1, 4.1.3).
7. Meaningless alt text from bulk product uploads (1.1.1).
8. Low-contrast sale badges, placeholder text, and light-gray body copy (1.4.3).
9. Unlabeled payment iframes and wallet buttons (4.1.2).
10. Auto-captions never edited on product videos (1.2.2).
11. Untagged PDFs for menus and forms.
12. Regression after a redesign that nobody retested.

Short worked example

Marisol's bike shop runs the checklist over two days. Phase 0 identifies eight templates and six third-party components. Phase 1 finds 140 product images with alt text that reads "bike-part-image." Phase 2 finds that the "Shop" menu opens only on hover, that a "Spring Tune-Up" pop-up cannot be closed by keyboard, and that the stylesheet removes all focus outlines. Phase 5 confirms she cannot reach the parts catalog by keyboard at all. Phase 6, with NVDA, finds that "Add to Cart" is announced as plain text and that the checkout's card number error is silent. The shop has three stores and a store-pickup option, so the nexus under Robles is plain.

She ranks the findings: the menu, pop-up, cart control, and checkout error as Blockers in the transaction path; focus outlines and alt text as Serious; footer contrast as Minor. The agency fixes the Blockers in three weeks, using native buttons, a disclosure menu, a native dialog, and a live-region error summary. Merchandising rewrites the alt text with a template ("[brand] [part] in [color], fits [standard]"). The shop adopts a policy, publishes an accessibility statement, adds automated checks to its theme deployment, and adds an accessibility warranty to its reviews-widget renewal. Every fix goes into a remediation log with the date and verification method.

When a demand letter arrives eight months later, alleging "inaccessible navigation" and "improper focus management," counsel answers within a week with the remediation dates and an independent verification. The letter goes no further. The audit cost two days of staff time and a few thousand dollars of agency work, which is less than most demand letters ask for.

This document is general information, not legal advice for any particular situation; WCAG conformance and legal compliance are related but not identical, and the facts matter.

Related Documents

Related Articles

• Website Accessibility Lawsuits: What the ADA Requires, What Breaks in the Code, and What to Do When the Letter Arrives: the law and the code behind each checklist item.
• Website and Mobile App Accessibility Under the ADA: WCAG, Litigation Risk, and Remediation: the broader compliance survey.
• Attorney-Client Privilege and Work Product for Businesses: Upjohn, In-House Counsel, and the Common Interest: when to route the audit through counsel.

Related Guides

• Responding to a Website Accessibility Demand Letter or Lawsuit: A Practical Guide: what to do if a claim arrives.
• Drafting and Maintaining a Privacy Policy: A Practical Guide: the companion site disclosure most businesses maintain alongside an accessibility statement.
• Requesting Disability Accommodations and Enforcing Access Rights: A Practical Guide: the user's perspective.

Related Checklists

• Website Accessibility Remediation Checklist: A Practical Checklist: fixing what this audit finds.
• Litigation Hold and Evidence Preservation Checklist: A Practical Checklist: preserving site history when a claim arrives.
• Website Terms of Service Review Checklist: A Practical Checklist: the other legal pages to review in the same pass.
• Vendor Cybersecurity Diligence Checklist: A Practical Checklist: a parallel diligence process for the same third-party scripts.

Related Toolkits

• Website Accessibility Defense Toolkit: Demand Responses, Privileged Audit Engagements, and Remediation Records: the remediation log, accessibility statement, and vendor clauses referred to here.
• Disability Rights Toolkit: Accommodation Requests, Access Complaints, and Housing Modifications: access complaints beyond the web.