Document 07

E-Commerce Accessibility & Legal Compliance

Updated: February 2026 WCAG 2.2 AA Baseline ISO/IEC 40500:2024
Section 1

WCAG 2.2 AA Requirements

The Web Content Accessibility Guidelines (WCAG) 2.2, published by the W3C, define the benchmark for digital accessibility. WCAG 2.2 became an ISO standard as ISO/IEC 40500:2024, giving it formal recognition in international procurement and regulatory frameworks.

87 Success Criteria
4 Principles (POUR)
3 Conformance Levels
9 New in 2.2

The Four Principles (POUR)

  • Perceivable — Information and UI components must be presentable in ways users can perceive (text alternatives, captions, adaptable layouts, distinguishable content).
  • Operable — UI components and navigation must be operable via keyboard, sufficient time, seizure-safe design, and navigable structure.
  • Understandable — Information and UI operation must be understandable through readable text, predictable behavior, and input assistance.
  • Robust — Content must be robust enough to be interpreted reliably by a wide variety of user agents and assistive technologies.

New Success Criteria in WCAG 2.2 New

WCAG 2.2 introduced nine new success criteria. Three are particularly relevant to e-commerce:

Criterion Level Requirement E-Commerce Impact
2.4.11 Focus Not Obscured AA When an element receives keyboard focus, it must not be entirely hidden by other content (sticky headers, cookie banners, chat widgets). Sticky carts, navigation bars, and cookie consent banners must not cover focused elements.
2.5.7 Dragging Movements AA Any functionality that uses dragging must have a single-pointer alternative that does not require dragging. Quantity sliders, image reordering, and drag-to-cart interactions need click/tap alternatives.
2.5.8 Target Size (Minimum) AA Interactive targets must be at least 24x24 CSS pixels, or have sufficient spacing from adjacent targets. Add-to-cart buttons, quantity controls, variant selectors, and checkout form elements.
ISO/IEC 40500:2024

WCAG 2.2 was adopted as the ISO/IEC 40500:2024 standard, replacing the earlier WCAG 2.0-based version. This means WCAG 2.2 is now referenced in government procurement requirements and international trade agreements. Compliance with WCAG 2.2 AA satisfies the ISO standard.

Section 2

ADA Compliance for E-Commerce

The Americans with Disabilities Act (ADA) is the primary US federal law driving web accessibility enforcement. Courts have consistently ruled that commercial websites are "places of public accommodation" under Title III. E-commerce is the most-targeted industry.

4,605+ Lawsuits in 2023
4,000+ Projected 2024
80%+ Target E-Commerce
$5K–$50K Average Settlement

Expected Standard

While the ADA does not explicitly reference WCAG, courts and the Department of Justice have consistently pointed to WCAG 2.1 AA as the minimum expected standard. ADA Title II (covering state and local government websites) formally mandates WCAG 2.1 AA compliance by April 24, 2026.

Top Violations Cited in Lawsuits

  1. Missing alt text on images — Product images without descriptions, decorative images missing alt=""
  2. Missing form labels — Search fields, quantity inputs, checkout forms without associated <label> elements
  3. Insufficient color contrast — Light gray text on white backgrounds, low-contrast button text
  4. Keyboard navigation failures — Dropdown menus, modals, and carousels that cannot be operated without a mouse
  5. Missing page language declaration — No lang attribute on the <html> element
  6. Empty links and buttons — Icon-only elements without accessible names
Serial Litigation Risk

A significant portion of ADA web accessibility lawsuits are filed by a small number of serial plaintiffs and law firms. Some file hundreds of cases per year targeting e-commerce sites with automated scans. Even small online stores are not exempt. A VPAT (Voluntary Product Accessibility Template) and documented remediation plan can strengthen your legal position.

Section 3

ARIA (Accessible Rich Internet Applications)

WAI-ARIA provides semantic attributes that bridge the gap between complex interactive components and assistive technologies. Proper ARIA usage is essential for dynamic e-commerce interfaces like product carousels, filter panels, and shopping carts.

First Rule of ARIA: "No ARIA is better than bad ARIA"

Incorrect ARIA attributes create worse experiences than having no ARIA at all. A screen reader trusts ARIA declarations. If you mark something as role="button" but it is not keyboard-operable, you have created a lie that the assistive technology will faithfully relay to the user. Always prefer native HTML elements (<button>, <nav>, <dialog>) over ARIA-enhanced <div> elements.

ARIA Roles for Common E-Commerce Components

Component ARIA Role Key Attributes
Product Carousel role="region" aria-label, aria-roledescription="carousel"
Modal / Dialog role="dialog" aria-modal="true", aria-labelledby
Tab Panels role="tablist", role="tab", role="tabpanel" aria-selected, aria-controls
Accordion Native <details> or heading + aria-expanded aria-expanded, aria-controls
Data Grid / Product Table role="grid" aria-rowcount, aria-colcount
Alert Messages role="alert" aria-live="assertive" (implicit)

Live Regions for Dynamic Content

  • aria-live="polite" — For non-urgent updates: cart item count changes, filter result counts, success messages. The screen reader announces at the next pause in speech.
  • aria-live="assertive" — For urgent updates: form validation errors, payment failures, session timeouts. The screen reader interrupts the current speech to announce immediately.
  • role="alert" — Automatically implies aria-live="assertive" and aria-atomic="true". Use for form validation error summaries.

Common ARIA Patterns in E-Commerce

<!-- Icon-only button: requires aria-label --> <button aria-label="Add to cart"> <svg aria-hidden="true">...</svg> </button> <!-- Cart count live region --> <span aria-live="polite" aria-atomic="true"> 3 items in cart </span> <!-- Expandable menu --> <button aria-expanded="false" aria-controls="category-menu"> Categories </button> <ul id="category-menu" hidden>...</ul> <!-- Form validation error --> <div role="alert"> Please enter a valid email address. </div>
Section 4

Keyboard Navigation

Full keyboard operability is a WCAG Level A requirement and one of the most frequently violated criteria in e-commerce. Every interactive element, from product browsing to completed purchase, must be operable without a mouse or touch input.

Essential Key Mappings

Key Action Context
Tab Move focus to next interactive element Sequential navigation through page
Shift + Tab Move focus to previous interactive element Reverse navigation
Arrow keys Navigate within a component Tabs, menus, radio groups, carousels, dropdowns
Enter / Space Activate / toggle element Buttons, links, checkboxes, accordions
Escape Close / dismiss Modals, dropdown menus, popups, overlays
Home / End Jump to first / last item Lists, menus, sliders

Focus Management Requirements

  • Skip links: Provide a "Skip to main content" link as the first focusable element on every page. This allows keyboard users to bypass repetitive navigation.
  • Focus indicators: All interactive elements must have a visible focus indicator. The default browser outline is acceptable, but custom indicators must have sufficient contrast (3:1 minimum against adjacent colors).
  • Focus trapping in modals: When a modal dialog is open, Tab must cycle within the modal only. Focus should not escape to the page behind. On close, focus returns to the element that opened the modal.
  • Logical tab order: Focus order must follow the visual reading order. Avoid tabindex values greater than 0.

E-Commerce Keyboard Audit Points

  • Can a user browse products, select variants, and add to cart using only the keyboard?
  • Can a user complete the entire checkout flow (address, payment, review, place order) with keyboard alone?
  • Do image carousels respond to arrow keys and have visible navigation controls?
  • Can dropdown menus and mega-menus be opened, navigated, and closed with keyboard?
  • Do quantity increment/decrement controls work with keyboard?
  • Can filters and sort controls be operated without a mouse?
<!-- Skip link implementation --> <body> <a href="#main-content" class="skip-link"> Skip to main content </a> <nav>...</nav> <main id="main-content"> ... </main> </body> /* CSS for skip link */ .skip-link { position: absolute; top: -100px; left: 16px; z-index: 10000; } .skip-link:focus { top: 8px; }
Section 5

Color Contrast

Insufficient color contrast is among the most common accessibility violations on the web. WCAG defines precise contrast ratios that ensure text and interactive elements remain perceivable for users with low vision or color vision deficiencies.

Minimum Contrast Ratios

Element Type Definition AA Minimum AAA Enhanced
Normal text Below 18px regular or 14px bold 4.5:1 7:1
Large text 18px+ bold or 24px+ regular 3:1 4.5:1
UI components & graphical objects Borders, icons, focus indicators, form controls 3:1 —

Contrast Demonstrations

#1A1A2E on #FFF
Ratio: 16.2:1 (Pass AAA)
#767676 on #FFF
Ratio: 4.54:1 (Pass AA)
#AAAAAA on #FFF
Ratio: 2.32:1 (FAIL)

Common E-Commerce Violations

  • Light gray placeholder text — Placeholder text in search bars and form fields often uses very low-contrast gray. Use a contrasting color or rely on visible labels instead.
  • Links without underline — If links are distinguished from surrounding text only by color, the color contrast between link and non-link text must be at least 3:1 and the link must have a non-color indicator on hover/focus (underline, outline).
  • Disabled state text — While WCAG exempts disabled controls from contrast requirements, excessively low-contrast disabled buttons confuse users about what is and is not interactive.
  • Sale price / strike-through text — The original price shown in strikethrough often fails contrast, making it unreadable.
  • White text on light images — Hero banners and product image overlays need text shadows, gradients, or solid backgrounds to guarantee contrast.

Testing Tools

  • WebAIM Contrast Checker — webaim.org/resources/contrastchecker/
  • Chrome DevTools — Inspect element → color picker shows contrast ratio and WCAG pass/fail status.
  • Stark (Figma plugin) — Check contrast during design, before code is written.
  • Colour Contrast Analyser (TPGi) — Desktop app with eyedropper tool for testing any on-screen content.
Section 6

Screen Reader Testing

Automated tools catch only a fraction of accessibility issues. Screen reader testing is essential to verify that real users can perceive and operate your e-commerce interface with assistive technology.

Market Share of Screen Readers

40.5% NVDA (Free, Windows)
31.9% JAWS (Paid, Windows)
14.4% VoiceOver (macOS / iOS)
Screen Reader Platform Cost Recommended Browser
NVDA Windows Free (open source) Firefox or Chrome
JAWS Windows Paid license (~$1,000/year) Chrome or Edge
VoiceOver macOS, iOS Free (built-in) Safari
TalkBack Android Free (built-in) Chrome for Android

What to Test

  1. Heading navigation — Can the user navigate the page structure using headings (H1-H6)? Are headings properly nested?
  2. Form labels — Are all form fields announced with their label when focused? Are required fields indicated?
  3. Error announcements — When a form validation error occurs, is it announced to the screen reader? Can the user navigate to the error?
  4. Purchase flow — Can a user complete the entire purchase (browse, add to cart, checkout, payment, confirmation) using only a screen reader?
  5. Dynamic content — Are cart updates, filter results, and status messages announced via live regions?

Common Issues Found in Screen Reader Testing

  • Non-descriptive links — "Click here", "Read more", "Learn more" provide no context when read in isolation. Use descriptive link text: "View product details for [Product Name]".
  • Missing form labels — Visual placeholder text is not a substitute for <label> elements. Screen readers may not announce placeholder text.
  • Image metadata (4 required attributes) — Every content image must have all four:
    • title — Short name shown on hover. For products: the product name. For gallery: a descriptive label.
    • alt — Screen reader text describing what the image shows. Be specific: “Patriot Air Shock mounted on K5 Blazer rear axle”, not “air shock”.
    • caption — Visible text below the image (via <figure> + <figcaption>). Provides context a user can read.
    • description — Extended detail for complex images (size charts, exploded views, technical drawings). Use aria-describedby pointing to a hidden text block, or a long description link.
    Decorative images (spacers, dividers, background textures) need alt="" and no title/caption. CSS background images used for content should be converted to <img> tags or given role="img" + aria-label.
  • Custom widgets without ARIA — Star ratings, color swatches, and accordion panels built with <div> elements are invisible to screen readers without proper roles and labels.
Section 7

Cognitive Accessibility

Cognitive and learning disabilities affect how people process information, remember instructions, and manage complex tasks. E-commerce checkout flows are particularly challenging for users with cognitive disabilities.

Content Readability

  • Reading level: Write at an 8th-grade reading level maximum. Use short, direct sentences. Avoid jargon unless defined.
  • Sentence length: Aim for 15–20 words per sentence. Break complex ideas into multiple short sentences.
  • Consistent terminology: Pick one word and use it everywhere. Do not alternate between "cart", "bag", "basket", "trolley" for the same concept. Consistency reduces cognitive load.
  • Plain language: Use "buy" instead of "procure", "send" instead of "transmit", "help" instead of "facilitate".

Navigation & Wayfinding

  • Breadcrumbs: Provide breadcrumb navigation on every page below the top level. Users must always know where they are in the site hierarchy.
  • Progress indicators: Multi-step checkout must show a progress indicator (step 1 of 4, step 2 of 4, etc.) so users understand where they are and how much remains.
  • Consistent navigation: Navigation menus must appear in the same location on every page. Do not rearrange the menu structure between pages.
  • Clear page titles: Every page must have a unique, descriptive <title> that identifies its purpose.

Error Prevention

  • Review before submit: Before placing an order, present a complete summary of the order (items, quantities, prices, shipping address, payment method) and require explicit confirmation.
  • Undo capability: Allow users to undo actions (remove from cart, change quantity) without multi-step processes.
  • Clear error messages: When something goes wrong, explain what happened, where the error is, and exactly how to fix it. Never display raw error codes.
  • Input validation in context: Show errors next to the relevant field, not only in a summary at the top of the form.
The Cognitive Load Principle

Every additional choice, field, or step in your checkout increases cognitive load and abandonment risk. This harms all users, but disproportionately affects users with cognitive disabilities. Guest checkout, autofill support, and minimal required fields are both accessibility measures and conversion optimizations.

Section 8

Motor Disability Support

Motor disabilities affect a user's ability to use a mouse, make precise movements, or interact with small targets. This includes users with tremors, paralysis, repetitive strain injuries, and those using alternative input devices like mouth sticks, head pointers, or eye-tracking systems.

Touch Target Sizes

Level Minimum Size Applies To
AA WCAG 2.5.8 24 x 24 CSS pixels All interactive targets (or sufficient spacing from adjacent targets)
AAA WCAG 2.5.5 44 x 44 CSS pixels Recommended for primary actions (add to cart, checkout, submit buttons)

Drag Alternatives (WCAG 2.5.7)

Any functionality that can be achieved by dragging must also have a single-pointer, non-dragging alternative. This is an AA requirement new in WCAG 2.2.

  • Quantity sliders — Provide a text input or increment/decrement buttons alongside any slider.
  • Image reordering — Provide "move up" / "move down" buttons alongside drag-to-reorder.
  • Drag-to-cart — Always provide a standard "Add to cart" button. Drag-to-cart may exist as an enhancement only.
  • Map interactions — Store locators with draggable maps need zoom buttons and address-based search.

Additional Motor Requirements

  • Timeout adjustability: If a session or checkout timer exists, users must be able to extend or disable it. At minimum, warn 20 seconds before expiry and allow a single-action extension.
  • No multi-point required gestures: If a pinch-to-zoom or multi-finger swipe is used, provide a single-pointer alternative (buttons, links).
  • Pointer cancellation: Actions should complete on the up-event (mouseup/touchend), not the down-event. This allows users to cancel an accidental activation by moving the pointer away before releasing.
  • No motion-only activation: If shaking or tilting the device triggers an action, provide a UI control alternative and allow the motion trigger to be disabled.
Section 9

GDPR Compliance

The General Data Protection Regulation (EU) governs how personal data is collected, processed, and stored for any business that serves EU/EEA residents. It applies regardless of where your business is physically located.

4% Max Fine (Global Revenue)
€20M Or Max Flat Fine
72 hrs Breach Notification

Cookie Consent Requirements

  • Explicit opt-in BEFORE non-essential cookies: Analytics, marketing, and personalization cookies must not be set until the user actively consents. Pre-checked boxes and implied consent ("by continuing to browse...") are not compliant.
  • Granular consent: Users must be able to accept or reject categories of cookies individually (necessary, analytics, marketing, personalization).
  • Easy withdrawal: It must be as easy to withdraw consent as it was to give it. A persistent settings link in the footer is standard.
  • No cookie walls: You cannot block access to the website if the user rejects non-essential cookies (with limited exceptions).

Key Data Subject Rights

  • Right to access — Users can request a copy of all personal data you hold about them.
  • Right to be forgotten — Users can request deletion of their personal data. You must comply unless you have a lawful basis for retention (e.g., tax records).
  • Data portability — Users can request their data in a machine-readable format (JSON, CSV) to transfer to another service.
  • Right to rectification — Users can correct inaccurate personal data.
  • Right to restrict processing — Users can limit how their data is used while disputes are resolved.

Breach Notification

In the event of a personal data breach, you must notify the relevant supervisory authority within 72 hours of becoming aware. If the breach poses a high risk to individuals, those individuals must also be notified directly.

E-Commerce GDPR Checklist

Your checkout flow collects names, addresses, emails, phone numbers, and payment data. Ensure: (1) your privacy policy is linked before submission, (2) marketing opt-in is a separate, unchecked checkbox, (3) data retention periods are defined and enforced, (4) third-party integrations (analytics, payment processors, shipping APIs) are documented in your data processing records.

Section 10

CCPA / CPRA (California)

The California Consumer Privacy Act (CCPA), as amended by the California Privacy Rights Act (CPRA), provides California residents with rights over their personal information and imposes obligations on businesses that collect it.

$7,988 Per Intentional Violation
$2,663 Per Unintentional Violation

Key Requirements for E-Commerce

  • "Do Not Sell or Share My Personal Information" link: Must be prominently displayed on the website (typically in the footer). Required even if you do not directly sell data, if any third-party tracking (Facebook Pixel, Google Analytics with advertising features) constitutes "sharing" under the CPRA definition.
  • Opt-out of data sale: Users must be able to opt out of the sale or sharing of their personal information with a simple mechanism (one-click, no account required).
  • Global Privacy Control (GPC): Websites must honor the GPC browser signal as a valid opt-out request.
  • Right to delete: California residents can request deletion of their personal data.
  • Right to know: Residents can request disclosure of what data has been collected and how it has been used, sold, or shared.
  • No retaliation: You cannot charge different prices, provide lower quality service, or deny services to users who exercise their privacy rights.
Applies to You If...

CCPA/CPRA applies if your business (1) has annual gross revenue over $25 million, (2) buys, sells, or shares personal information of 100,000+ California residents/households/devices, or (3) derives 50%+ of annual revenue from selling or sharing California residents' personal information. Even smaller businesses should comply proactively, as state privacy laws are proliferating nationwide.

Section 11

FTC Rules (Pricing & Transparency)

The Federal Trade Commission has issued rules specifically targeting deceptive pricing practices in e-commerce. The FTC's "Rule on Unfair or Deceptive Fees" (commonly called the Junk Fee Rule) takes effect May 12, 2025.

$53,088 Max Penalty Per Violation
May 12, 2025 Effective Date

Key Requirements

  • No bait-and-switch pricing: The advertised price must reflect what the consumer will actually pay. Hidden fees added at checkout violate the rule.
  • Total price prominence: The total price (including all mandatory fees) must be displayed more prominently than its component parts. You may not show a low base price in large text and bury fees in small print.
  • Fee disclosure: All non-optional fees must be disclosed clearly and conspicuously before the consumer makes a purchase decision — not for the first time on the final checkout page.
  • Drip pricing prohibited: The practice of revealing additional mandatory charges incrementally throughout the checkout process is considered unfair and deceptive.

Practical Implications for E-Commerce

  • Product listing pages must show the full price including any mandatory fees (handling, service fees, etc.).
  • Shipping costs, if not included in the product price, must be disclosed before the user initiates checkout.
  • Subscription pricing must clearly state the recurring charge, billing interval, and total commitment.
  • "Free trial" offers must clearly disclose what happens after the trial (automatic billing, required cancellation action).
Penalties Are Per-Violation

The FTC can assess penalties of up to $53,088 per violation. Each deceptive transaction can be counted as a separate violation. For an e-commerce site processing thousands of orders, exposure can escalate to millions of dollars.

Section 12

International Compliance Deadlines

Accessibility and privacy regulations are proliferating globally. The following timeline covers key deadlines through 2026 that affect e-commerce businesses operating internationally.

Deadline Regulation / Law Jurisdiction Standard Scope
May 1, 2025 Manitoba Accessibility Standard Manitoba, Canada WCAG 2.1 AA Obligated organizations with public-facing websites
May 12, 2025 FTC Junk Fee Rule United States FTC Act § 5 All businesses with fees in consumer transactions
June 28, 2025 European Accessibility Act (EAA) European Union (27 states) EN 301 549 / WCAG 2.1 AA E-commerce services, banking, transport, telecom
April 24, 2026 ADA Title II Digital Rule United States WCAG 2.1 AA State and local government websites and apps
June 2026 Accessible Canada Act (ACA) Canada (federal) ICT standard (WCAG-based) Federally regulated organizations
December 31, 2026 Ontario AODA Ontario, Canada WCAG 2.1 AA All public and private organizations with 50+ employees

Visual Timeline

May 1, 2025
Manitoba Accessibility Standard
WCAG 2.1 AA for obligated organizations in Manitoba, Canada
May 12, 2025
FTC Junk Fee Rule
All-in pricing, fee transparency for US e-commerce
June 28, 2025
European Accessibility Act (EAA)
EN 301 549 / WCAG 2.1 AA for e-commerce in all 27 EU member states
April 24, 2026
ADA Title II Digital Rule
WCAG 2.1 AA mandate for US state and local government web
June 2026
Accessible Canada Act (ACA)
Federal accessibility standard for Canadian regulated entities
December 31, 2026
Ontario AODA
WCAG 2.1 AA for private organizations with 50+ employees in Ontario
EU Accessibility Act: The Big One

The EAA is the broadest accessibility mandate in history. It requires all e-commerce services selling to EU consumers to comply with EN 301 549 (which maps to WCAG 2.1 AA) by June 28, 2025. This applies to non-EU businesses that serve EU customers. Each EU member state sets its own enforcement penalties, but they must be "effective, proportionate and dissuasive." If you sell to European customers, this is your most urgent deadline.

Section 13

Inclusive Design Patterns

Beyond meeting minimum compliance standards, inclusive design proactively accommodates the full range of human diversity in vision, motor control, cognition, and environmental conditions.

CSS Media Queries for Accessibility

/* Respect user's dark mode preference */ @media (prefers-color-scheme: dark) { :root { --bg: #1a1a2e; --text: #e2e8f0; } } /* Reduce motion for users who request it */ @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 0.01ms !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; } } /* Support Windows High Contrast Mode */ @media (forced-colors: active) { .btn { border: 2px solid ButtonText; } }

Color & Vision Considerations

  • Avoid pure black (#000) on pure white (#FFF): High-contrast extremes cause "halation" for users with astigmatism (affects roughly 33% of the population). The bright white bleeds into the dark text, making it harder to read. Use off-white backgrounds (#F8F9FA) and near-black text (#1A1A2E) instead.
  • Never rely on color alone: Use icons, patterns, text labels, or shape in addition to color to convey information. Red/green distinctions are invisible to roughly 8% of males.
  • Support dark mode: Use prefers-color-scheme to detect and respect the user's system preference. Provide a manual toggle as well.

Typography & Zoom

  • Use rem units for font sizes: This allows text to scale with the user's browser font size preference. Avoid px for body text.
  • Support 200% zoom (WCAG 1.4.4): All content and functionality must remain usable when the page is zoomed to 200%. No horizontal scrolling, no content overflow, no overlapping elements. Test by zooming your browser to 200% and completing a purchase.
  • Minimum body text size: 16px (1rem) base font size. Smaller sizes are acceptable for labels and captions but not for primary content.
  • Line height: 1.5 minimum for body text (WCAG 1.4.12). Allows users with dyslexia to track lines more easily.

Responsive & Adaptive Design

  • Content must reflow at 320px viewport width without horizontal scrolling (WCAG 1.4.10).
  • Touch targets should be larger on mobile than on desktop. The 44x44px AAA target is recommended for all mobile interactions.
  • Forms should use appropriate inputmode and autocomplete attributes to trigger the correct on-screen keyboard and autofill.
Section 14

Accessibility Testing Checklist

A comprehensive accessibility testing strategy combines automated scanning with manual testing. Automated tools catch only 30–40% of accessibility issues. The remaining 60–70% require human judgment.

Automated Testing Tools

Tool Type Cost Best For
axe DevTools Browser extension Free (core) / Paid (pro) In-browser page scanning, developer workflow integration
Lighthouse Built into Chrome DevTools Free Quick audits, CI/CD integration, performance + accessibility scoring
WAVE Browser extension / web service Free Visual overlay of issues on the page, structural analysis
Pa11y CLI / CI tool Free (open source) Automated CI/CD pipelines, batch testing, regression detection
Automated tools catch only 30–40% of WCAG issues

Automated scans are essential but insufficient. They can detect missing alt text, low contrast ratios, and missing form labels. They cannot evaluate whether alt text is meaningful, whether keyboard navigation is logical, whether error messages are helpful, or whether content is understandable. Every automated scan must be supplemented with manual testing.

Manual Testing Procedures

Keyboard Testing

  • Unplug the mouse. Navigate every page using only Tab, Enter, Space, Escape, and arrow keys.
  • Verify a visible focus indicator appears on every interactive element.
  • Confirm focus order follows logical reading order (left-to-right, top-to-bottom).
  • Open and close every modal, dropdown, and accordion with keyboard only.
  • Complete the full purchase flow from product page to order confirmation without a mouse.
  • Verify Escape closes modals and returns focus to the trigger element.
  • Test that skip links work and land on the correct target.

Screen Reader Testing

  • Navigate the page using heading shortcuts (H key in NVDA/JAWS). Verify headings are properly nested (H1 → H2 → H3).
  • Tab through all form fields and verify each is announced with its label and required status.
  • Submit a form with errors and verify errors are announced and navigable.
  • Add a product to cart and verify the cart update is announced (live region).
  • Verify product images have meaningful alt text (not "image1.jpg" or "photo").
  • Test with at least one of: NVDA + Firefox, VoiceOver + Safari.

Visual & Zoom Testing

  • Zoom browser to 200% and verify all content remains readable without horizontal scrolling.
  • Check all text contrast ratios meet AA minimums (4.5:1 normal, 3:1 large).
  • Verify focus indicators have 3:1 contrast against adjacent colors.
  • Test with Windows High Contrast mode or forced-colors: active emulation.
  • Confirm no information is conveyed by color alone (form errors, status indicators, required fields).

Content & Structure Testing

  • Verify every page has a unique, descriptive <title>.
  • Confirm the <html> element has a lang attribute.
  • Check that all images have appropriate alt attributes (descriptive or empty for decorative).
  • Verify landmarks are present: <header>, <nav>, <main>, <footer>.
  • Test that error messages explain the problem and how to fix it.
  • Verify links have descriptive text (not "click here" or "read more").

Testing Cadence Recommendation

When What Who
Every commit / PR Automated scan (axe-core in CI, Lighthouse CI) Development team (automated)
Every sprint Keyboard + screen reader test of new features QA / developer
Quarterly Full manual audit of critical user flows Accessibility specialist
Annually Third-party WCAG 2.2 AA conformance audit + VPAT update External auditor
Accessibility is Ongoing, Not a Project

A one-time audit and remediation is not sufficient. Every new feature, content update, and design change can introduce accessibility regressions. Build accessibility checks into your development workflow: linting rules, automated CI tests, design review checklists, and regular manual testing. The goal is to prevent issues, not just find and fix them.