# whatisADA.com > Independent accessibility education and implementation resources published by Grow Wild Agency. Use the linked primary sources, scope and update dates when evaluating legal or technical claims. The site separates legal applicability from technical WCAG conformance. Tools support limited checks or user-entered planning; they do not certify a website or predict litigation. Research-method pages identify their evidence and publication status. Canonical domain: https://whatisada.com XML sitemap: https://whatisada.com/sitemap.xml HTML directory: https://whatisada.com/sitemap # Complete resource directory ## "We're Too Small to Get Sued": 6 ADA Compliance Myths That Cost Small Businesses Thousands https://whatisada.com/blog/ada-small-business-myths Most ADA website demand letters land on small and mid-sized businesses — not big brands. Here are the six myths that leave small businesses exposed, and the reality behind each one. ## 2024 Title II Web Accessibility Final Rule https://whatisada.com/laws/2024-title-ii-web-rule The DOJ's April 2024 final rule establishes specific technical requirements for web and mobile app accessibility by state and local governments under ADA Title II. It mandates conformance with WCAG 2.1 Level AA. On April 20, 2026, the DOJ published an Interim Final Rule (91 Fed. Reg. 20902) that extended the original compliance dates by one year: large entities (population 50,000+) now have until April 26, 2027, and smaller entities have until April 26, 2028. This is the first federal rule to codify a specific WCAG version for ADA compliance. ## A Day Without Accessibility https://whatisada.com/stories/a-day-without-accessibility A scrollable story following one day of the barriers people with disabilities face online — and what an accessible web looks like instead. ## About https://whatisada.com/about Learn about whatisADA.com — our mission to make ADA education free, accessible, and accurate. Published by Grow Wild Agency. ## Accessibility Audit Scope Builder https://whatisada.com/tools/audit-scope-builder Document templates, representative URLs, complete processes, test environments and exclusions. ## Accessibility Audit Scope: What to Include Before You Buy https://whatisada.com/guides/accessibility-audit-scope Compare accessibility audit proposals by pages, user journeys, WCAG version, assistive technology testing, deliverables, and retesting. Includes a scope checklist. ## Accessibility Budget Worksheet https://whatisada.com/tools/remediation-cost Use your own quantities, hours, rates and contingency to build a transparent budget estimate. ## Accessibility Budgeting Method https://whatisada.com/research/remediation-cost How to estimate work using explicit assumptions and measured samples. ## Accessibility Checklist Generator https://whatisada.com/tools/checklist-generator Create a starting checklist for your content and technical target. Record progress and review the limits of the selected scope. ## Accessibility Coverage Guide https://whatisada.com/tools/exemption-checker Explore which legal frameworks may require further review based on your organization and activities. ## Accessibility HTML Scanner https://whatisada.com/tools/compliance-checker Fetch a public page and inspect selected accessibility rules in its HTML. Includes a prioritized findings list and clear limits on the checks. ## Accessibility Overlay https://whatisada.com/glossary/accessibility-overlay An accessibility overlay is a third-party JavaScript widget that claims to automatically detect and fix website accessibility issues, but independent research, court rulings, and disability advocacy organizations have consistently found that overlays do not deliver meaningful accessibility and may increase legal risk. ## Accessibility Prioritization Method https://whatisada.com/research/lawsuit-risk-index A transparent planning framework based on observed user impact. ## Accessibility Readiness Planner https://whatisada.com/tools/lawsuit-risk-calculator Mark documented accessibility work and download a practical next-step plan. No lawsuit prediction or settlement estimate. ## Accessibility Statement https://whatisada.com/accessibility-statement whatisADA.com is committed to WCAG 2.2 Level AA conformance. Read our full accessibility statement including testing methods, known limitations, and how to report issues. ## Accessibility workflows https://whatisada.com/workflows 80 practical testing, publishing and operational workflows. ## Accessible accordions: Examples and Testing https://whatisada.com/patterns/accordions An accordion organizes related expandable sections. ## Accessible autocomplete comboboxes: Examples and Testing https://whatisada.com/patterns/comboboxes A combobox combines an input or selection control with an associated popup. ## Accessible breadcrumbs: Examples and Testing https://whatisada.com/patterns/breadcrumbs Breadcrumbs communicate a page's location within a site hierarchy. ## Accessible buttons: Examples and Testing https://whatisada.com/patterns/buttons Use a native button for an action performed on the current page, such as saving a draft or opening a dialog. ## Accessible carousels: Examples and Testing https://whatisada.com/patterns/carousels A carousel needs understandable slide controls and an accessible way to stop automatic rotation when used. ## Accessible checkboxes: Examples and Testing https://whatisada.com/patterns/checkboxes Use a checkbox for an independently selectable choice. ## Accessible confirmation dialogs: Examples and Testing https://whatisada.com/patterns/alert-dialogs Use an alert dialog for a brief, important interruption that requires a response, such as confirming a consequential deletion. ## Accessible data tables: Examples and Testing https://whatisada.com/patterns/data-tables Use a table when cells have meaningful row and column relationships. ## Accessible disclosure controls: Examples and Testing https://whatisada.com/patterns/disclosures A disclosure reveals or hides a section in place. ## Accessible dropdown navigation: Examples and Testing https://whatisada.com/patterns/navigation-disclosures Most website dropdown navigation is a disclosure containing ordinary links, not an application menu. ## Accessible file upload controls: Examples and Testing https://whatisada.com/patterns/file-uploads Keep a labeled native file input available even when a drag-and-drop area is offered. ## Accessible form error summaries: Examples and Testing https://whatisada.com/patterns/error-summaries An error summary gives users a compact route to all detected problems after submission. ## Accessible Forms: The Highest-ROI Fix for ADA Compliance and Conversion Rates https://whatisada.com/blog/accessible-forms-roi Roughly half of the web's home pages have unlabeled form fields. Forms are where accessibility and revenue collide — fix them well and you reduce legal risk and lift conversions at the same time. ## Accessible heading structures: Examples and Testing https://whatisada.com/patterns/headings Use heading elements to express the content's hierarchy, and write headings that describe their sections. ## Accessible inline validation errors: Examples and Testing https://whatisada.com/patterns/inline-errors Inline errors identify the affected field and explain what must change. ## Accessible interface patterns https://whatisada.com/patterns 40 patterns with implementation guidance and testing examples. ## Accessible links: Examples and Testing https://whatisada.com/patterns/links Use a real anchor with a destination when the purpose is navigation. ## Accessible listboxes: Examples and Testing https://whatisada.com/patterns/listboxes A listbox presents selectable options with a managed keyboard interaction model. ## Accessible meters and gauges: Examples and Testing https://whatisada.com/patterns/meters A meter describes a scalar measurement within a known range, such as storage used. ## Accessible modal dialogs: Examples and Testing https://whatisada.com/patterns/modal-dialogs A modal dialog temporarily makes the rest of the page unavailable while the user completes a focused task. ## Accessible numeric inputs: Examples and Testing https://whatisada.com/patterns/number-inputs Use numeric controls when the value is a quantity, and explain units, bounds and valid increments. ## Accessible page landmarks: Examples and Testing https://whatisada.com/patterns/landmarks Landmarks identify major page regions such as navigation, main content, search and the footer. ## Accessible pagination: Examples and Testing https://whatisada.com/patterns/pagination Pagination needs understandable page links, a current-page indication and predictable behavior when results change. ## Accessible password fields: Examples and Testing https://whatisada.com/patterns/password-fields Password inputs need clear labels, appropriate autocomplete and support for password managers and paste. ## Accessible progress indicators: Examples and Testing https://whatisada.com/patterns/progress-indicators Use a progress indicator for completion of an ongoing task. ## Accessible radio groups: Examples and Testing https://whatisada.com/patterns/radio-groups Radio buttons let users choose one option within a named group. ## Accessible range sliders: Examples and Testing https://whatisada.com/patterns/range-sliders A slider selects a value from an ordered range. ## Accessible search forms: Examples and Testing https://whatisada.com/patterns/search-forms A search form needs a discoverable search region, a labeled query field, a clear submit action and understandable results. ## Accessible select controls: Examples and Testing https://whatisada.com/patterns/selects For a straightforward choice from a fixed list, a native select supplies familiar keyboard and platform behavior. ## Accessible skip links: Examples and Testing https://whatisada.com/patterns/skip-links A skip link lets keyboard users bypass repeated navigation and reach the page's main task. ## Accessible sortable tables: Examples and Testing https://whatisada.com/patterns/sortable-tables A sortable table retains its table structure while exposing sorting as an action in the relevant header. ## Accessible status messages: Examples and Testing https://whatisada.com/patterns/status-messages Routine status messages should communicate results without taking focus. ## Accessible switches: Examples and Testing https://whatisada.com/patterns/switches A switch represents a setting that is on or off. ## Accessible tab interfaces: Examples and Testing https://whatisada.com/patterns/tabs Tabs switch among associated panels within a single interface. ## Accessible term and value lists: Examples and Testing https://whatisada.com/patterns/description-lists A description list expresses associations between terms and their descriptions or values. ## Accessible text areas: Examples and Testing https://whatisada.com/patterns/textareas Use a labeled textarea for multiline input. ## Accessible text inputs: Examples and Testing https://whatisada.com/patterns/text-inputs Give text inputs visible labels and explain important constraints before entry. ## Accessible toggle buttons: Examples and Testing https://whatisada.com/patterns/toggle-buttons A toggle button represents an on/off state for an action or mode. ## Accessible toolbars: Examples and Testing https://whatisada.com/patterns/toolbars A toolbar groups a related set of controls and, when using the ARIA toolbar pattern, provides efficient keyboard movement within that group. ## Accessible tooltips and help text: Examples and Testing https://whatisada.com/patterns/tooltips A tooltip supplies a brief description for a focused or hovered control. ## Accessible tree views: Examples and Testing https://whatisada.com/patterns/tree-views A tree represents a hierarchical collection with expandable branches and a full tree keyboard model. ## Accessible urgent alerts: Examples and Testing https://whatisada.com/patterns/alerts Use an alert for important, time-sensitive information that needs prompt announcement without requiring focus. ## ADA (Americans with Disabilities Act) https://whatisada.com/glossary/ada The Americans with Disabilities Act (ADA) is a landmark U.S. civil rights law enacted in 1990 that prohibits discrimination against individuals with disabilities in all areas of public life, including employment, education, transportation, and access to public and private places open to the general public. ## ADA & Web Accessibility FAQ (2026) https://whatisada.com/faq The definitive ADA website compliance FAQ — Title II IFR extension, WCAG 2.1 AA, lawsuit costs, overlay widgets, exemptions, deadlines, and more. Plain-English answers grounded in current law. ## ADA & Web Accessibility Glossary https://whatisada.com/glossary Comprehensive glossary of ADA, WCAG, and web accessibility terms. Find clear definitions for accessibility concepts, legal terms, technical standards, and more. ## ADA Compliance https://whatisada.com/glossary/ada-compliance ADA compliance means meeting the requirements of the Americans with Disabilities Act to ensure that people with disabilities have equal access to facilities, services, employment, and digital content — including websites and mobile applications. ## ADA Compliance & Web Accessibility Guides https://whatisada.com/guides Free in-depth guides on ADA compliance, WCAG standards, web accessibility best practices, and digital inclusion. Written for developers, business owners, and legal teams. ## ADA Compliance Audit https://whatisada.com/glossary/ada-compliance-audit A systematic evaluation of a website, application, or physical space to determine whether it meets ADA requirements and WCAG standards for accessibility. ## ADA Compliance by Industry https://whatisada.com/industries Industry-specific ADA compliance guides covering regulations, common violations, lawsuit statistics, and actionable checklists for 14 industries. ## ADA Compliance by Platform https://whatisada.com/platforms Whether a CMS or site builder is "ADA compliant" depends on the theme, the plugins, and the content on top of it. Platform-by-platform guides to what each one does and does not handle. ## ADA Compliance Checklist: All 50 WCAG 2.1 AA Items (2026) https://whatisada.com/requirements/checklist A practical 50-item ADA website compliance checklist mapped to WCAG 2.1 Level AA, grouped by the WebAIM Big Six and the POUR principles. Print, audit, ship. ## ADA Compliance Deadlines: April 2027 & 2028 (DOJ IFR) https://whatisada.com/deadlines Compare ADA Title II and HHS Section 504 web accessibility deadlines, the 2026 extensions, and which organizations each rule covers. ## ADA Compliance for Automotive: The Complete Guide https://whatisada.com/industries/automotive Car dealerships, manufacturers, and auto service websites face growing ADA lawsuit risk. Learn how to protect your digital presence. ## ADA Compliance for Construction: The Complete Guide https://whatisada.com/industries/construction Construction and building industry websites must meet ADA digital requirements alongside physical accessibility standards. ## ADA Compliance for E-Commerce: The Complete Guide https://whatisada.com/industries/ecommerce Online retailers are the #1 target for ADA lawsuits. Learn how to make your store accessible and protect your business. ## ADA Compliance for Education: The Complete Guide https://whatisada.com/industries/education Schools, universities, and edtech platforms must ensure digital learning is accessible to all students under ADA and Section 504. ## ADA Compliance for Financial Services: The Complete Guide https://whatisada.com/industries/financial-services Banks, credit unions, fintech, and investment firms must ensure equal digital access to financial tools and information. ## ADA Compliance for Government: The Complete Guide https://whatisada.com/industries/government Federal, state, and local government websites must meet strict accessibility standards under ADA Title II and Section 508. ## ADA Compliance for Healthcare: The Complete Guide https://whatisada.com/industries/healthcare HIPAA meets ADA: everything healthcare organizations need to know about web accessibility compliance, from patient portals to telehealth. ## ADA Compliance for Hospitality: The Complete Guide https://whatisada.com/industries/hospitality Hotels, restaurants, and travel companies must make reservation systems and digital services accessible to all guests. ## ADA Compliance for Insurance: The Complete Guide https://whatisada.com/industries/insurance Insurance companies must make policy information, quote tools, and claims processes digitally accessible to all customers. ## ADA Compliance for Legal: The Complete Guide https://whatisada.com/industries/legal Law firms and legal services face unique ADA challenges. Learn how to make client portals, case documents, and legal websites accessible. ## ADA Compliance for Nonprofits: The Complete Guide https://whatisada.com/industries/nonprofit Nonprofits serving the public must ensure their websites and digital programs are accessible, often with limited budgets. ## ADA Compliance for Professional Services: The Complete Guide https://whatisada.com/industries/professional-services Consulting firms, accounting practices, and professional service providers must ensure their digital presence is accessible to all clients. ## ADA Compliance for Real Estate: The Complete Guide https://whatisada.com/industries/real-estate Real estate websites, property listings, and virtual tours must be accessible under ADA and Fair Housing requirements. ## ADA Compliance for SaaS: The Complete Guide https://whatisada.com/industries/saas Software-as-a-Service companies must build accessibility into their products to meet customer requirements and avoid legal risk. ## ADA Compliance News & Analysis https://whatisada.com/blog Stay informed on ADA website compliance news, lawsuit roundups, regulatory changes, technical tutorials, and expert analysis. ## ADA Employment Requirements: What Employers Need to Know https://whatisada.com/guides/ada-employment-requirements Learn about ADA employment requirements, including reasonable accommodations, the interactive process, and employer obligations under Title I. Covers hiring, workplace policies, and digital accessibility for employees. ## ADA Laws & Regulations: Title II, Title III, Section 504/508, EAA, State https://whatisada.com/laws Comprehensive reference of ADA federal laws (Title II 2024 rule + April 2026 IFR, Title III + Robles/Winn-Dixie circuit split, Section 504 HHS, Section 508), WCAG standards, state accessibility laws (Unruh, NYCHRL, IL HRA, Florida), EAA, and key court rulings. ## ADA Lawsuit https://whatisada.com/glossary/ada-lawsuit An ADA lawsuit is a civil rights legal action filed under the Americans with Disabilities Act alleging that a business or organization has discriminated against people with disabilities by failing to provide accessible facilities, services, or digital experiences. ## ADA Requirements for Websites: WCAG 2.1 AA (2026) https://whatisada.com/requirements All 50 WCAG 2.1 AA criteria behind ADA website requirements, who must comply, and a plain-English checklist — updated for the April 2026 DOJ rule. ## ADA Standards for Accessible Design (2010) https://whatisada.com/laws/ada-standards-accessible-design The 2010 ADA Standards for Accessible Design set the technical requirements for the design and construction of facilities covered by ADA Titles II and III. While primarily focused on physical accessibility (buildings, public spaces, transit facilities), these standards establish the baseline physical accessibility requirements that complement digital accessibility obligations and inform the broader framework of ADA compliance. ## ADA Title I: Employment https://whatisada.com/laws/ada-title-i Title I of the ADA prohibits private employers, state and local governments, employment agencies, and labor unions from discriminating against qualified individuals with disabilities in job application procedures, hiring, firing, advancement, compensation, job training, and other terms and conditions of employment. Employers with 15 or more employees must provide reasonable accommodations to qualified applicants and employees with disabilities unless doing so would cause undue hardship. ## ADA Title II Compliance: A Practical Guide for Government Agencies https://whatisada.com/guides/ada-title-ii-government-compliance-guide A practical guide for government IT and compliance officers on ADA Title II: the WCAG 2.1 AA deadlines under the April 2026 DOJ Interim Final Rule, self-evaluation and transition plans, VPATs in procurement, and where to start. ## ADA Title II: Public Services https://whatisada.com/laws/ada-title-ii Title II of the ADA prohibits state and local governments from discriminating against people with disabilities in all services, programs, and activities. This includes public transportation, court systems, voting, education, and, following the 2024 rulemaking, websites and mobile applications. It is one of the most frequently cited titles in digital accessibility enforcement. ## ADA Title III https://whatisada.com/glossary/ada-title-iii ADA Title III prohibits discrimination on the basis of disability in places of public accommodation operated by private entities, including hotels, restaurants, retail stores, healthcare providers, and — as courts and the DOJ have increasingly affirmed — their websites and digital services. ## ADA Title III & Websites: The Robles/Winn-Dixie Circuit Split Explained https://whatisada.com/laws/title-iii ADA Title III applies to private businesses — and to their websites, per Robles v. Domino's (9th Cir. 2019). Plus the 11th Circuit Winn-Dixie split, 2025 lawsuit data, and what compliance looks like. ## ADA Title III: Public Accommodations https://whatisada.com/laws/ada-title-iii Title III of the ADA prohibits discrimination on the basis of disability in places of public accommodation operated by private entities. This includes restaurants, hotels, theaters, retail stores, doctors offices, and increasingly, websites and digital platforms. Title III is the basis for most ADA web accessibility lawsuits against private businesses. ## ADA vs. WCAG vs. Section 508: What's the Difference? https://whatisada.com/guides/ada-vs-wcag-vs-section-508 Understand the differences between ADA, WCAG, and Section 508. Learn which applies to your organization, how they overlap, and which standard to follow. ## ADA Website Compliance Statistics (Updated Monthly) https://whatisada.com/statistics Every sourced, dated statistic on ADA website lawsuits, WCAG failure rates, settlement costs, and compliance deadlines in one place — updated monthly, every number linked to its primary source. ## ADA Website Compliance, Explained (2026) https://whatisada.com/ ADA website compliance in plain English — who the law covers, the WCAG 2.1 AA standard, 2027 deadlines, lawsuit costs, and the six fixes that matter most. ## ADA Website Exemptions (2026): Who Is Actually Exempt? https://whatisada.com/exemptions Most "I think I'm exempt" answers turn out to be "you're covered." The real ADA exemptions: 28 C.F.R. § 35.201 (Title II), Title III religious + private clubs, EAA microenterprise. Decision tree included. ## ADA Website Guidelines (2026): The Standards That Define Compliance https://whatisada.com/guidelines The technical guidelines behind ADA website compliance — WCAG 2.0 / 2.1 / 2.2, Section 508, EN 301 549, and the four POUR principles that organize all of them. ## ADA Website Lawsuit Statistics 2025: Federal Filings, Costs, States, Industries https://whatisada.com/laws/lawsuit-statistics-2025 The 2025 ADA website accessibility lawsuit dataset: 8,667 total Title III filings, 3,117 website cases (+27% YoY), state breakdown, industry distribution, and settlement cost ranges. ## ADA Website Lawsuits in 2025: Year in Review https://whatisada.com/blog/ada-website-lawsuits-2025-review A comprehensive look at ADA website accessibility lawsuit trends in 2025 — 3,117 federal filings, a 27% year-over-year increase, the top filing states, and what businesses should expect in 2026. ## ADA Website Lawsuits in 2026: The Mid-Year Trends Every Business Should Watch https://whatisada.com/blog/ada-lawsuits-2026-midyear-trends Federal website accessibility lawsuits hit 3,117 in 2025 — a 27% jump. Here is what is driving the 2026 filings, which states and industries carry the most risk, and how to stay off the target list. ## ADA Website Lawsuits: Everything You Need to Know (2026) https://whatisada.com/guides/ada-website-lawsuits Learn about ADA website lawsuit trends, serial plaintiffs, average settlement costs, and how to respond if your business receives a demand letter in 2026. ## ADA Website Requirements by Industry (2026) https://whatisada.com/requirements/by-industry Industry-specific ADA web accessibility requirements: e-commerce, healthcare, hospitality, financial, government, education. 2025 lawsuit distribution + the rules that apply to your sector. ## Add and Check Captions in PowerPoint Media https://whatisada.com/workflows/powerpoint-video-captions Provide and verify captions for meaningful audio in presentation media. ## Alt Text: The Complete Guide https://whatisada.com/guides/alt-text-guide Master alt text for web accessibility. Learn when to use descriptive alt text, when to leave it empty, see real-world examples, and avoid common mistakes. ## Are overlays ever useful? https://whatisada.com/faq/are-overlays-ever-useful Some overlay features (font sizing, high-contrast mode) replicate functionality modern browsers and operating systems already provide natively and more rel ## Are religious organizations exempt from the ADA? https://whatisada.com/faq/are-religious-organizations-exempt-from-the-ada For Title III (public accommodations): yes, per 42 U.S.C. § 12187. The exemption applies to religious organizations and entities controlled by them. The ex ## ARIA (Accessible Rich Internet Applications) https://whatisada.com/glossary/aria ARIA (Accessible Rich Internet Applications) is a set of HTML attributes defined by the W3C that add semantic meaning to web elements, enabling assistive technologies like screen readers to understand and interact with dynamic content and custom interface components. ## Audio Description https://whatisada.com/glossary/audio-description Audio description is a narration track added to video content that describes important visual information, actions, and scene changes during natural pauses in dialogue, making video accessible to people who are blind or have low vision. ## Audit a Donation Form and Recurring Gift Flow https://whatisada.com/workflows/donation-form-audit Review how a donor selects an amount, frequency and payment route, then understands the commitment. ## Audit a Government Permit Application https://whatisada.com/workflows/government-permit-accessibility-audit Review the permit process across instructions, eligibility, uploads, fees and submission status. ## Audit a Hotel Booking and Room Selection https://whatisada.com/workflows/hotel-booking-accessibility-audit Review search dates, room selection, rate conditions and reservation review. ## Audit a Library Search and Hold Request https://whatisada.com/workflows/library-catalog-audit Test discovery, filtering, item details and placing a hold as one connected task. ## Audit a Page's Heading Outline https://whatisada.com/workflows/heading-outline-audit Compare the visible sections of a page with its semantic heading structure. ## Audit a Student Admissions Application https://whatisada.com/workflows/student-admissions-audit Review an admissions process across program choice, eligibility questions, documents and status tracking. ## Audit a Third-Party Embed in Context https://whatisada.com/workflows/third-party-embed-review Test an embedded widget as part of the page and the complete user process. ## Audit a WordPress Form Plugin Output https://whatisada.com/workflows/wordpress-form-plugin-review Test the complete form produced by the site's configured plugin and theme. ## Audit an Appointment Booking Journey https://whatisada.com/workflows/appointment-booking-audit Review the booking process from service choice to confirmation and rescheduling information. ## Audit an Ecommerce Purchase Journey https://whatisada.com/workflows/ecommerce-checkout-audit Scope a purchase from product discovery to confirmation, including variants, stock changes and payment-provider boundaries. ## Audit an Insurance Quote Questionnaire https://whatisada.com/workflows/insurance-quote-accessibility-audit Review a quote journey with changing questions, validation and a final comparison. ## Audit an Online Job Application Process https://whatisada.com/workflows/job-application-audit Test an application from vacancy discovery through document upload and submission review. ## Audit Link Text and Destination Clarity https://whatisada.com/workflows/link-text-audit Review whether readers can determine where links lead from their text and available context. ## Audit Page and Passage Language Markup https://whatisada.com/workflows/page-language-audit Review the language identified for the page and for meaningful passages in another language. ## Audit Sign-In and Account Recovery https://whatisada.com/workflows/account-recovery-accessibility-audit Test account access and recovery without relying on memory puzzles or a single sensory channel. ## Audit Statement Discovery and Download https://whatisada.com/workflows/bank-statement-accessibility-review Review how an account holder locates, downloads and reads a statement. ## Audit Ticket Selection and Seat Booking https://whatisada.com/workflows/event-ticketing-accessibility-audit Review event choice, ticket quantity, seat selection and checkout. ## Build an Inventory of Page Templates and Components https://whatisada.com/workflows/accessibility-template-inventory Create a map of the structures that generate the site before choosing audit pages. ## California Unruh Civil Rights Act https://whatisada.com/laws/california-unruh-act The California Unruh Civil Rights Act is a state civil rights law that provides broader protections than the federal ADA, including a minimum of $4,000 in statutory damages per violation. California courts have held that ADA violations automatically constitute Unruh Act violations, making California the most active state for web accessibility litigation due to the availability of monetary damages not available under federal ADA Title III. ## Can automated tools achieve full ADA compliance? https://whatisada.com/faq/can-automated-tools-achieve-full-ada-compliance No. Automated tools (axe-core, WAVE, Lighthouse) catch 30-40% of WCAG failures. Manual assistive-technology testing — screen reader, keyboard-only, focus, ## Can I get sued for ADA violations if I've never been asked to fix my website first? https://whatisada.com/faq/can-i-get-sued-without-a-warning-first In most of the country, yes — federal ADA Title III does not require a plaintiff to send a demand letter or offer a cure period before filing suit, so the ## Check Focus Behind Sticky Headers and Banners https://whatisada.com/workflows/sticky-header-focus Test whether focused controls are hidden by sticky or fixed content. ## Check PDF Table Headers and Cell Relationships https://whatisada.com/workflows/pdf-table-headers Inspect a PDF table at the cell and header-association level. ## Choose an Image Alternative by Purpose https://whatisada.com/workflows/alt-text-decision-review Decide what an image contributes in its specific context before writing alt text. ## Choose the Appropriate VPAT Edition https://whatisada.com/workflows/choose-vpat-edition Identify the reporting standard requested by the buyer before selecting an ITI VPAT® edition. ## Color Contrast Checker https://whatisada.com/tools/color-contrast-checker Compare a valid foreground and background color pair against WCAG contrast thresholds. ## Color Contrast Ratio https://whatisada.com/glossary/color-contrast-ratio Color contrast ratio is a mathematical measurement of the luminance difference between foreground text and its background color, used by WCAG to ensure text is readable for people with low vision or color vision deficiencies. ## Colorado's Website Accessibility Law, Explained https://whatisada.com/laws/colorado What Colorado's HB21-1110 and SB23-244 require of state and local government websites, the WCAG 2.1 standard adopted, the 2024 deadline, and how to comply. ## Common Accessibility Barriers Quiz https://whatisada.com/tools/big-six-quiz Review six common categories of accessibility barriers and identify topics for further testing. ## Contact Us https://whatisada.com/contact Have a question about ADA compliance, found an error on the site, or want to contribute? Get in touch with the whatisADA.com team. ## Contribute https://whatisada.com/contribute Share your accessibility expertise with thousands of readers. Learn about our guest contributor guidelines, content types, editorial standards, and submission process. ## Cookie Policy https://whatisada.com/legal/cookie-policy Cookie policy for whatisADA.com — what cookies we use, why we use them, and how you can control them. ## Create a Role-Based Accessibility Training Plan https://whatisada.com/workflows/accessibility-training-plan Connect training to the decisions each team makes and the defects the product actually has. ## Create a Text Alternative for a Data Chart https://whatisada.com/workflows/chart-text-alternative Make the chart's message and relevant data available without requiring visual interpretation. ## Create an Accessibility Regression Test Plan https://whatisada.com/workflows/accessibility-regression-plan Protect important repaired behavior with a small set of meaningful repeatable tests. ## Did HHS also extend its Section 504 deadlines? https://whatisada.com/faq/did-hhs-also-extend-its-section-504-deadlines Yes. HHS issued its own May 2026 interim final rule. The WCAG 2.1 AA compliance dates are May 11, 2027 for recipients with 15 or more employees and May 10, ## Did the IFR pause litigation? https://whatisada.com/faq/did-the-ifr-pause-litigation No. Title II's nondiscrimination mandate remains in full force. Private plaintiffs can still sue during the extension. DOJ stated it "fully anticipates imp ## Do accessibility overlay widgets make my website ADA compliant? https://whatisada.com/faq/do-accessibility-overlays-make-my-website-ada-compliant No. The FTC fined accessiBe $1 million in April 2025 for falsely claiming its overlay made websites WCAG-compliant. EcomBack reports 22.64% of websites sue ## Do small businesses need to comply with the ADA? https://whatisada.com/faq/do-small-businesses-need-to-comply-with-the-ada Yes. ADA Title III has no small-business carve-out for websites. The 15-employee threshold applies to ADA Title I (employment), not Title III (public accom ## Does ADA compliance apply to social media content or just websites? https://whatisada.com/faq/does-ada-compliance-apply-to-social-media It can extend beyond your website. The DOJ's 2024 Title II rule specifically lists "social media content when used as an official communication channel" as ## Does the ADA apply to mobile apps? https://whatisada.com/faq/does-the-ada-apply-to-mobile-apps Yes. In Robles v. Domino's Pizza (2019), the Ninth Circuit held that Domino's mobile ordering app — not just its website — was subject to ADA Title III's a ## Does the ADA Apply to Mobile Apps? Compliance Guide https://whatisada.com/guides/mobile-app-ada-compliance Native mobile apps are increasingly treated the same as websites under the ADA. Learn the public-accommodation legal theory, why WCAG 2.1 AA is the practical benchmark for apps, and how VoiceOver, TalkBack, and platform accessibility APIs fit in. ## Does Your Website Need to Be ADA Compliant? https://whatisada.com/guides/does-my-website-need-ada-compliance Who ADA Title II and Title III cover, the current 2027/2028 government deadlines, what WCAG 2.1 AA means in practice, and how to check your own site. ## DOJ Guidance on Web Accessibility https://whatisada.com/laws/doj-web-guidance The DOJ has issued multiple guidance documents affirming that the ADA applies to websites, establishing that web accessibility is a civil rights obligation for both government entities and private businesses. This guidance, while not carrying the force of a formal regulation for Title III, has been cited by courts nationwide and represents the DOJ's authoritative interpretation of the ADA's application to digital content. ## DOJ Title II Web Rule (2024) + April 2026 IFR Extension Explained https://whatisada.com/laws/title-ii-2024-rule The DOJ's April 24, 2024 ADA Title II web accessibility final rule — and the April 20, 2026 Interim Final Rule that extended compliance dates by one year to April 26, 2027 and April 26, 2028. ## Domino's Pizza v. Robles (2019) https://whatisada.com/laws/dominos-v-robles In this landmark Ninth Circuit decision, the court held that the ADA applies to Domino's Pizza's website and mobile app, rejecting the company's argument that the lack of specific DOJ web accessibility regulations meant websites were not covered. The court ruled that the ADA's requirement that places of public accommodation provide full and equal enjoyment extends to websites and mobile apps with a nexus to a physical location. The Supreme Court declined to hear Domino's appeal, letting the ruling stand. ## European Accessibility Act: Scope, Exemptions and Website Reviews https://whatisada.com/laws/eaa-international Understand the EAA’s covered product and service categories, the service microenterprise exemption, and how to scope a technical accessibility review. ## Evaluate a Vendor Accessibility Conformance Report https://whatisada.com/workflows/review-vendor-acr Read an ACR as evidence about a specific product version and evaluation scope. ## Export and Verify a Tagged PDF from Word https://whatisada.com/workflows/word-accessible-pdf-export Treat PDF export as a separate quality checkpoint after repairing the Word source. ## Florida Accessibility Laws https://whatisada.com/laws/florida-accessibility Florida has enacted several laws addressing disability accessibility, including the Florida Americans with Disabilities Accessibility Implementation Act and the Florida Civil Rights Act. Notably, Florida passed legislation in 2021 and 2023 aimed at curbing what legislators characterized as abusive ADA accessibility lawsuits, establishing specific procedural requirements and limitations that affect web accessibility litigation in the state. ## Free Accessibility Tools: Testing, Planning and Evidence https://whatisada.com/tools Use 12 free accessibility tools for contrast, headings, WCAG criteria, HTML scanning, audit scope, budgets and ACR preparation. ## Free ADA Website Audit https://whatisada.com/free-ada-audit Get a free preliminary WCAG 2.1 AA scan of your website, focused on the WebAIM Big Six failure types, plus a fixed-scope remediation quote from Grow Wild Agency. ## Gil v. Winn-Dixie (2017/2021) https://whatisada.com/laws/gil-v-winn-dixie Gil v. Winn-Dixie was the first ADA web accessibility case to go to a full federal trial. The district court ruled in favor of the blind plaintiff, finding Winn-Dixie's website inaccessible. However, the Eleventh Circuit reversed on appeal in 2021, holding that a website is not itself a place of public accommodation under the ADA and that the plaintiff lacked standing because the website's inaccessibility did not prevent him from accessing the physical store. This created a significant circuit split with the Ninth Circuit's Robles decision. ## Grow Wild Agency — ADA Web Accessibility Research https://whatisada.com/research Accessibility planning methods from Grow Wild Agency: prioritizing repairs, estimating budgets and a clearly labeled proposed overlay study. ## Handle an Accessibility Feedback Report https://whatisada.com/workflows/accessibility-feedback-triage Turn a visitor's report into a respectful support response and a reproducible product issue. ## Heading Structure Validator https://whatisada.com/tools/heading-validator Inspect heading markup and review its hierarchy, labels and potential structural problems. ## HHS Extended the Section 504 Web Deadlines: A Healthcare Action Plan https://whatisada.com/blog/section-504-deadline-healthcare HHS moved its WCAG 2.1 AA deadlines to May 2027 and May 2028. Check your employee threshold, inventory patient journeys, and plan testing and remediation. ## HHS Section 504 Web Accessibility Deadlines: 2027 & 2028 https://whatisada.com/laws/section-504-hhs HHS extended its WCAG 2.1 AA web and mobile deadlines to May 11, 2027 and May 10, 2028. Check coverage, employee thresholds, and next steps. ## How do I make a PDF accessible? https://whatisada.com/faq/how-do-i-make-a-pdf-accessible An accessible PDF needs a logical tag structure (headings, lists, tables), alt text for images, a defined reading order, a specified document language, suf ## How many ADA website lawsuits were filed in 2025? https://whatisada.com/faq/how-many-ada-website-lawsuits-were-filed-in-2025 3,117 federal website accessibility lawsuits in 2025 — a 27% increase over 2024. Top filing states: NY (1,021), FL (961), IL (585). Illinois alone was up 7 ## How Much Does ADA Website Compliance Cost? https://whatisada.com/guides/ada-compliance-cost Understand the real costs of ADA website compliance, from initial audits to remediation and ongoing monitoring, broken down by business size and website type. ## How much does an ADA lawsuit cost? https://whatisada.com/faq/how-much-does-an-ada-lawsuit-cost Demand-letter settlements: $1,000–$25,000. Out-of-court settlements: ~$25,000 average, up to $100,000. Court judgments: ~$75,000 average. Class actions: $6 ## How often should I re-test my website for accessibility? https://whatisada.com/faq/how-often-should-i-retest-my-website-for-accessibility At minimum, once a year, plus after any significant change — a redesign, a new feature, a platform migration, or a CMS update. Many organizations now pair ## How to Check If Your Website Is ADA Compliant (Self-Service Guide) https://whatisada.com/guides/how-to-check-website-ada-compliance A step-by-step self-check for non-technical site owners: run a free automated scan, test keyboard navigation, try a screen reader, check color contrast, alt text, and form labels. Honest about what this does and doesn't prove. ## How to Make a Website ADA Compliant: The 7-Step Process (2026) https://whatisada.com/guides/how-to-make-website-ada-compliant A practical 7-step process for making a website ADA compliant under WCAG 2.1 Level AA — audit, remediation priorities, manual testing, accessibility statement, and ongoing monitoring. ## How to Run a DIY ADA Website Audit This Afternoon (Free Tools + When to Call a Pro) https://whatisada.com/blog/diy-ada-website-audit You can get a real, honest read on your website's accessibility in a couple of hours using free tools and a keyboard. Here's the step-by-step — and the clear line where DIY ends and a professional audit begins. ## Identify Audio Description Needs in Video https://whatisada.com/workflows/audio-description-review Review visual information that a listener cannot obtain from the existing audio. ## Illinois Information Technology Accessibility Act https://whatisada.com/laws/illinois-itaa The Illinois Information Technology Accessibility Act (ITAA) requires all Illinois state agencies and universities to ensure that their websites, information technology systems, and electronic content are accessible to people with disabilities. Enacted in 2007, the ITAA was one of the earliest state laws specifically addressing digital accessibility and references the Section 508 standards and WCAG as its benchmarks. ## Inspect and Repair a PDF Tag Tree https://whatisada.com/workflows/pdf-tag-structure Review whether PDF tags represent the document's actual structure. ## Is ADA compliance mandatory for websites? https://whatisada.com/faq/is-ada-compliance-mandatory-for-websites For state and local government sites: yes, under ADA Title II and the DOJ 2024 final rule. For private businesses: there is no formal DOJ deadline, but Tit ## Is archived web content exempt? https://whatisada.com/faq/is-archived-web-content-exempt Under ADA Title II (28 C.F.R. § 35.201): archived content is exempt if it is (1) maintained exclusively for reference/research/recordkeeping, (2) not updat ## Is WordPress ADA Compliant? A Builder's Guide https://whatisada.com/platforms/wordpress-ada-compliance Whether WordPress core, your theme, your plugins, or your content decides accessibility, what 'accessibility-ready' really covers, and how to check your site. ## Kaden Ewald — Author & Accessibility Engineer https://whatisada.com/authors/kaden-ewald Kaden Ewald is Founder and Lead Accessibility Engineer at Grow Wild Agency, and the author of whatisADA.com. Credentials, areas of expertise, and everything he has published here. ## Keyboard Accessibility: Building a Mouse-Free Web https://whatisada.com/guides/keyboard-accessibility Learn how to build keyboard-accessible websites with proper tab order, visible focus indicators, skip navigation, and focus trapping for modal dialogs. ## Keyboard Navigation https://whatisada.com/glossary/keyboard-navigation Keyboard navigation is the ability to use a website or application entirely through keyboard input — using Tab, Enter, arrow keys, and other keys — without requiring a mouse, which is essential for users with motor disabilities and screen reader users. ## Measure Text Contrast on Images and Gradients https://whatisada.com/workflows/contrast-on-images-and-gradients Review the actual background behind text when it varies across an image or gradient. ## Murphy v. Eyebobs (Overlay Case) https://whatisada.com/laws/murphy-v-eyebobs Murphy v. Eyebobs and similar cases represent a growing body of litigation challenging the effectiveness of accessibility overlay tools. In these cases, plaintiffs who are blind or visually impaired have sued businesses whose websites used accessibility overlays (such as accessiBe, AudioEye, and similar products) and argued that the overlays did not actually make the websites accessible. These cases have undermined the marketing claims of overlay vendors and reinforced that automated overlay solutions do not constitute ADA compliance. ## New York Human Rights Law https://whatisada.com/laws/new-york-human-rights-law The New York State Human Rights Law and the New York City Human Rights Law provide extensive disability discrimination protections that complement and, in some cases, exceed the federal ADA. New York is the second most active jurisdiction for web accessibility lawsuits, with both state and city laws offering compensatory damages and broader coverage than federal Title III. New York City's law is considered one of the most protective civil rights statutes in the country. ## PDF Accessibility: How to Make PDFs ADA/WCAG Compliant https://whatisada.com/guides/pdf-accessibility A practical guide to PDF accessibility: why PDFs are commonly inaccessible, what tagged PDF and the PDF/UA standard require, how to check a PDF's accessibility, and a step-by-step remediation workflow for ADA and Section 508 compliance. ## POUR Principles: Perceivable, Operable, Understandable, Robust (WCAG) https://whatisada.com/guidelines/pour-principles The four POUR principles organize all 78 WCAG 2.1 success criteria. Plain-English explanations with real examples for each principle and what failing each one looks like in practice. ## Prepare Accessibility Requirements for an RFP https://whatisada.com/workflows/accessibility-rfp-requirements Describe the accessibility outcomes and evidence needed for the actual purchase. ## Prepare an Accessible Excel Data Workbook https://whatisada.com/workflows/excel-accessible-data Organize a workbook so a reader can identify sheets, locate tables and interpret values without relying on color or visual position. ## Prepare Evaluation Evidence for an ACR https://whatisada.com/workflows/prepare-acr-evidence Organize evidence before completing an Accessibility Conformance Report. ## Prioritize Accessibility Issues by User Impact https://whatisada.com/workflows/accessibility-severity-triage Triage findings using a documented impact model and the importance of the affected task. ## Privacy Policy https://whatisada.com/legal/privacy-policy Privacy policy for whatisADA.com — how we collect, use, and protect your personal information. ## Remediation https://whatisada.com/glossary/remediation The process of identifying and fixing accessibility barriers in digital content, websites, or applications to bring them into compliance with WCAG and legal requirements. ## Repair Heading Structure in Word https://whatisada.com/workflows/word-heading-structure Make the document's visible sections available as a navigable heading hierarchy. ## Retest an Accessibility Repair https://whatisada.com/workflows/accessibility-fix-retesting Verify a repair against the original reproduction steps and the surrounding user process. ## Review a Marketing or Service Email for Accessibility https://whatisada.com/workflows/accessible-email-review Test the actual sent email in representative clients, including its text, links, images and reading order. ## Review a Site in Forced Colors Mode https://whatisada.com/workflows/forced-colors-review Inspect a site with an operating system contrast theme or a documented forced-colors test setup. ## Review a Webflow Form Before Launch https://whatisada.com/workflows/webflow-form-accessibility-review Check the published Webflow form with its real labels, styles and success and error states. ## Review a Website with VoiceOver and Safari https://whatisada.com/workflows/voiceover-safari-first-pass Use VoiceOver on macOS with Safari to review page structure, control names and a short task. ## Review Accessibility Responsibilities for a Third-Party Service https://whatisada.com/workflows/third-party-accessibility-handoff Map who can repair each part of an integrated service and how defects will be escalated. ## Review an Android Website with TalkBack https://whatisada.com/workflows/talkback-android Use TalkBack on an Android device to test names, reading order and actions on a mobile web page. ## Review Caption Accuracy and Timing https://whatisada.com/workflows/caption-quality-review Watch a complete representative media item with its captions enabled and compare the captions with the audio. ## Review Conditional Questions in a Form https://whatisada.com/workflows/conditional-form-fields Test each answer that reveals or removes dependent fields. ## Review Data Table Structure in Word https://whatisada.com/workflows/word-data-tables Inspect tables as relationships between headers and values rather than as visual grids. ## Review Data Tables with NVDA https://whatisada.com/workflows/nvda-tables Evaluate whether someone can understand a data value together with its row and column context. ## Review Links and Bookmarks in a PDF https://whatisada.com/workflows/pdf-links-bookmarks Check the document's navigation as a reader would use it: identifying a destination, activating it and understanding the arrival point. ## Review OCR Before Remediating a Scanned PDF https://whatisada.com/workflows/scanned-pdf-ocr Convert an image-only document into accurate machine-readable text before building its accessible structure. ## Review PowerPoint Slide Reading Order https://whatisada.com/workflows/powerpoint-reading-order Check the sequence in which slide objects are presented to a screen reader. ## Review Sequential Navigation with Switch Control https://whatisada.com/workflows/switch-input-navigation Evaluate whether the essential task can be completed using a switch access system's sequential selection. ## Review Shopify Product Media Accessibility https://whatisada.com/workflows/shopify-product-media-review Inspect the product gallery as a shopping task, including alternatives, controls and media behavior. ## Review Social Images, Captions and Link Context https://whatisada.com/workflows/accessible-social-post-review Prepare social content so its message remains available beyond the visual asset. ## Review Squarespace Content and Layout Accessibility https://whatisada.com/workflows/squarespace-content-accessibility-review Review the site's published content structure and responsive layout after editing in Squarespace. ## Review WordPress Image Alt Text in Context https://whatisada.com/workflows/wordpress-image-alt-text Review image alternatives on the rendered WordPress page, not only in the media library. ## Run a First NVDA Website Review https://whatisada.com/workflows/nvda-first-pass Use NVDA on Windows to inspect the structure and basic interaction of a representative page. ## Run a Keyboard-Only End-to-End Test https://whatisada.com/workflows/keyboard-only-full-flow Review one complete process without a mouse, from entry to confirmation. ## Screen Reader https://whatisada.com/glossary/screen-reader A screen reader is assistive technology software that converts on-screen text, images, and interface elements into synthesized speech or braille output, enabling people who are blind or visually impaired to use computers and navigate websites. ## Section 504 of the Rehabilitation Act https://whatisada.com/laws/section-504 Section 504 was the first federal civil rights law to protect people with disabilities. It prohibits discrimination on the basis of disability in any program or activity that receives federal financial assistance. This broad reach covers public schools, universities, hospitals, social service agencies, and any other organization that receives federal funds, making it a foundational law for disability rights. ## Section 508 https://whatisada.com/glossary/section-508 Section 508 is a provision of the Rehabilitation Act of 1973 that requires federal agencies to make their electronic and information technology accessible to people with disabilities, including federal websites, software, documents, and digital services. ## Section 508 of the Rehabilitation Act https://whatisada.com/laws/section-508 Section 508 requires federal agencies to ensure that their electronic and information technology (ICT) is accessible to people with disabilities, both employees and members of the public. The 2017 refresh aligned Section 508 standards with WCAG 2.0 Level AA, establishing a concrete technical benchmark for federal digital accessibility. ## Section 508 vs ADA: The Definitive Comparison (2026) https://whatisada.com/section-508-vs-ada Compare federal ICT requirements under Section 508 with ADA Titles II and III. Understand funding, procurement, technical standards and overlapping obligations. ## Select a Representative Accessibility Audit Sample https://whatisada.com/workflows/accessibility-audit-sampling Choose pages and states that cover the product's important structures and complete processes. ## Set and Verify PDF Language and Title https://whatisada.com/workflows/pdf-language-title Give a PDF a meaningful document title and the correct primary language, then review language changes within its content. ## Shopify ADA Compliance: Test the Complete Purchase Journey https://whatisada.com/platforms/shopify-ada-compliance Check your Shopify theme, product options, apps, cart, and checkout. Use this practical audit scope to assign fixes and retest the customer journey. ## State Website Accessibility Laws (2026): Unruh, NYCHRL, Illinois HRA, Florida https://whatisada.com/laws/state-laws Beyond the ADA: state laws that drive web accessibility lawsuits. California's Unruh Act ($4,000 per violation), NY's NYCHRL, Illinois's 746% surge, Florida. 2025 federal filings by state. ## Switch Access https://whatisada.com/glossary/switch-access An assistive technology method that allows people with severe motor disabilities to operate computers and mobile devices using one or more switches instead of a keyboard or touchscreen. ## Target Size Explorer https://whatisada.com/tools/target-size-checker Explore target dimensions against WCAG size thresholds, with spacing and exception limits explained. ## Terms of Service https://whatisada.com/legal/terms-of-service Terms of service for whatisADA.com — the rules and guidelines for using our website and educational resources. ## Test a Form's Error Recovery Path https://whatisada.com/workflows/form-error-recovery Evaluate the process from an invalid submission to a successful correction. ## Test a Mobile Web Journey with iOS VoiceOver https://whatisada.com/workflows/voiceover-ios-mobile Test the actual mobile page with VoiceOver on an iPhone or iPad. ## Test Checkout Announcements with JAWS https://whatisada.com/workflows/jaws-checkout Review a checkout using JAWS in a documented Windows and browser configuration. ## Test Fillable PDF Form Fields https://whatisada.com/workflows/pdf-form-fields Review a fillable PDF through instructions, field entry, validation and saving. ## Test Focus After Client-Side Navigation https://whatisada.com/workflows/route-change-focus Review what happens when a single-page application changes its main view without a full browser load. ## Test Form Labels and Errors with NVDA https://whatisada.com/workflows/nvda-forms Review a form in NVDA from initial instructions through error recovery. ## Test Page Reflow at 400 Percent Zoom https://whatisada.com/workflows/reflow-400-percent Check a vertically scrolling page at a width equivalent to 320 CSS pixels. ## Test Reduced Motion Preferences https://whatisada.com/workflows/reduced-motion-review Review how a site responds to a user's reduced-motion preference. ## Test Session Warnings and Extensions https://whatisada.com/workflows/session-timeout-review Review a time-limited process using a documented test account and a controlled timeout. ## Test Shopify Cart and Checkout Accessibility https://whatisada.com/workflows/shopify-checkout-accessibility-test Review the actual cart and checkout configuration as a complete purchase process. ## Test Text Resizing to 200 Percent https://whatisada.com/workflows/text-resize-200-percent Review whether text can be enlarged to twice its original size without losing content or functionality. ## Test Visible Labels with Speech Input https://whatisada.com/workflows/speech-input-controls Check whether a person using speech input can activate controls by saying the labels they see. ## Test WCAG Text Spacing Overrides https://whatisada.com/workflows/text-spacing-overrides Apply the specified line, paragraph, letter and word spacing simultaneously to check for lost content or functionality. ## Test WordPress Navigation Blocks and Menus https://whatisada.com/workflows/wordpress-navigation-review Review the rendered WordPress navigation at desktop and mobile widths. ## Texas Accessibility Standards https://whatisada.com/laws/texas-accessibility Texas has its own Accessibility Standards (TAS) for the built environment and Chapter 2054 of the Texas Government Code, which requires state agencies and institutions of higher education to comply with web accessibility standards. The Texas Department of Information Resources (DIR) oversees state agency technology accessibility, and Texas was one of the first states to establish specific web accessibility requirements for government websites. ## Text Alternative https://whatisada.com/glossary/text-alternative A text alternative is a textual description that serves as a substitute for non-text content such as images, videos, audio, and charts, making the information accessible to people who cannot perceive the original format. ## The 2026 WebAIM Million: Web Accessibility Just Got Worse for the First Time in Years https://whatisada.com/blog/webaim-million-2026-analysis The annual analysis of the top one million home pages found detectable WCAG failures on 95.9% of them — up from 94.8%, reversing years of slow progress. Here's what the data means for your site. ## The ADA Web Audit Process: What a Good Audit Looks Like (2026) https://whatisada.com/guides/ada-audit-process A practical breakdown of the ADA web audit process. Tooling, methodology, manual vs automated coverage, deliverables, and what to demand from any vendor proposing to audit your site. ## The Complete WCAG 2.2 Checklist https://whatisada.com/guides/wcag-2-2-checklist A plain-English checklist of all WCAG 2.2 Level A and AA success criteria organized by POUR principle. Understand every requirement for web accessibility. ## The European Accessibility Act Is Live: What U.S. Businesses Selling to Europe Must Do in 2026 https://whatisada.com/blog/european-accessibility-act-us-companies The EAA became enforceable on June 28, 2025 across all 27 EU member states — and it reaches U.S. companies that sell to European customers. Here is who is covered and what conformance requires. ## The Overlay Reckoning: One Year After the FTC's $1M accessiBe Fine https://whatisada.com/blog/overlay-reckoning-ftc-accessibe In April 2025 the FTC fined accessiBe $1 million for claiming its overlay made sites WCAG-compliant. A year on, the data is clear: accessibility widgets are a liability, not a shield. An opinion. ## The ROI of Web Accessibility: Why Compliance Pays for Itself https://whatisada.com/blog/roi-of-web-accessibility Beyond avoiding lawsuits, web accessibility delivers returns through expanded market reach, improved SEO, and better user experience for everyone. Here is the honest case, with sourced numbers. ## UPDATED: The April 2026 Title II Deadline Was Extended — New Dates Are April 2027 and 2028 https://whatisada.com/blog/april-2026-title-ii-deadline The DOJ's original April 24, 2026 ADA Title II web accessibility deadline was pushed back a year by an April 2026 Interim Final Rule. Here is what changed and what state and local governments must still do. ## Use Wix's Accessibility Wizard and Verify the Result https://whatisada.com/workflows/wix-accessibility-wizard-review Use the Wix Accessibility Wizard to identify supported issues, then complete its manual tasks and review the published site. ## Verify PDF Reading Order Across Columns https://whatisada.com/workflows/pdf-reading-order Check that meaningful content is read in an order that preserves the document's explanation. ## Voice Control https://whatisada.com/glossary/voice-control Assistive technology that allows users to operate computers and mobile devices using spoken commands, enabling people with motor disabilities to navigate, type, and interact without a keyboard or mouse. ## VPAT (Voluntary Product Accessibility Template) https://whatisada.com/glossary/vpat A VPAT (Voluntary Product Accessibility Template) is a standardized document that explains how a digital product or service conforms to accessibility standards, primarily used in government and enterprise procurement to evaluate whether technology meets Section 508 and WCAG requirements. ## VPAT and ACR Readiness Planner https://whatisada.com/tools/vpat-readiness Organize product identity, reporting requirements and evaluation evidence before preparing an ACR. ## WCAG (Web Content Accessibility Guidelines) https://whatisada.com/glossary/wcag WCAG (Web Content Accessibility Guidelines) is a set of internationally recognized technical standards published by the W3C that defines how to make web content more accessible to people with disabilities, organized around four principles: Perceivable, Operable, Understandable, and Robust. ## WCAG 1.1.1: Non-text Content https://whatisada.com/wcag/1-1-1-non-text-content Make the purpose or information in non-text content available through text. ## WCAG 1.2.1: Audio-only and Video-only (Prerecorded) https://whatisada.com/wcag/1-2-1-audio-only-and-video-only-prerecorded For prerecorded media with only audio or only video, provide the information in another usable form. ## WCAG 1.2.2: Captions (Prerecorded) https://whatisada.com/wcag/1-2-2-captions-prerecorded Prerecorded video with audio needs synchronized captions for spoken words and meaningful sounds. ## WCAG 1.2.3: Audio Description or Media Alternative (Prerecorded) https://whatisada.com/wcag/1-2-3-audio-description-or-media-alternative-prerecorded Prerecorded synchronized media must provide audio description or a full media alternative for important visual information that the soundtrack does not communicate. ## WCAG 1.2.4: Captions (Live) https://whatisada.com/wcag/1-2-4-captions-live Live synchronized media needs captions for the live audio. ## WCAG 1.2.5: Audio Description (Prerecorded) https://whatisada.com/wcag/1-2-5-audio-description-prerecorded Prerecorded video in synchronized media needs audio description for important visual information missing from the soundtrack. ## WCAG 1.2.6: Sign Language (Prerecorded) https://whatisada.com/wcag/1-2-6-sign-language-prerecorded At Level AAA, prerecorded synchronized media includes sign-language interpretation of its audio. ## WCAG 1.2.7: Extended Audio Description (Prerecorded) https://whatisada.com/wcag/1-2-7-extended-audio-description-prerecorded When normal pauses are too short for necessary audio description, Level AAA calls for extended description. ## WCAG 1.2.8: Media Alternative (Prerecorded) https://whatisada.com/wcag/1-2-8-media-alternative-prerecorded Level AAA requires a complete text media alternative for prerecorded synchronized media and prerecorded video-only content. ## WCAG 1.2.9: Audio-only (Live) https://whatisada.com/wcag/1-2-9-audio-only-live Live audio-only material needs an alternative presenting equivalent information at Level AAA. ## WCAG 1.3.1: Info and Relationships https://whatisada.com/wcag/1-3-1-info-and-relationships Structure and relationships conveyed visually must also be available programmatically or in text. ## WCAG 1.3.2: Meaningful Sequence https://whatisada.com/wcag/1-3-2-meaningful-sequence When the order of content affects meaning, the programmatically determined reading sequence must preserve that meaning. ## WCAG 1.3.3: Sensory Characteristics https://whatisada.com/wcag/1-3-3-sensory-characteristics Instructions must not depend only on shape, color, size, location, orientation or sound. ## WCAG 1.3.4: Orientation https://whatisada.com/wcag/1-3-4-orientation Content should work in both portrait and landscape unless a particular orientation is essential to its purpose. ## WCAG 1.3.5: Identify Input Purpose https://whatisada.com/wcag/1-3-5-identify-input-purpose For fields collecting information about the user, identify the expected purpose programmatically when it appears in WCAG's input-purpose list and the technology supports it. ## WCAG 1.3.6: Identify Purpose https://whatisada.com/wcag/1-3-6-identify-purpose At Level AAA, the purpose of interface components, icons and regions is programmatically identifiable in markup-based content. ## WCAG 1.4.1: Use of Color https://whatisada.com/wcag/1-4-1-use-of-color Color cannot be the sole visual cue for information or an action. ## WCAG 1.4.10: Reflow https://whatisada.com/wcag/1-4-10-reflow Content should reflow without loss or two-dimensional scrolling at a width equivalent to 320 CSS pixels, or a height equivalent to 256 CSS pixels for vertically written content, apart from content needing a two-dimensional layout. ## WCAG 1.4.11: Non-text Contrast https://whatisada.com/wcag/1-4-11-non-text-contrast Visual information needed to identify controls, their states and meaningful graphical objects generally needs 3:1 contrast against adjacent colors. ## WCAG 1.4.12: Text Spacing https://whatisada.com/wcag/1-4-12-text-spacing Users can increase specified text-spacing values without losing content or functionality in markup-based content that supports those properties. ## WCAG 1.4.13: Content on Hover or Focus https://whatisada.com/wcag/1-4-13-content-on-hover-or-focus Additional content triggered by hover or keyboard focus must satisfy the dismissible, hoverable and persistent conditions where they apply. ## WCAG 1.4.2: Audio Control https://whatisada.com/wcag/1-4-2-audio-control Audio that starts automatically and continues for more than three seconds needs a way to pause or stop it, or a volume control independent of the system volume. ## WCAG 1.4.3: Contrast (Minimum) https://whatisada.com/wcag/1-4-3-contrast-minimum Ordinary text needs a contrast ratio of at least 4.5:1 against its background; large text needs 3:1. ## WCAG 1.4.4: Resize Text https://whatisada.com/wcag/1-4-4-resize-text Text can be enlarged to 200 percent without losing content or functionality, apart from the specified exceptions for captions and images of text. ## WCAG 1.4.5: Images of Text https://whatisada.com/wcag/1-4-5-images-of-text Use real text when the technology can provide the intended presentation. ## WCAG 1.4.6: Contrast (Enhanced) https://whatisada.com/wcag/1-4-6-contrast-enhanced At Level AAA, ordinary text needs at least 7:1 contrast and large text needs at least 4.5:1, subject to the stated exceptions. ## WCAG 1.4.7: Low or No Background Audio https://whatisada.com/wcag/1-4-7-low-or-no-background-audio For prerecorded audio-only material that is primarily speech and falls within this criterion's scope, background sound must be absent, switchable off, or at least 20 decibels below the foreground speech, with limited exceptions. ## WCAG 1.4.8: Visual Presentation https://whatisada.com/wcag/1-4-8-visual-presentation At Level AAA, readers can control several aspects of text presentation: colors, line width, alignment, spacing and resizing behavior. ## WCAG 1.4.9: Images of Text (No Exception) https://whatisada.com/wcag/1-4-9-images-of-text-no-exception At Level AAA, use images of text only for pure decoration or when the particular presentation is essential. ## WCAG 2.0 https://whatisada.com/laws/wcag-2-0 WCAG 2.0 is the foundational web accessibility standard published by the W3C in December 2008. It provides 12 guidelines organized under four principles (Perceivable, Operable, Understandable, Robust) with three conformance levels (A, AA, AAA). WCAG 2.0 Level AA is incorporated into Section 508 and remains the baseline for most accessibility compliance programs worldwide. ## WCAG 2.1 https://whatisada.com/laws/wcag-2-1 WCAG 2.1 extends WCAG 2.0 with 17 new success criteria addressing mobile accessibility, low vision users, and people with cognitive and learning disabilities. Published in June 2018, WCAG 2.1 Level AA is the standard adopted by the DOJ's 2024 Title II web accessibility rule and is the current recommended benchmark for digital accessibility compliance. ## WCAG 2.1 Level AA: The 50 Success Criteria of ADA Compliance https://whatisada.com/requirements/wcag-2-1-aa A practical breakdown of WCAG 2.1 Level AA — 30 Level A + 20 Level AA success criteria — grouped by the POUR principles. The operative technical standard for ADA Title II and Title III. ## WCAG 2.1.1: Keyboard https://whatisada.com/wcag/2-1-1-keyboard Provide keyboard operation for all functionality, without requiring precisely timed individual keystrokes, except for functions whose underlying purpose depends on a movement path. ## WCAG 2.1.2: No Keyboard Trap https://whatisada.com/wcag/2-1-2-no-keyboard-trap People must be able to leave any component they can enter with a keyboard. ## WCAG 2.1.3: Keyboard (No Exception) https://whatisada.com/wcag/2-1-3-keyboard-no-exception At Level AAA, every function must have keyboard operation without precisely timed individual keystrokes. ## WCAG 2.1.4: Character Key Shortcuts https://whatisada.com/wcag/2-1-4-character-key-shortcuts Character-only shortcuts must be switchable off, remappable to include a non-printable key, or active only while the relevant component has focus. ## WCAG 2.2 https://whatisada.com/laws/wcag-2-2 WCAG 2.2 is the latest completed version of the Web Content Accessibility Guidelines, published in October 2023. It adds 9 new success criteria to WCAG 2.1, with a strong focus on cognitive accessibility, improved authentication methods, and consistent help mechanisms. WCAG 2.2 also removed one WCAG 2.0 criterion (4.1.1 Parsing) as obsolete. ## WCAG 2.2.1: Timing Adjustable https://whatisada.com/wcag/2-2-1-timing-adjustable For time limits imposed by content, let users turn them off, adjust them sufficiently or extend them under the criterion's conditions, unless a defined exception applies. ## WCAG 2.2.2: Pause, Stop, Hide https://whatisada.com/wcag/2-2-2-pause-stop-hide Give users control over qualifying automatic movement and updates. ## WCAG 2.2.3: No Timing https://whatisada.com/wcag/2-2-3-no-timing At Level AAA, activities do not make timing essential except for non-interactive synchronized media and real-time events. ## WCAG 2.2.4: Interruptions https://whatisada.com/wcag/2-2-4-interruptions At Level AAA, users can postpone or suppress interruptions except those involving an emergency. ## WCAG 2.2.5: Re-authenticating https://whatisada.com/wcag/2-2-5-re-authenticating At Level AAA, a user whose authenticated session expires can sign in again and continue without losing data. ## WCAG 2.2.6: Timeouts https://whatisada.com/wcag/2-2-6-timeouts At Level AAA, tell users how long inactivity can last before it causes data loss, unless the data is preserved for more than 20 hours without action. ## WCAG 2.3.1: Three Flashes or Below Threshold https://whatisada.com/wcag/2-3-1-three-flashes-or-below-threshold Avoid content that flashes more than three times in a one-second period unless it is below the defined general-flash and red-flash thresholds. ## WCAG 2.3.2: Three Flashes https://whatisada.com/wcag/2-3-2-three-flashes At Level AAA, nothing on the page flashes more than three times in any one-second period. ## WCAG 2.3.3: Animation from Interactions https://whatisada.com/wcag/2-3-3-animation-from-interactions At Level AAA, users can disable motion animation triggered by interaction unless that motion is essential. ## WCAG 2.4.1: Bypass Blocks https://whatisada.com/wcag/2-4-1-bypass-blocks Provide a way to bypass repeated blocks such as navigation. ## WCAG 2.4.10: Section Headings https://whatisada.com/wcag/2-4-10-section-headings At Level AAA, use section headings to organize written content. ## WCAG 2.4.11: Focus Not Obscured (Minimum) https://whatisada.com/wcag/2-4-11-focus-not-obscured-minimum When a component receives keyboard focus, author-created content must not hide it entirely. ## WCAG 2.4.12: Focus Not Obscured (Enhanced) https://whatisada.com/wcag/2-4-12-focus-not-obscured-enhanced At Level AAA, no part of a component receiving keyboard focus may be hidden by author-created content. ## WCAG 2.4.13: Focus Appearance https://whatisada.com/wcag/2-4-13-focus-appearance At Level AAA, a visible focus indicator needs an area at least equivalent to a two-CSS-pixel perimeter and a 3:1 change between the same pixels in focused and unfocused states, subject to stated browser-control exceptions. ## WCAG 2.4.2: Page Titled https://whatisada.com/wcag/2-4-2-page-titled Each page needs a title describing its topic or purpose. ## WCAG 2.4.3: Focus Order https://whatisada.com/wcag/2-4-3-focus-order Where navigation sequence affects meaning or operation, keyboard focus must follow a sequence that preserves both. ## WCAG 2.4.4: Link Purpose (In Context) https://whatisada.com/wcag/2-4-4-link-purpose-in-context A link's purpose must be understandable from its text or from text plus programmatically determined context, except where its purpose is ambiguous to everyone. ## WCAG 2.4.5: Multiple Ways https://whatisada.com/wcag/2-4-5-multiple-ways Within a set of pages, offer more than one way to locate a page unless it is a process step or result. ## WCAG 2.4.6: Headings and Labels https://whatisada.com/wcag/2-4-6-headings-and-labels Headings and labels should describe the topic or purpose of the content or control. ## WCAG 2.4.7: Focus Visible https://whatisada.com/wcag/2-4-7-focus-visible Keyboard users need a visible indicator showing which interactive element currently has focus. ## WCAG 2.4.8: Location https://whatisada.com/wcag/2-4-8-location At Level AAA, provide information showing where the user is within a set of pages. ## WCAG 2.4.9: Link Purpose (Link Only) https://whatisada.com/wcag/2-4-9-link-purpose-link-only At Level AAA, a mechanism lets users identify each link's purpose from link text alone, except where the purpose is generally ambiguous. ## WCAG 2.5.1: Pointer Gestures https://whatisada.com/wcag/2-5-1-pointer-gestures Functions using multipoint or path-based gestures need a single-pointer alternative that does not require a path, unless the gesture is essential. ## WCAG 2.5.2: Pointer Cancellation https://whatisada.com/wcag/2-5-2-pointer-cancellation Single-pointer actions should avoid committing a function on pointer-down, allow abort or undo around completion, reverse the down action on release, or meet an essential exception. ## WCAG 2.5.3: Label in Name https://whatisada.com/wcag/2-5-3-label-in-name When a control has a visible text label, its accessible name must contain that text. ## WCAG 2.5.4: Motion Actuation https://whatisada.com/wcag/2-5-4-motion-actuation Functions triggered by device or user motion need an interface-control alternative, and the motion response can be disabled unless a defined exception applies. ## WCAG 2.5.5: Target Size (Enhanced) https://whatisada.com/wcag/2-5-5-target-size-enhanced At Level AAA, pointer targets are generally at least 44 by 44 CSS pixels, with specified exceptions for equivalent controls, inline targets, unmodified browser controls and essential presentation. ## WCAG 2.5.6: Concurrent Input Mechanisms https://whatisada.com/wcag/2-5-6-concurrent-input-mechanisms At Level AAA, content does not unnecessarily restrict input methods available on the platform. ## WCAG 2.5.7: Dragging Movements https://whatisada.com/wcag/2-5-7-dragging-movements Functions requiring a dragging movement need a single-pointer alternative without dragging, unless dragging is essential or the behavior is an unmodified browser function. ## WCAG 2.5.8: Target Size (Minimum) https://whatisada.com/wcag/2-5-8-target-size-minimum At Level AA, pointer targets are generally at least 24 by 24 CSS pixels or satisfy a defined exception. ## WCAG 3.0 (Draft) https://whatisada.com/laws/wcag-3-0 WCAG 3.0 is a major in-progress overhaul of the Web Content Accessibility Guidelines that reimagines how accessibility is measured and reported. It introduces a new scoring model, expands scope beyond web content to all digital content and applications, and uses plain language outcomes instead of technical success criteria. WCAG 3.0 is still in Working Draft status and is not expected to become a W3C Recommendation for several more years. ## WCAG 3.1.1: Language of Page https://whatisada.com/wcag/3-1-1-language-of-page The default human language of a page must be available programmatically. ## WCAG 3.1.2: Language of Parts https://whatisada.com/wcag/3-1-2-language-of-parts Identify the language of passages or phrases that differ from the page's default, except for defined cases such as proper names, technical terms and words adopted into surrounding usage. ## WCAG 3.1.3: Unusual Words https://whatisada.com/wcag/3-1-3-unusual-words At Level AAA, provide a way to identify specific meanings of unusual or restricted words, including jargon and idioms. ## WCAG 3.1.4: Abbreviations https://whatisada.com/wcag/3-1-4-abbreviations At Level AAA, users can identify the expansion or meaning of abbreviations. ## WCAG 3.1.5: Reading Level https://whatisada.com/wcag/3-1-5-reading-level At Level AAA, material requiring reading ability above lower-secondary education needs supplemental content or a simpler version, after excluding proper names and titles from that assessment. ## WCAG 3.1.6: Pronunciation https://whatisada.com/wcag/3-1-6-pronunciation At Level AAA, provide a way to identify pronunciation when a word's meaning in context depends on how it is spoken and would otherwise be ambiguous. ## WCAG 3.2.1: On Focus https://whatisada.com/wcag/3-2-1-on-focus Receiving focus must not itself trigger a change of context. ## WCAG 3.2.2: On Input https://whatisada.com/wcag/3-2-2-on-input Changing a control's setting must not unexpectedly change context unless the user was told beforehand. ## WCAG 3.2.3: Consistent Navigation https://whatisada.com/wcag/3-2-3-consistent-navigation Navigation repeated across a set of pages must keep the same relative order unless the user initiates a change. ## WCAG 3.2.4: Consistent Identification https://whatisada.com/wcag/3-2-4-consistent-identification Components with the same functionality in a page set should be identified consistently. ## WCAG 3.2.5: Change on Request https://whatisada.com/wcag/3-2-5-change-on-request At Level AAA, context changes happen only at the user's request, or a mechanism allows the changes to be turned off. ## WCAG 3.2.6: Consistent Help https://whatisada.com/wcag/3-2-6-consistent-help When specified help mechanisms repeat across a set of pages, keep their order relative to other content consistent unless the user changes it. ## WCAG 3.3.1: Error Identification https://whatisada.com/wcag/3-3-1-error-identification When an input error is detected automatically, identify the field and describe the error in text. ## WCAG 3.3.2: Labels or Instructions https://whatisada.com/wcag/3-3-2-labels-or-instructions Provide labels or instructions when users must enter information. ## WCAG 3.3.3: Error Suggestion https://whatisada.com/wcag/3-3-3-error-suggestion When automatically detected input errors have known corrections, suggest how to fix them unless doing so would compromise security or the content's purpose. ## WCAG 3.3.4: Error Prevention (Legal, Financial, Data) https://whatisada.com/wcag/3-3-4-error-prevention-legal-financial-data For specified consequential submissions, provide a reversible action, error checking with a chance to correct, or review/confirmation with correction before finalizing. ## WCAG 3.3.5: Help https://whatisada.com/wcag/3-3-5-help At Level AAA, context-sensitive help is available. ## WCAG 3.3.6: Error Prevention (All) https://whatisada.com/wcag/3-3-6-error-prevention-all At Level AAA, all pages requiring information submission provide reversal, checking with correction, or review/confirmation with correction. ## WCAG 3.3.7: Redundant Entry https://whatisada.com/wcag/3-3-7-redundant-entry Within the same process, information already entered by or provided to the user and required again should be auto-filled or selectable, unless re-entry is essential, security-related or the prior information is no longer valid. ## WCAG 3.3.8: Accessible Authentication (Minimum) https://whatisada.com/wcag/3-3-8-accessible-authentication-minimum Authentication steps should not require an unassisted cognitive test unless a defined exception applies. ## WCAG 3.3.9: Accessible Authentication (Enhanced) https://whatisada.com/wcag/3-3-9-accessible-authentication-enhanced At Level AAA, authentication cannot require a cognitive test unless an alternative avoids it or a mechanism assists the user. ## WCAG 4.1.1: Parsing (legacy) https://whatisada.com/wcag/4-1-1-parsing Parsing was removed from WCAG 2.2. ## WCAG 4.1.2: Name, Role, Value https://whatisada.com/wcag/4-1-2-name-role-value User-interface components need programmatically determinable names and roles, and their user-settable states, properties and values must be available to software. ## WCAG 4.1.3: Status Messages https://whatisada.com/wcag/4-1-3-status-messages In markup-based content, status messages must have roles or properties that allow assistive technology to announce them without moving focus. ## WCAG and ADA: How a W3C Spec Became U.S. Law (2026) https://whatisada.com/wcag-and-ada WCAG is a W3C technical specification. The ADA is a U.S. civil rights statute. Here is exactly how WCAG 2.1 Level AA became the legal benchmark courts and the DOJ apply for ADA web accessibility. ## WCAG criterion reference https://whatisada.com/wcag All 86 active WCAG 2.2 criteria and the legacy Parsing reference. ## WCAG Quick Reference https://whatisada.com/tools/wcag-quick-reference Search criteria by version, principle and level, then open examples and testing worksheets. ## Web Accessibility https://whatisada.com/glossary/web-accessibility Web accessibility is the practice of designing and developing websites, tools, and technologies so that people with disabilities can perceive, understand, navigate, interact with, and contribute to the web equally and independently. ## Web Accessibility & the ADA: How They Relate (2026) https://whatisada.com/web-accessibility-and-ada Web accessibility is the practice of building sites everyone can use; the ADA is the U.S. law that makes much of it mandatory. Here is exactly how the two fit together — and what to build. ## Webflow ADA Compliance: A Practical Site Audit Guide https://whatisada.com/platforms/webflow-ada-compliance Plan a Webflow accessibility review covering CMS content, shared components, forms, menus, motion, and embeds, with clear ownership and retesting. ## Weekly Accessibility Digest — Free Newsletter https://whatisada.com/newsletter Stay current on ADA compliance, web accessibility, and WCAG standards. One weekly email covering lawsuits, deadlines, and practical fixes — no spam. ## What are the most common accessibility failures? https://whatisada.com/faq/what-are-the-most-common-accessibility-failures Per WebAIM Million 2026, six failure types account for 96% of detected errors: low contrast text (83.9% of home pages), missing alt text (53.1%), missing f ## What industries get sued most often for ADA website violations? https://whatisada.com/faq/what-industries-get-sued-most-for-ada-violations E-commerce and retail dominate: EcomBack put them at roughly 69% of 2025 digital accessibility lawsuits, followed by food and beverage at about 21%. Entert ## What is a demand letter and what should I do if I receive one? https://whatisada.com/faq/what-is-a-demand-letter An ADA demand letter is a formal pre-litigation notice, usually from a plaintiff's attorney, describing specific accessibility barriers on your website and ## What is a VPAT and do I need one? https://whatisada.com/faq/what-is-a-vpat-and-do-i-need-one A VPAT (Voluntary Product Accessibility Template) is a standardized document, created by the Information Technology Industry Council, that vendors use to r ## What Is a VPAT? Accessibility Conformance Reports Explained https://whatisada.com/guides/vpat-guide A practical guide to VPATs (Voluntary Product Accessibility Templates) and Accessibility Conformance Reports: the four editions, how conformance levels are scored, who requests them, and why a vendor-completed VPAT is not proof of an independent accessibility audit. ## What is ADA compliance for a website? https://whatisada.com/faq/what-is-ada-compliance-for-a-website ADA compliance for a website means the site is accessible to people with disabilities under the Americans with Disabilities Act. Courts and the DOJ apply W ## What Is ADA Compliance? The Complete Guide https://whatisada.com/guides/what-is-ada-compliance Learn what ADA compliance means for websites, apps, and digital content. Covers legal requirements, WCAG standards, and practical steps to become compliant. ## What is an accessibility overlay and why do experts warn against them? https://whatisada.com/faq/why-do-experts-warn-against-accessibility-overlays An accessibility overlay is a third-party JavaScript widget that scans a page after it loads and tries to auto-inject fixes — like alt text or ARIA labels ## What is the difference between Section 508 and the ADA? https://whatisada.com/faq/difference-between-section-508-and-ada Section 508 applies to federal agencies, contractors, and federal funding recipients — technical standard WCAG 2.0 AA. The ADA covers state/local governmen ## What is the difference between WCAG 2.0, 2.1, and 2.2? https://whatisada.com/faq/difference-between-wcag-2-0-2-1-and-2-2 WCAG 2.0 (2008) established 61 success criteria under the four POUR principles and is still the version Section 508 references. WCAG 2.1 (2018) added 17 mo ## What is WCAG 2.1 Level AA? https://whatisada.com/faq/what-is-wcag-2-1-level-aa WCAG 2.1 Level AA is the W3C Web Content Accessibility Guidelines at the AA conformance level — 50 success criteria (30 Level A + 20 Level AA) across the f ## What Is WCAG? Web Content Accessibility Guidelines Explained https://whatisada.com/guides/what-is-wcag Learn what WCAG is, how the Web Content Accessibility Guidelines work, the POUR principles, conformance levels A through AAA, and how WCAG relates to ADA law. ## What states have the most ADA website lawsuits? https://whatisada.com/faq/what-states-have-the-most-ada-website-lawsuits In 2025 federal data: New York (1,021), Florida (961), Illinois (585), Minnesota (162), Pennsylvania (137). California has the most state-court filings und ## When is the new ADA Title II web compliance deadline? https://whatisada.com/faq/when-is-the-new-ada-title-ii-web-compliance-deadline Per the DOJ's April 20, 2026 IFR (91 Fed. Reg. 20902): April 26, 2027 for state/local government serving 50,000+ population, and April 26, 2028 for smaller ## Why Accessibility Overlay Widgets Don't Work — and Why the FTC Fined accessiBe $1M https://whatisada.com/guides/overlay-widgets-warning The FTC fined accessiBe $1 million in April 2025 for falsely claiming its overlay made sites WCAG-compliant. 22.64% of sued sites had an overlay installed. Here is why overlays fail and what to do instead. ## Why did the DOJ extend the deadlines? https://whatisada.com/faq/why-did-the-doj-extend-the-deadlines DOJ stated it "overestimated the capabilities (whether staffing or technology) of covered entities" to comply in the original time frames. Public comment r ## Why E-commerce Sites Are the #1 ADA Lawsuit Target — and How to Get Off the List https://whatisada.com/blog/ecommerce-ada-compliance-lawsuit-target E-commerce accounts for roughly 69% of digital accessibility lawsuits. Here is exactly why online stores are so exposed, the barriers plaintiffs find first, and the fix order that protects both compliance and conversions. ## Write a Reproducible Accessibility Issue https://whatisada.com/workflows/write-accessibility-issue Turn an observation into a repairable issue with a clear trigger, user impact and expected behavior. ## Write an Evidence-Based Accessibility Statement https://whatisada.com/workflows/write-accessibility-statement Publish a statement that helps visitors understand accessibility support, known limitations and how to report a problem. ## Write Clear Instructions for a Complex Form https://whatisada.com/workflows/plain-language-form-instructions Explain what people need to provide before they encounter an error. ## Write Useful Image Alternatives in Word https://whatisada.com/workflows/word-image-alternatives Review each image in its document context and decide whether it conveys information, performs a function or is decorative. ## You Got an ADA Demand Letter. Here's Exactly What to Do Next https://whatisada.com/blog/ada-demand-letter-response A calm, step-by-step playbook for the first 48 hours after an ADA website demand letter — what to do, what to avoid, and how to turn a scary letter into a manageable fix. # Implementation reference ## WCAG 1.1.1: Non-text Content https://whatisada.com/wcag/1-1-1-non-text-content Updated: 2026-09-11 Make the purpose or information in non-text content available through text. The right alternative depends on how the image is used: a product photograph, a linked icon and a decorative divider need different treatment. Example: A store shows a backpack from three angles. Describe the useful visual differences in each image. If a small cart icon sits inside a button already labeled “View cart,” hide the redundant icon from assistive technology. Checks: 1. List images, SVGs, icon buttons, charts and canvas content in the chosen page state. 2. Decide which information or action each conveys in this context, then inspect its accessible name or adjacent alternative. 3. Read the alternatives without seeing the images and complete the same task, including any chart interpretation. Limitations: An alt attribute existing is not proof that its wording is useful. Complex diagrams may need a short name plus a nearby detailed explanation; decorative images usually need an empty alternative. Sources: - W3C: Understanding 1.1.1 Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#non-text-content ## WCAG 1.2.1: Audio-only and Video-only (Prerecorded) https://whatisada.com/wcag/1-2-1-audio-only-and-video-only-prerecorded Updated: 2026-09-11 For prerecorded media with only audio or only video, provide the information in another usable form. Audio-only material needs an equivalent text alternative; silent video needs a text alternative or an audio track describing its visual information. Example: An audio interview includes two speakers and a door alarm relevant to the conversation. A useful transcript identifies the speakers and the alarm. A silent assembly demonstration can instead have a narrated version that explains each step. Checks: 1. Identify prerecorded audio-only and silent video assets, including embedded players. 2. Locate the linked alternative and compare it with the whole recording, including important sounds, actions and sequence. 3. Check that a visitor can find and use the alternative without first operating an inaccessible player. Limitations: A filename, episode summary or automatic transcript with uncorrected errors may omit essential information. Media clearly labeled as an alternative to existing text has a specific exception. Sources: - W3C: Understanding 1.2.1 Audio-only and Video-only (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/audio-only-and-video-only-prerecorded.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#audio-only-and-video-only-prerecorded ## WCAG 1.2.2: Captions (Prerecorded) https://whatisada.com/wcag/1-2-2-captions-prerecorded Updated: 2026-09-11 Prerecorded video with audio needs synchronized captions for spoken words and meaningful sounds. Captions let someone follow the soundtrack while watching the related visual action. Example: A safety demonstration says “release the latch” while a warning beep sounds. Captions identify the instruction and beep at the correct moment; a transcript below the player helps separately but does not synchronize with the demonstration. Checks: 1. Play the complete video with captions enabled and sound muted. 2. Compare a second playback with sound, checking names, numbers, speaker changes and meaningful audio cues. 3. Check timing and caption placement where slides, faces or demonstrations would otherwise be covered. Limitations: Machine-generated captions need review. A caption button can be present even when no usable track is loaded. The criterion has an exception for clearly labeled media alternatives to text. Sources: - W3C: Understanding 1.2.2 Captions (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#captions-prerecorded ## WCAG 1.2.3: Audio Description or Media Alternative (Prerecorded) https://whatisada.com/wcag/1-2-3-audio-description-or-media-alternative-prerecorded Updated: 2026-09-11 Prerecorded synchronized media must provide audio description or a full media alternative for important visual information that the soundtrack does not communicate. This Level A criterion allows either route. Example: A training video silently displays an error message before the presenter explains a fix. Add description identifying the message, or provide a sequential text alternative covering the visual and audio content together. Checks: 1. Listen to the recording without watching and list information you cannot obtain from the soundtrack. 2. Compare that list against the described version or complete media alternative. 3. Follow the same instructional steps using only the alternative, including any choices or interactive outcomes. Limitations: A dialogue transcript alone may omit the visuals. At Level AA, 1.2.5 also applies and generally requires audio description, so the text option here does not by itself satisfy the AA target. Sources: - W3C: Understanding 1.2.3 Audio Description or Media Alternative (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/audio-description-or-media-alternative-prerecorded.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#audio-description-or-media-alternative-prerecorded ## WCAG 1.2.4: Captions (Live) https://whatisada.com/wcag/1-2-4-captions-live Updated: 2026-09-11 Live synchronized media needs captions for the live audio. Plan caption production and delivery as part of the event workflow rather than treating a later transcript as equivalent access. Example: A live town-hall stream includes audience questions from microphones in the room. The caption feed must include those questions and identify changes of speaker, not only the prepared presentation. Checks: 1. Before the event, verify that the intended player exposes and displays the live caption feed. 2. During a rehearsal, compare speech, speaker changes and meaningful sounds against the captions. 3. Test the participant view on the devices used by the audience and check that captions do not cover essential content. Limitations: A recording captioned after the event does not supply live access. Accuracy and delay need operational monitoring; the presence of an automated caption service is only the start of that check. Sources: - W3C: Understanding 1.2.4 Captions (Live): https://www.w3.org/WAI/WCAG22/Understanding/captions-live.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#captions-live ## WCAG 1.2.5: Audio Description (Prerecorded) https://whatisada.com/wcag/1-2-5-audio-description-prerecorded Updated: 2026-09-11 Prerecorded video in synchronized media needs audio description for important visual information missing from the soundtrack. Integrating necessary description into the original narration can reduce the need for a separate track. Example: A software tutorial highlights a tab without naming it. Replace “click here” with “open the Billing tab,” and describe the resulting panel. Where visuals remain unexplained, add a described track or described version. Checks: 1. Identify visual events, on-screen text, gestures and scene changes that carry meaning. 2. Listen without the picture to determine which are already explained by the main audio. 3. Play the described version and verify that missing information is delivered at useful moments without obscuring essential dialogue. Limitations: Not every visual detail needs narration. Focus on equivalent understanding; a transcript by itself is not the audio-description solution required by this AA criterion. Sources: - W3C: Understanding 1.2.5 Audio Description (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/audio-description-prerecorded.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#audio-description-prerecorded ## WCAG 1.2.6: Sign Language (Prerecorded) https://whatisada.com/wcag/1-2-6-sign-language-prerecorded Updated: 2026-09-11 At Level AAA, prerecorded synchronized media includes sign-language interpretation of its audio. Interpretation is a distinct access route and should be planned with the intended language community. Example: An instructional video for a regional audience offers a version with an interpreter signing the spoken material. The interpreter remains large enough to see facial expression and hand movement throughout the lesson. Checks: 1. Confirm the target sign language with the intended audience and arrange competent interpretation. 2. Review the full interpreted version for coverage of dialogue, speaker changes and meaningful audio. 3. Check the actual player size and responsive layout so the signing remains visible and unobstructed. Limitations: Sign languages are not interchangeable, and signing is not simply word-for-word caption translation. Captions and audio description remain separate requirements at their respective levels. Sources: - W3C: Understanding 1.2.6 Sign Language (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/sign-language-prerecorded.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#sign-language-prerecorded ## WCAG 1.2.7: Extended Audio Description (Prerecorded) https://whatisada.com/wcag/1-2-7-extended-audio-description-prerecorded Updated: 2026-09-11 When normal pauses are too short for necessary audio description, Level AAA calls for extended description. This pauses the video to provide information before the visual sequence continues. Example: A fast laboratory demonstration changes equipment while the presenter speaks continuously. An extended described version pauses before the next step so the equipment position and measurement can be explained without competing with speech. Checks: 1. Mark visual information missing from the soundtrack and estimate where description would fit. 2. Check whether ordinary description can communicate it during available pauses. 3. Where it cannot, verify a usable extended version that pauses and resumes with the explanation aligned to the relevant scene. Limitations: Speeding narration until it becomes difficult to understand is not a useful substitute. This criterion applies where the pauses are insufficient; it does not require extending every video. Sources: - W3C: Understanding 1.2.7 Extended Audio Description (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/extended-audio-description-prerecorded.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#extended-audio-description-prerecorded ## WCAG 1.2.8: Media Alternative (Prerecorded) https://whatisada.com/wcag/1-2-8-media-alternative-prerecorded Updated: 2026-09-11 Level AAA requires a complete text media alternative for prerecorded synchronized media and prerecorded video-only content. The alternative follows the sequence and conveys relevant visual and auditory information. Example: A cooking lesson has spoken instructions, silent temperature labels and a timer sound. Its media alternative includes all three in order, allowing a reader to prepare the recipe without operating the recording. Checks: 1. Inventory the recording's speech, significant sounds, visible text and meaningful actions. 2. Compare the text alternative against the full timeline, including interactions that ask the viewer to respond. 3. Check that the alternative is easy to locate, uses real text and preserves the instructional order. Limitations: This is more than subtitles pasted below a player. A dialogue-only transcript can leave out the very information that makes the demonstration understandable. Sources: - W3C: Understanding 1.2.8 Media Alternative (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/media-alternative-prerecorded.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#media-alternative-prerecorded ## WCAG 1.2.9: Audio-only (Live) https://whatisada.com/wcag/1-2-9-audio-only-live Updated: 2026-09-11 Live audio-only material needs an alternative presenting equivalent information at Level AAA. A live text stream is one practical approach when the event does not contain a video component. Example: An audio-only public briefing publishes a synchronized text feed that identifies each speaker and includes important announcements. Readers can follow the briefing as it happens without relying on the sound. Checks: 1. Confirm that the event is live audio-only and identify the intended alternative delivery channel. 2. Run a rehearsal containing names, figures, questions and speaker changes. 3. Compare the audio and alternative for equivalent information and verify that listeners can find the alternative before the event begins. Limitations: A summary published later may support the archive but does not provide access to the live information. If the event includes synchronized video, evaluate the live-caption criterion too. Sources: - W3C: Understanding 1.2.9 Audio-only (Live): https://www.w3.org/WAI/WCAG22/Understanding/audio-only-live.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#audio-only-live ## WCAG 1.3.1: Info and Relationships https://whatisada.com/wcag/1-3-1-info-and-relationships Updated: 2026-09-11 Structure and relationships conveyed visually must also be available programmatically or in text. Headings, labels, lists and table headers should describe the relationships a reader sees. Example: A pricing table uses bold cells as column names but ordinary data cells in the markup. Replace those cells with headers and connect more complex header relationships so each price can be understood with its plan and billing period. Checks: 1. Identify visual headings, grouped controls, lists, tables and emphasized relationships. 2. Inspect the markup and accessibility tree for the corresponding semantics and associations. 3. Navigate by headings and read selected form controls and table cells with a screen reader, checking the announced context. Limitations: Making text bold does not create a heading. Conversely, adding ARIA to every container can make the structure harder to use. Prefer the native element that expresses the actual relationship. Sources: - W3C: Understanding 1.3.1 Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#info-and-relationships ## WCAG 1.3.2: Meaningful Sequence https://whatisada.com/wcag/1-3-2-meaningful-sequence Updated: 2026-09-11 When the order of content affects meaning, the programmatically determined reading sequence must preserve that meaning. A responsive layout can move items visually while leaving an unusable reading order. Example: An instruction card visually places “Step 2” after “Step 1,” but its DOM places the warning after the final step. Reorder the document so the warning is encountered before the dangerous action at every breakpoint. Checks: 1. Choose content whose sequence matters, such as instructions, conversations or multi-column forms. 2. Read it in DOM order or with a screen reader's continuous reading command. 3. Compare desktop and narrow layouts and verify that the sequence still communicates the intended relationships. Limitations: Not every difference between visual order and DOM order is a failure. Evaluate whether meaning changes, and separately test the keyboard focus sequence under 2.4.3. Sources: - W3C: Understanding 1.3.2 Meaningful Sequence: https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#meaningful-sequence ## WCAG 1.3.3: Sensory Characteristics https://whatisada.com/wcag/1-3-3-sensory-characteristics Updated: 2026-09-11 Instructions must not depend only on shape, color, size, location, orientation or sound. Name the control or action so the instruction remains understandable without the referenced sensory cue. Example: Instead of “press the green circle on the right,” a checkout says “Select Continue to payment.” The button can still be green and circular, but its visible name makes the instruction usable with speech or a screen reader. Checks: 1. Search task instructions for phrases such as above, right, round, green or after the beep. 2. Try following each instruction without seeing its visual arrangement or hearing its audio cue. 3. Add a name, text label or other non-sensory description wherever the cue alone identifies the action. Limitations: Sensory descriptions can supplement clear wording. This criterion does not prohibit useful visual references; it addresses instructions that become ambiguous when those references are unavailable. Sources: - W3C: Understanding 1.3.3 Sensory Characteristics: https://www.w3.org/WAI/WCAG22/Understanding/sensory-characteristics.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#sensory-characteristics ## WCAG 1.3.4: Orientation https://whatisada.com/wcag/1-3-4-orientation Updated: 2026-09-11 Content should work in both portrait and landscape unless a particular orientation is essential to its purpose. Users may have a device mounted in a fixed position and be unable to rotate it. Example: An appointment form displays a “rotate your phone” overlay in landscape. Remove the restriction and let its fields and actions reflow so a person using a wheelchair-mounted phone can finish the booking. Checks: 1. Open representative pages in portrait and landscape, including forms, dialogs and media controls. 2. Check for rotation messages, blocked controls, clipped content or application code that forces an orientation. 3. Document any claimed essential orientation and explain why the underlying function genuinely requires it. Limitations: A designer's preferred composition is not the same as essential orientation. Test the actual app or browser configuration rather than assuming a responsive screenshot proves both orientations work. Sources: - W3C: Understanding 1.3.4 Orientation: https://www.w3.org/WAI/WCAG22/Understanding/orientation.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#orientation ## WCAG 1.3.5: Identify Input Purpose https://whatisada.com/wcag/1-3-5-identify-input-purpose Updated: 2026-09-11 For fields collecting information about the user, identify the expected purpose programmatically when it appears in WCAG's input-purpose list and the technology supports it. HTML autocomplete tokens are a common implementation. Example: A checkout labels a field “Street address” and uses autocomplete="street-address". A second section uses shipping or billing tokens to distinguish addresses instead of treating every text field as a generic input. Checks: 1. Inventory fields asking for the user's name, address, contact or payment information. 2. Match eligible fields to the standard input-purpose tokens and inspect their autocomplete values. 3. Check that token combinations accurately describe the field, including shipping or billing context where needed. Limitations: A correct visible label does not replace machine-readable purpose. The requirement is limited to eligible user-information purposes; do not invent autocomplete values for unrelated search or administrative fields. Sources: - W3C: Understanding 1.3.5 Identify Input Purpose: https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#identify-input-purpose ## WCAG 1.3.6: Identify Purpose https://whatisada.com/wcag/1-3-6-identify-purpose Updated: 2026-09-11 At Level AAA, the purpose of interface components, icons and regions is programmatically identifiable in markup-based content. This supports adaptations that help people recognize and navigate familiar functions. Example: A support page exposes its main content and navigation as landmarks, uses a real search region, and gives an icon-only print button an identifiable purpose. A customization tool can then work with meaningful components rather than anonymous containers. Checks: 1. List page regions, interface controls and meaningful icons. 2. Inspect available semantics and supported purpose annotations for each item. 3. Check that the exposed purpose agrees with the visible action and remains meaningful when decorative styling is removed. Limitations: Do not invent unsupported ARIA roles to imitate personalization. Use recognized semantics, consult the criterion's techniques, and keep accessible names and input-purpose requirements distinct. Sources: - W3C: Understanding 1.3.6 Identify Purpose: https://www.w3.org/WAI/WCAG22/Understanding/identify-purpose.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#identify-purpose ## WCAG 1.4.1: Use of Color https://whatisada.com/wcag/1-4-1-use-of-color Updated: 2026-09-11 Color cannot be the sole visual cue for information or an action. People who cannot distinguish the chosen colors still need to identify errors, links, categories and states. Example: A booking calendar marks unavailable dates in red. Add “Unavailable” text or a clearly explained symbol, and ensure the same state is exposed to assistive technology. A red border alone is not enough to explain a form error. Checks: 1. Identify every place color distinguishes a state, category, link or instruction. 2. View a grayscale rendering and check whether the distinction remains understandable. 3. Verify that added words, symbols or patterns communicate the same information and are present in the relevant accessible description. Limitations: Passing text contrast does not automatically solve color-only communication. Links and charts need their own review, including any criterion-specific techniques for distinguishing links from adjacent text. Sources: - W3C: Understanding 1.4.1 Use of Color: https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#use-of-color ## WCAG 1.4.2: Audio Control https://whatisada.com/wcag/1-4-2-audio-control Updated: 2026-09-11 Audio that starts automatically and continues for more than three seconds needs a way to pause or stop it, or a volume control independent of the system volume. Competing audio can prevent screen-reader users from finding that control. Example: A landing page starts a narrated welcome message. The simplest improvement is to wait for the visitor to press Play; if it starts automatically, a promptly available Stop control must work without searching through the page. Checks: 1. Load the page in a fresh state and observe any automatically started audio. 2. For audio longer than three seconds, locate and operate the stop, pause or independent-volume control. 3. Test the control with a keyboard while a screen reader is speaking, including how early it is reached. Limitations: Turning down system volume also turns down assistive speech and does not meet the independent-control option. Avoid auto-starting sound whenever possible. Sources: - W3C: Understanding 1.4.2 Audio Control: https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#audio-control ## WCAG 1.4.3: Contrast (Minimum) https://whatisada.com/wcag/1-4-3-contrast-minimum Updated: 2026-09-11 Ordinary text needs a contrast ratio of at least 4.5:1 against its background; large text needs 3:1. Large means at least 18 points, or 14 points when bold. Evaluate the rendered colors and applicable exceptions. Example: A 16-pixel checkout hint uses a pale gray that measures 3.2:1 against white. It needs a darker color for this AA text requirement even though a large heading could meet a lower threshold. Checks: 1. Inventory text styles and states, including placeholder text, hover content and validation messages. 2. Measure foreground against the actual background, accounting for transparency, gradients and images. 3. Compare the unrounded ratio with the applicable threshold and record the colors, size, weight and location. Limitations: Do not round 4.49 up to a pass. Logotypes, inactive controls and certain incidental text have exceptions, but branding ordinary body copy does not create a logo exception. Sources: - W3C: Understanding 1.4.3 Contrast (Minimum): https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#contrast-minimum ## WCAG 1.4.4: Resize Text https://whatisada.com/wcag/1-4-4-resize-text Updated: 2026-09-11 Text can be enlarged to 200 percent without losing content or functionality, apart from the specified exceptions for captions and images of text. The interface should accommodate enlarged labels and instructions. Example: At doubled text size, a fixed-height registration button clips “Create account.” Let the button grow and allow adjacent fields to move so the action and its label remain usable. Checks: 1. Set up a representative page with text, navigation and form controls at the normal size. 2. Increase text to 200 percent using a supported browser mechanism and inspect every important state. 3. Complete the task and check for clipped labels, hidden errors, overlapping controls or content that becomes unreachable. Limitations: A visually larger screenshot alone is insufficient. Verify operation at the enlarged size, and test reflow separately because resizing text and avoiding two-dimensional scrolling address different barriers. Sources: - W3C: Understanding 1.4.4 Resize Text: https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#resize-text ## WCAG 1.4.5: Images of Text https://whatisada.com/wcag/1-4-5-images-of-text Updated: 2026-09-11 Use real text when the technology can provide the intended presentation. Images of text are allowed where the presentation is essential or the user can customize it to their requirements. Example: A promotion stores its discount and expiry date inside a graphic. Rebuild those words as HTML over the background art so they can scale, change colors and be read without image interpretation. Checks: 1. Find promotional graphics, text banners and other images used mainly to display words. 2. Determine whether the same presentation can be achieved with real text and CSS. 3. For an exception, document the essential presentation or demonstrate the available text customization. Limitations: Alt text helps with non-text content but does not by itself resolve an avoidable image of text. Logos and screenshots that communicate more than their words need contextual evaluation. Sources: - W3C: Understanding 1.4.5 Images of Text: https://www.w3.org/WAI/WCAG22/Understanding/images-of-text.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#images-of-text ## WCAG 1.4.6: Contrast (Enhanced) https://whatisada.com/wcag/1-4-6-contrast-enhanced Updated: 2026-09-11 At Level AAA, ordinary text needs at least 7:1 contrast and large text needs at least 4.5:1, subject to the stated exceptions. These stronger thresholds support readers who need greater contrast. Example: An account balance passes AA at 5.1:1 but misses the enhanced target for ordinary text. Adjust the foreground or background until the unrounded measurement reaches 7:1 while preserving other visual states. Checks: 1. Identify the size and weight of each text style and whether an exception applies. 2. Measure the actual text/background pair for default, interactive and error states. 3. Record the exact ratios against the enhanced thresholds rather than reusing an AA-only report. Limitations: AAA contrast is not the same as dark mode, black-and-white styling or a high score from an automated scanner. Each applicable pair still needs measurement. Sources: - W3C: Understanding 1.4.6 Contrast (Enhanced): https://www.w3.org/WAI/WCAG22/Understanding/contrast-enhanced.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#contrast-enhanced ## WCAG 1.4.7: Low or No Background Audio https://whatisada.com/wcag/1-4-7-low-or-no-background-audio Updated: 2026-09-11 For prerecorded audio-only material that is primarily speech and falls within this criterion's scope, background sound must be absent, switchable off, or at least 20 decibels below the foreground speech, with limited exceptions. Example: A spoken onboarding lesson has music underneath the narration. Supply a speech-only version or mix the music sufficiently below the voice so listeners can understand it without separating two competing sound streams. Checks: 1. Confirm that the recording is mainly speech and review the criterion's exclusions. 2. Check for an accessible control or version that removes background sound. 3. If relying on the level difference, have the audio measured and document the speech and background levels across the recording. Limitations: A quiet-sounding mix to one reviewer is not a documented 20-decibel difference. Brief occasional sounds and excluded content require their own scope assessment. Sources: - W3C: Understanding 1.4.7 Low or No Background Audio: https://www.w3.org/WAI/WCAG22/Understanding/low-or-no-background-audio.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#low-or-no-background-audio ## WCAG 1.4.8: Visual Presentation https://whatisada.com/wcag/1-4-8-visual-presentation Updated: 2026-09-11 At Level AAA, readers can control several aspects of text presentation: colors, line width, alignment, spacing and resizing behavior. The aim is readable blocks of text that can adapt to individual needs. Example: A long policy page offers a reading view with user-selected colors, a narrow left-aligned column and generous spacing. Increasing text size does not force horizontal scrolling to read a line in a full-screen window. Checks: 1. Check mechanisms for selecting foreground/background colors and limiting lines to 80 characters or glyphs, or 40 for CJK. 2. Verify non-justified alignment, at least 1.5 line spacing and paragraph spacing at least 1.5 times line spacing. 3. Resize to 200 percent and review the criterion's horizontal-scrolling condition while using the available presentation settings. Limitations: This is a collection of presentation conditions, not merely a font-size control. Document the mechanism used to meet each condition, including any supported browser or reader customization. Sources: - W3C: Understanding 1.4.8 Visual Presentation: https://www.w3.org/WAI/WCAG22/Understanding/visual-presentation.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#visual-presentation ## WCAG 1.4.9: Images of Text (No Exception) https://whatisada.com/wcag/1-4-9-images-of-text-no-exception Updated: 2026-09-11 At Level AAA, use images of text only for pure decoration or when the particular presentation is essential. This is stricter than the AA criterion's allowance for user-customizable images of text. Example: A dashboard exports its instructions as an image even though their appearance is ordinary typography. Replace the instructions with HTML text. A wordmark can remain an image when its specific presentation is essential to the information. Checks: 1. Locate content whose primary purpose is to display words as pixels or outlines. 2. Distinguish decorative words and essential presentation from ordinary readable text. 3. Replace nonessential text images and verify that the resulting text supports selection, resizing and assistive reading. Limitations: A customization control that was relevant to 1.4.5 does not create an exception here. Evaluate this enhanced criterion separately when claiming AAA. Sources: - W3C: Understanding 1.4.9 Images of Text (No Exception): https://www.w3.org/WAI/WCAG22/Understanding/images-of-text-no-exception.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#images-of-text-no-exception ## WCAG 1.4.10: Reflow https://whatisada.com/wcag/1-4-10-reflow Updated: 2026-09-11 Content should reflow without loss or two-dimensional scrolling at a width equivalent to 320 CSS pixels, or a height equivalent to 256 CSS pixels for vertically written content, apart from content needing a two-dimensional layout. Example: A benefits application has a fixed-width two-column form. At a narrow effective viewport, stack the fields and keep the submit action in the reading flow. A genuinely two-dimensional data table can have its own scroll area. Checks: 1. Use a 320-CSS-pixel-wide viewport or the equivalent zoom setup for horizontally written pages. 2. Read and complete the whole page, including open navigation, dialogs and validation states. 3. Identify any horizontal scrolling and decide whether it comes from essential two-dimensional content or a repairable layout constraint. Limitations: An exception for a table does not exempt the entire page. Sticky headers, cookie notices and fixed toolbars can create losses of content even when the main text reflows. Sources: - W3C: Understanding 1.4.10 Reflow: https://www.w3.org/WAI/WCAG22/Understanding/reflow.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#reflow ## WCAG 1.4.11: Non-text Contrast https://whatisada.com/wcag/1-4-11-non-text-contrast Updated: 2026-09-11 Visual information needed to identify controls, their states and meaningful graphical objects generally needs 3:1 contrast against adjacent colors. Evaluate which parts actually convey the required information and any exceptions. Example: A checkbox has a border that disappears into the form background, and its checkmark is equally faint. Strengthen the necessary outline and selected-state indicator so both the control and its state remain identifiable. Checks: 1. List controls, focus/selection indicators, chart marks and informative icons. 2. Identify which visual boundaries or marks are needed to understand each component or graphic. 3. Measure each necessary part against adjacent colors and document any exception for inactive or unmodified browser controls. Limitations: Not every decorative border needs 3:1. A labeled solid button may be identifiable without its outline, but its essential state indicator still needs review. Text contrast is assessed separately. Sources: - W3C: Understanding 1.4.11 Non-text Contrast: https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#non-text-contrast ## WCAG 1.4.12: Text Spacing https://whatisada.com/wcag/1-4-12-text-spacing Updated: 2026-09-11 Users can increase specified text-spacing values without losing content or functionality in markup-based content that supports those properties. The criterion tests resilience to overrides, not whether those values are the default design. Example: A help card uses a fixed height that clips its final sentence after spacing increases. Allow the card to expand and keep its link available when word, letter, line and paragraph spacing are overridden together. Checks: 1. Apply line height of 1.5 times font size and paragraph spacing of 2 times font size. 2. At the same time, apply letter spacing of 0.12 times and word spacing of 0.16 times font size. 3. Review every visible state for clipping, overlap, hidden controls and lost information, including form errors and expanded panels. Limitations: Changing only line height does not exercise the full test. Language and script exceptions apply to unsupported spacing properties; record the actual settings used. Sources: - W3C: Understanding 1.4.12 Text Spacing: https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#text-spacing ## WCAG 1.4.13: Content on Hover or Focus https://whatisada.com/wcag/1-4-13-content-on-hover-or-focus Updated: 2026-09-11 Additional content triggered by hover or keyboard focus must satisfy the dismissible, hoverable and persistent conditions where they apply. Users need time and a stable way to inspect the revealed information. Example: A product tooltip appears above a help icon. It can be dismissed without moving focus, stays open when the pointer moves onto it, and remains available while it is being read instead of disappearing on a timer. Checks: 1. Trigger the additional content with both pointer hover and keyboard focus where supported. 2. Try dismissing it without moving the pointer or focus, and move the pointer onto the additional content. 3. Check that it persists until the trigger is removed, the user dismisses it or the information is no longer valid. Limitations: There are defined exceptions, including certain content controlled by the browser and dismissibility cases. Avoid treating every tooltip-like widget as automatically exempt. Sources: - W3C: Understanding 1.4.13 Content on Hover or Focus: https://www.w3.org/WAI/WCAG22/Understanding/content-on-hover-or-focus.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#content-on-hover-or-focus ## WCAG 2.1.1: Keyboard https://whatisada.com/wcag/2-1-1-keyboard Updated: 2026-09-11 Provide keyboard operation for all functionality, without requiring precisely timed individual keystrokes, except for functions whose underlying purpose depends on a movement path. Native HTML controls provide much of this behavior automatically. Example: A product gallery can be advanced by clicking thumbnails but not by keyboard. Use real buttons with clear names, then ensure selection and the enlarged image update when those buttons are activated. Checks: 1. Put the pointer aside and follow each important task using a keyboard. 2. Reach and operate controls, menus, dialogs, media players and custom widgets using their expected keys. 3. Compare the available keyboard actions with pointer actions and document any genuinely path-dependent function. Limitations: Adding tabindex makes something focusable but does not supply its role or activation behavior. A text-entry feature does not become exempt merely because its chosen interface uses handwriting. Sources: - W3C: Understanding 2.1.1 Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#keyboard ## WCAG 2.1.2: No Keyboard Trap https://whatisada.com/wcag/2-1-2-no-keyboard-trap Updated: 2026-09-11 People must be able to leave any component they can enter with a keyboard. If exiting needs an unusual method beyond standard keys or exit conventions, explain that method to the user. Example: An embedded editor captures Tab to indent code. Give the editor a documented keyboard exit method, or a mode that lets Tab leave, so users can still reach the controls following it. Checks: 1. Enter each custom component and embedded frame using only keyboard navigation. 2. Try forward and reverse navigation and any documented standard exit mechanism. 3. For dialogs, verify that an operable close action releases the contained focus and returns it to an appropriate location. Limitations: A modal can intentionally contain focus while open, provided keyboard users can close or otherwise exit it. An unexplained trap is an interference problem even if the component is not central to the page. Sources: - W3C: Understanding 2.1.2 No Keyboard Trap: https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#no-keyboard-trap ## WCAG 2.1.3: Keyboard (No Exception) https://whatisada.com/wcag/2-1-3-keyboard-no-exception Updated: 2026-09-11 At Level AAA, every function must have keyboard operation without precisely timed individual keystrokes. Unlike 2.1.1, this enhanced criterion does not allow the path-dependent function exception. Example: A drawing lesson offers pointer sketching and an alternative keyboard interface for constructing the required shapes. The team evaluates the complete drawing function rather than stopping after the toolbar buttons work. Checks: 1. Inventory all functions, including drawing surfaces, games and specialized interactions. 2. Identify keyboard actions that achieve each function without required keystroke timing. 3. Complete the same outcomes with the keyboard and record any function for which no equivalent operation exists. Limitations: Do not report an AA keyboard pass as evidence of this stricter AAA requirement. The missing path-dependent exception matters for products built around freehand movement. Sources: - W3C: Understanding 2.1.3 Keyboard (No Exception): https://www.w3.org/WAI/WCAG22/Understanding/keyboard-no-exception.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#keyboard-no-exception ## WCAG 2.1.4: Character Key Shortcuts https://whatisada.com/wcag/2-1-4-character-key-shortcuts Updated: 2026-09-11 Character-only shortcuts must be switchable off, remappable to include a non-printable key, or active only while the relevant component has focus. This includes character sequences and printable characters entered with Shift or AltGr. Example: A document viewer uses the letter D to delete a page anywhere on screen. Restrict the shortcut to the focused viewer, provide a setting to disable it, or require a modifier key that users can configure. Checks: 1. Find shortcuts based on printable characters, including sequences such as G then A and characters entered using Shift or AltGr. 2. Test whether they act outside the intended component or during dictation and text entry. 3. Verify a working off switch, supported remapping or focus-only activation for each affected shortcut. Limitations: A list of shortcuts does not solve accidental activation. Keep the settings reachable without relying on the very shortcut that a user needs to disable. Sources: - W3C: Understanding 2.1.4 Character Key Shortcuts: https://www.w3.org/WAI/WCAG22/Understanding/character-key-shortcuts.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#character-key-shortcuts ## WCAG 2.2.1: Timing Adjustable https://whatisada.com/wcag/2-2-1-timing-adjustable Updated: 2026-09-11 For time limits imposed by content, let users turn them off, adjust them sufficiently or extend them under the criterion's conditions, unless a defined exception applies. People need enough time to read, decide and enter information. Example: A benefits form warns before session expiry and offers a simple Extend session action. The warning allows at least 20 seconds to respond, and the session can be extended at least ten times when this option is used. Checks: 1. Inventory session, quiz, form and confirmation time limits controlled by the application. 2. Verify the selected route: off before encounter, adjustment to at least ten times the default, or compliant warning and repeated extension. 3. Test with the keyboard and check whether any real-time, essential or longer-than-20-hour exception is justified. Limitations: A warning that appears for five seconds is not enough for the extension route. Security requirements should be analyzed carefully rather than assumed to exempt every session timeout. Sources: - W3C: Understanding 2.2.1 Timing Adjustable: https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#timing-adjustable ## WCAG 2.2.2: Pause, Stop, Hide https://whatisada.com/wcag/2-2-2-pause-stop-hide Updated: 2026-09-11 Give users control over qualifying automatic movement and updates. Movement that starts automatically, lasts over five seconds and appears alongside other content generally needs pause, stop or hide; automatic updates have their own conditions. Example: A testimonial carousel changes slides while someone reads a signup form. Add a persistent pause control and keep it paused until the person chooses otherwise. A live results panel can also let users control update frequency. Checks: 1. Identify moving, blinking, scrolling and automatically refreshing information presented with other content. 2. Check the duration and trigger for movement, and the separate conditions for auto-updates. 3. Operate the pause, stop, hide or update-frequency control and verify that the page remains usable afterward. Limitations: Hover-only pausing is not sufficient for every user. Do not apply the five-second movement threshold to exempt auto-updating information; the criterion treats those cases separately. Sources: - W3C: Understanding 2.2.2 Pause, Stop, Hide: https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#pause-stop-hide ## WCAG 2.2.3: No Timing https://whatisada.com/wcag/2-2-3-no-timing Updated: 2026-09-11 At Level AAA, activities do not make timing essential except for non-interactive synchronized media and real-time events. This goes beyond offering extra time under the Level A timing criterion. Example: A training quiz scores learners on both correctness and a countdown. An untimed assessment route lets a learner demonstrate the same knowledge without speed being part of the task. Checks: 1. List activities that require a response, completion or decision within a period. 2. Determine whether timing is part of the activity and whether a listed exception applies. 3. Complete the activity using a route where timing is not essential, checking that the outcome remains available. Limitations: A generous countdown can still make timing essential. Evaluate this criterion separately from session-extension controls and document any real-time event exception. Sources: - W3C: Understanding 2.2.3 No Timing: https://www.w3.org/WAI/WCAG22/Understanding/no-timing.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#no-timing ## WCAG 2.2.4: Interruptions https://whatisada.com/wcag/2-2-4-interruptions Updated: 2026-09-11 At Level AAA, users can postpone or suppress interruptions except those involving an emergency. Reading and task completion should not be repeatedly displaced by nonessential messages. Example: A support chat prompt opens while a visitor fills a long form. Provide a preference that postpones the prompt or keeps it closed, while allowing the visitor to open help when wanted. Checks: 1. Inventory pop-ups, reminders, invitations and other interruptions during normal tasks. 2. Find and operate controls that suppress or postpone each nonemergency interruption. 3. Continue through the task long enough to verify that the interruption respects the chosen setting. Limitations: A marketing deadline does not make a message an emergency. Notifications should be designed so that disabling interruption does not remove a user's ability to find the information later. Sources: - W3C: Understanding 2.2.4 Interruptions: https://www.w3.org/WAI/WCAG22/Understanding/interruptions.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#interruptions ## WCAG 2.2.5: Re-authenticating https://whatisada.com/wcag/2-2-5-re-authenticating Updated: 2026-09-11 At Level AAA, a user whose authenticated session expires can sign in again and continue without losing data. Preserve the task state through the authentication transition in a way suitable for the information involved. Example: Someone drafts a grant application and returns after the session expires. After signing in again, the saved draft, selected options and current step are restored so the application can continue. Checks: 1. Enter representative information into a multi-step authenticated task. 2. Allow the session to expire and complete the normal re-authentication process. 3. Check the restored values, selected files where feasible, workflow position and pending actions for lost work or unintended submission. Limitations: A successful login redirect is not proof of state recovery. Sensitive drafts need an appropriate storage and retention design; do not solve data loss by exposing private information on a shared device. Sources: - W3C: Understanding 2.2.5 Re-authenticating: https://www.w3.org/WAI/WCAG22/Understanding/re-authenticating.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#re-authenticating ## WCAG 2.2.6: Timeouts https://whatisada.com/wcag/2-2-6-timeouts Updated: 2026-09-11 At Level AAA, tell users how long inactivity can last before it causes data loss, unless the data is preserved for more than 20 hours without action. The notice should help users plan before investing effort. Example: An application explains before data entry that an unsaved draft is cleared after 30 minutes of inactivity. A later warning and extension mechanism address other timing requirements but do not replace the initial duration information. Checks: 1. Identify inactivity limits that can discard user-entered information. 2. Locate a clear explanation of the duration before the user is at risk of losing work. 3. If relying on preservation, test and document storage beyond 20 hours with an appropriate privacy and security design. Limitations: “Your session may expire” does not communicate the duration. This AAA notice requirement is distinct from the Level A rules for adjusting or extending time limits. Sources: - W3C: Understanding 2.2.6 Timeouts: https://www.w3.org/WAI/WCAG22/Understanding/timeouts.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#timeouts ## WCAG 2.3.1: Three Flashes or Below Threshold https://whatisada.com/wcag/2-3-1-three-flashes-or-below-threshold Updated: 2026-09-11 Avoid content that flashes more than three times in a one-second period unless it is below the defined general-flash and red-flash thresholds. Evaluate video, animation and other rendered effects across the page. Example: A promotional animation rapidly alternates red frames. Replace the effect with a stable transition or have the actual asset assessed with an appropriate flash-analysis method before publication. Checks: 1. Inventory videos, GIFs, animations and interactive effects that may flash. 2. Use appropriate analysis of the actual rendered content rather than asking a photosensitive person to inspect it. 3. Remove unsafe effects or document the measured frequency and threshold assessment for any retained material. Limitations: Small-looking content and a pause button do not automatically make flashing safe. The threshold analysis includes more than frequency, and this criterion is part of WCAG's non-interference requirements. Sources: - W3C: Understanding 2.3.1 Three Flashes or Below Threshold: https://www.w3.org/WAI/WCAG22/Understanding/three-flashes-or-below-threshold.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#three-flashes-or-below-threshold ## WCAG 2.3.2: Three Flashes https://whatisada.com/wcag/2-3-2-three-flashes Updated: 2026-09-11 At Level AAA, nothing on the page flashes more than three times in any one-second period. This enhanced rule removes the general-flash and red-flash threshold alternative available at Level A. Example: A celebration effect creates a rapid flashing border after checkout. Replace it with a steady confirmation and a non-flashing visual change so the completion state does not introduce the effect. Checks: 1. Inventory all moving assets and state-change effects, including user-triggered celebrations. 2. Analyze the actual sequence for any one-second interval containing more than three flashes. 3. Remove or redesign any effect exceeding that frequency and retain the assessment with the asset record. Limitations: Do not reuse a Level A threshold exemption for an AAA claim. Avoid creating a flashing demonstration solely to test this requirement; use safe analysis methods. Sources: - W3C: Understanding 2.3.2 Three Flashes: https://www.w3.org/WAI/WCAG22/Understanding/three-flashes.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#three-flashes ## WCAG 2.3.3: Animation from Interactions https://whatisada.com/wcag/2-3-3-animation-from-interactions Updated: 2026-09-11 At Level AAA, users can disable motion animation triggered by interaction unless that motion is essential. Respecting reduced-motion preferences is a practical starting point for scroll, transition and parallax effects. Example: A card expands with a long zoom and sweeping background movement. When reduced motion is requested, show the expanded state directly while preserving the action and information. Checks: 1. Inventory motion caused by clicks, focus, scrolling, dragging and route changes. 2. Enable the supported reduced-motion setting or equivalent site control and repeat those interactions. 3. Verify that nonessential motion stops while state changes, orientation cues and required information remain understandable. Limitations: Removing only the initial page animation leaves interactive motion untested. A transition that communicates a state can often be replaced with an immediate state change rather than treated as essential. Sources: - W3C: Understanding 2.3.3 Animation from Interactions: https://www.w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#animation-from-interactions ## WCAG 2.4.1: Bypass Blocks https://whatisada.com/wcag/2-4-1-bypass-blocks Updated: 2026-09-11 Provide a way to bypass repeated blocks such as navigation. A keyboard or assistive-technology user should be able to reach the unique content without traversing the same links on every page. Example: An account area repeats 25 navigation links before each form. A first-focus skip link moves to the main content, and correctly named landmarks offer another route for screen-reader navigation. Checks: 1. Start keyboard navigation at the top of several pages sharing the same layout. 2. Find the bypass mechanism and activate it, then confirm the next interaction begins in the intended content. 3. Use landmark or heading navigation to verify the structure and avoid repeated regions being mistaken for the main content. Limitations: A skip link that only scrolls while leaving keyboard focus in the header can remain frustrating. Verify the actual focus and subsequent Tab behavior in supported browsers. Sources: - W3C: Understanding 2.4.1 Bypass Blocks: https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocks.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#bypass-blocks ## WCAG 2.4.2: Page Titled https://whatisada.com/wcag/2-4-2-page-titled Updated: 2026-09-11 Each page needs a title describing its topic or purpose. Titles help users distinguish browser tabs, history entries and screen-reader announcements when moving between pages. Example: Three application steps all use “Portal.” Give them distinct titles such as “Contact details – Permit application” and “Review – Permit application,” updating the title when the route changes. Checks: 1. Inspect the document title on each representative route and process step. 2. Compare the title with the visible page purpose and with titles on similar pages. 3. Navigate client-side and directly reload the destination to verify both paths produce the correct title. Limitations: The visible H1 does not automatically set the browser title. Unique wording is useful, but a unique identifier alone may still fail to describe the page's purpose. Sources: - W3C: Understanding 2.4.2 Page Titled: https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#page-titled ## WCAG 2.4.3: Focus Order https://whatisada.com/wcag/2-4-3-focus-order Updated: 2026-09-11 Where navigation sequence affects meaning or operation, keyboard focus must follow a sequence that preserves both. Test the flow through dynamic states as well as the initial page. Example: A checkout adds delivery options after a radio selection, but focus jumps to the footer. Keep the selected control in place and insert the new options in a logical reading and focus order. Checks: 1. Tab and Shift+Tab through the important task while noting the active element. 2. Open and close dialogs, reveal conditional fields and trigger errors or route changes. 3. Verify that focus stays in a useful place and that completing the next step does not require searching backward through unrelated controls. Limitations: Focus order need not duplicate every visual detail. Avoid positive tabindex values and judge whether the sequence makes the task understandable and operable. Sources: - W3C: Understanding 2.4.3 Focus Order: https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#focus-order ## WCAG 2.4.4: Link Purpose (In Context) https://whatisada.com/wcag/2-4-4-link-purpose-in-context Updated: 2026-09-11 A link's purpose must be understandable from its text or from text plus programmatically determined context, except where its purpose is ambiguous to everyone. Nearby visual layout alone may not provide that context. Example: An article list repeats “Read more.” Including the article title in each link is clear and robust; another supported approach associates the link with suitable context in the same meaningful structure. Checks: 1. Read each link with the context available programmatically, including relevant paragraph, list or table relationships. 2. Compare the resulting meaning with the actual destination or action. 3. Revise ambiguous links and inspect icon-only links, document downloads and repeated card actions. Limitations: A tooltip title is not a dependable substitute for useful link text. Do not assume any nearby heading supplies programmatic context simply because it appears close on screen. Sources: - W3C: Understanding 2.4.4 Link Purpose (In Context): https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#link-purpose-in-context ## WCAG 2.4.5: Multiple Ways https://whatisada.com/wcag/2-4-5-multiple-ways Updated: 2026-09-11 Within a set of pages, offer more than one way to locate a page unless it is a process step or result. Navigation, search, a sitemap and well-structured indexes can serve different discovery needs. Example: A documentation site has a topic navigation tree and a searchable index. Someone who does not know the product's internal category names can locate the same troubleshooting page by a familiar symptom. Checks: 1. Define the relevant set of pages and identify process-step exceptions. 2. Try finding selected pages through two available mechanisms. 3. Verify both mechanisms reach the intended live pages and remain available to keyboard and assistive-technology users. Limitations: Two links in the same menu are not necessarily two distinct ways to locate content. A search box that omits most pages or returns broken URLs is not a reliable alternative. Sources: - W3C: Understanding 2.4.5 Multiple Ways: https://www.w3.org/WAI/WCAG22/Understanding/multiple-ways.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#multiple-ways ## WCAG 2.4.6: Headings and Labels https://whatisada.com/wcag/2-4-6-headings-and-labels Updated: 2026-09-11 Headings and labels should describe the topic or purpose of the content or control. Useful wording reduces the need to inspect surrounding details before deciding where to navigate or what to enter. Example: A form has two fields labeled “Name,” one for the applicant and one for a dependent. Use labels such as “Applicant's full name” and “Dependent's full name” so their purpose is clear. Checks: 1. Read headings as an outline and labels without relying on disappearing input hints. 2. Check the wording against the content section or data actually requested. 3. Review repeated labels and generic headings in context, making distinctions clear where the task needs them. Limitations: This criterion concerns whether wording is descriptive. Correct heading elements and programmatic label association are related requirements, but technically associated text can still be unhelpful. Sources: - W3C: Understanding 2.4.6 Headings and Labels: https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#headings-and-labels ## WCAG 2.4.7: Focus Visible https://whatisada.com/wcag/2-4-7-focus-visible Updated: 2026-09-11 Keyboard users need a visible indicator showing which interactive element currently has focus. The page must have a mode of keyboard operation where that indicator can be seen. Example: A theme removes outlines from all buttons, leaving only a hover color. Add a visible focus style and test it on every button background, including dark cards and destructive actions. Checks: 1. Navigate with Tab and the expected keys for composite widgets. 2. Inspect every focused control across default, expanded, selected and error states. 3. Check that the indicator remains visible in the relevant themes and is not clipped by overflow containers. Limitations: A mouse hover style is not a keyboard focus indicator. WCAG 2.2 also adds criteria for obscuring focus and, at AAA, the indicator's measurable appearance. Sources: - W3C: Understanding 2.4.7 Focus Visible: https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#focus-visible ## WCAG 2.4.8: Location https://whatisada.com/wcag/2-4-8-location Updated: 2026-09-11 At Level AAA, provide information showing where the user is within a set of pages. Breadcrumbs, a marked current section or another understandable location indicator can support orientation. Example: A resource library displays “Resources → Forms → Error messages,” with the current page named in the breadcrumb. Its section navigation also identifies the current section without relying only on color. Checks: 1. Enter a deep page directly from a saved link or search result. 2. Find information identifying its place within the surrounding page set. 3. Follow the location links and confirm that their labels and hierarchy match the actual site structure. Limitations: A browser Back button describes navigation history, not necessarily the page's place in the site. Ensure that visually marked current states have an equivalent accessible indication. Sources: - W3C: Understanding 2.4.8 Location: https://www.w3.org/WAI/WCAG22/Understanding/location.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#location ## WCAG 2.4.9: Link Purpose (Link Only) https://whatisada.com/wcag/2-4-9-link-purpose-link-only Updated: 2026-09-11 At Level AAA, a mechanism lets users identify each link's purpose from link text alone, except where the purpose is generally ambiguous. This is stricter than relying on paragraph or table context. Example: A dashboard replaces repeated “Download” links with “Download March invoice” and “Download April invoice.” A screen reader's links list can then distinguish the files without reading each surrounding card. Checks: 1. List links without their surrounding paragraphs or headings. 2. Check whether the text available through the site's mechanism identifies each destination or action. 3. Verify that visible and accessible link names remain consistent and that repeated links with different destinations are distinguishable. Limitations: Do not confuse this enhanced criterion with 2.4.4, which permits certain programmatic context. Avoid excessively long names that repeat an entire card when a short specific label will do. Sources: - W3C: Understanding 2.4.9 Link Purpose (Link Only): https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-link-only.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#link-purpose-link-only ## WCAG 2.4.10: Section Headings https://whatisada.com/wcag/2-4-10-section-headings Updated: 2026-09-11 At Level AAA, use section headings to organize written content. Readers should be able to identify its structure and move to the part they need without reading every paragraph sequentially. Example: A long refund policy is divided into “Eligibility,” “Start a return,” “Shipping costs” and “Refund timing.” The headings follow the content's actual organization instead of being inserted at arbitrary intervals. Checks: 1. Identify longer written content and the sections that communicate distinct topics. 2. Check that appropriate headings introduce those sections and describe their contents. 3. Navigate the heading outline and verify that the organization helps locate specific information. Limitations: This requirement concerns sections in writing. It is distinct from adding labels to interface widgets and does not mean every short paragraph needs its own heading. Sources: - W3C: Understanding 2.4.10 Section Headings: https://www.w3.org/WAI/WCAG22/Understanding/section-headings.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#section-headings ## WCAG 2.4.11: Focus Not Obscured (Minimum) https://whatisada.com/wcag/2-4-11-focus-not-obscured-minimum Updated: 2026-09-11 When a component receives keyboard focus, author-created content must not hide it entirely. Sticky headers, banners and overlays can otherwise leave users unsure where keyboard input will act. Example: A sticky consent banner covers the final checkout button when it receives focus. Add enough scrolling clearance or adjust the banner layout so at least part of the focused component remains visible. Checks: 1. Tab through the page with sticky headers, footers, notices and expanded panels in place. 2. Check focused components near viewport edges and repeat at zoomed and narrow sizes. 3. Where user-opened content obscures focus, verify any applicable mechanism for revealing the component without advancing focus. Limitations: The AA minimum prohibits complete hiding; partial coverage still deserves repair and can fail the enhanced criterion. Review WCAG's notes for movable and user-opened content rather than assuming all overlays are exceptions. Sources: - W3C: Understanding 2.4.11 Focus Not Obscured (Minimum): https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum ## WCAG 2.4.12: Focus Not Obscured (Enhanced) https://whatisada.com/wcag/2-4-12-focus-not-obscured-enhanced Updated: 2026-09-11 At Level AAA, no part of a component receiving keyboard focus may be hidden by author-created content. This strengthens the minimum rule that prohibits complete hiding. Example: A fixed help bar leaves a button's label visible but covers half its clickable area. Move the bar, add scroll padding or change the layout so the entire focused component can be seen. Checks: 1. Navigate through all focusable components with persistent overlays and sticky regions enabled. 2. Check the whole component boundary at each stop, including zoom and responsive layouts. 3. Repair partial overlaps and repeat both forward and reverse keyboard navigation. Limitations: A component can satisfy the AA minimum while failing this enhanced rule. Test the whole component, not merely whether its focus outline or some text remains visible. Sources: - W3C: Understanding 2.4.12 Focus Not Obscured (Enhanced): https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-enhanced.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#focus-not-obscured-enhanced ## WCAG 2.4.13: Focus Appearance https://whatisada.com/wcag/2-4-13-focus-appearance Updated: 2026-09-11 At Level AAA, a visible focus indicator needs an area at least equivalent to a two-CSS-pixel perimeter and a 3:1 change between the same pixels in focused and unfocused states, subject to stated browser-control exceptions. Example: A thin pale focus ring is easy to miss on a large button. Use a sufficiently large, high-contrast indicator and compare its actual area and state change instead of measuring only the button label. Checks: 1. Identify the visible component or subcomponent receiving the indicator and calculate the reference perimeter area. 2. Measure the indicator area that achieves at least 3:1 between the same focused and unfocused pixels. 3. Review any unmodified browser-indicator exception and test different backgrounds and clipped containers. Limitations: This comparison is between states at the same pixels. It is not simply text contrast or a blanket requirement that every ring be exactly two pixels thick. Sources: - W3C: Understanding 2.4.13 Focus Appearance: https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#focus-appearance ## WCAG 2.5.1: Pointer Gestures https://whatisada.com/wcag/2-5-1-pointer-gestures Updated: 2026-09-11 Functions using multipoint or path-based gestures need a single-pointer alternative that does not require a path, unless the gesture is essential. This supports people who cannot reliably pinch, draw a gesture or use several fingers. Example: A map uses pinch to zoom. Add separate Zoom in and Zoom out buttons that work with a single tap, and provide other controls for any additional gesture-only functions. Checks: 1. Inventory pinch, multi-finger, swipe-path and drawn-gesture interactions controlled by the page. 2. Find a single-pointer action that performs the same function without requiring a particular path. 3. Test the alternative on the actual touch interface and document any essential-gesture exception. Limitations: Keyboard operation alone does not establish a single-pointer alternative. Dragging has an additional WCAG 2.2 criterion and should be reviewed separately. Sources: - W3C: Understanding 2.5.1 Pointer Gestures: https://www.w3.org/WAI/WCAG22/Understanding/pointer-gestures.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#pointer-gestures ## WCAG 2.5.2: Pointer Cancellation https://whatisada.com/wcag/2-5-2-pointer-cancellation Updated: 2026-09-11 Single-pointer actions should avoid committing a function on pointer-down, allow abort or undo around completion, reverse the down action on release, or meet an essential exception. This gives people a chance to correct an unintended press. Example: A destructive button deletes a record on mousedown. Use normal button activation on release and a suitable confirmation or undo flow, so pressing and moving away does not immediately commit deletion. Checks: 1. Inspect controls implemented with pointerdown, mousedown or touchstart handlers. 2. Press a control, move away before release and observe whether the action can be abandoned. 3. Where another permitted route is used, verify the actual undo or reversal behavior and document any essential case. Limitations: Event names alone do not prove the outcome. Review what commits on each event, including side effects that happen before a later click handler runs. Sources: - W3C: Understanding 2.5.2 Pointer Cancellation: https://www.w3.org/WAI/WCAG22/Understanding/pointer-cancellation.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#pointer-cancellation ## WCAG 2.5.3: Label in Name https://whatisada.com/wcag/2-5-3-label-in-name Updated: 2026-09-11 When a control has a visible text label, its accessible name must contain that text. People using speech input often speak the words they see, so a conflicting hidden name can make the control difficult to target. Example: A button visibly says “Send message” but aria-label changes its name to “Submit inquiry.” Remove the conflicting override or use a name that contains “Send message,” preferably at the beginning. Checks: 1. List controls with visible text or images of text. 2. Inspect each computed accessible name rather than only its HTML attributes. 3. Check that the visible words are included in the name and try the visible phrase with supported speech input where available. Limitations: A more descriptive hidden label can still introduce a mismatch. Check localization and changing button labels because the accessible name may be left behind after the visible wording changes. Sources: - W3C: Understanding 2.5.3 Label in Name: https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#label-in-name ## WCAG 2.5.4: Motion Actuation https://whatisada.com/wcag/2-5-4-motion-actuation Updated: 2026-09-11 Functions triggered by device or user motion need an interface-control alternative, and the motion response can be disabled unless a defined exception applies. A person may have a mounted device or move involuntarily. Example: A form clears when the phone is shaken. Provide a visible Clear form action with appropriate protection, and a setting that disables shake activation while keeping the normal control available. Checks: 1. Identify actions triggered by shaking, tilting, camera-tracked movement or similar motion. 2. Complete each function through ordinary interface controls. 3. Disable motion activation and verify that accidental movement no longer triggers the action, while checking any supported-interface or essential exception. Limitations: An alternative control addresses only one part of the criterion. Users also need to prevent unintended motion activation where the requirement applies. Sources: - W3C: Understanding 2.5.4 Motion Actuation: https://www.w3.org/WAI/WCAG22/Understanding/motion-actuation.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#motion-actuation ## WCAG 2.5.5: Target Size (Enhanced) https://whatisada.com/wcag/2-5-5-target-size-enhanced Updated: 2026-09-11 At Level AAA, pointer targets are generally at least 44 by 44 CSS pixels, with specified exceptions for equivalent controls, inline targets, unmodified browser controls and essential presentation. Example: A dense toolbar uses 20-pixel icons with tiny click areas. Increase the actual button boxes to at least 44 by 44 CSS pixels, preserving enough space between functions and keeping the visual labels understandable. Checks: 1. Measure the actual interactive bounding boxes in CSS pixels. 2. Review small targets against each defined exception, including equivalent controls on the same page. 3. Test the layout at narrow widths and enlarged text so larger targets remain operable without overlap. Limitations: An icon can be smaller than its target if the surrounding padding is interactive. Physical device pixels are not CSS pixels, and the AA spacing exception for 2.5.8 should not be imported here. Sources: - W3C: Understanding 2.5.5 Target Size (Enhanced): https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#target-size-enhanced ## WCAG 2.5.6: Concurrent Input Mechanisms https://whatisada.com/wcag/2-5-6-concurrent-input-mechanisms Updated: 2026-09-11 At Level AAA, content does not unnecessarily restrict input methods available on the platform. People may switch between touch, pointer, keyboard and other mechanisms during the same task. Example: A tablet site disables keyboard handlers after the first touch event. Keep both pathways available so a person can touch a field and then continue using a connected keyboard. Checks: 1. Use a device or setup supporting more than one input mechanism. 2. Begin a task with one mechanism, switch to another and then switch back. 3. Check that all available mechanisms continue to operate unless a restriction is essential, required for security or respects a user setting. Limitations: Detecting touch capability does not mean keyboard access is unnecessary. Avoid mutually exclusive event paths that silently disable another supported way of interacting. Sources: - W3C: Understanding 2.5.6 Concurrent Input Mechanisms: https://www.w3.org/WAI/WCAG22/Understanding/concurrent-input-mechanisms.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#concurrent-input-mechanisms ## WCAG 2.5.7: Dragging Movements https://whatisada.com/wcag/2-5-7-dragging-movements Updated: 2026-09-11 Functions requiring a dragging movement need a single-pointer alternative without dragging, unless dragging is essential or the behavior is an unmodified browser function. Reordering controls and precise placement often need an explicit alternative. Example: A task board moves cards only by dragging. Add a “Move task” control that lets the user choose a destination column and position through taps or clicks. Checks: 1. Inventory sortable lists, sliders, drawing handles, upload zones and other drag interactions. 2. Find an equivalent action requiring only individual pointer activations. 3. Complete the same outcome with that alternative and check that its state update is visible and understandable. Limitations: Keyboard arrow-key support is valuable but does not alone meet the single-pointer requirement. Do not assume an off-the-shelf drag library supplies the needed alternative. Sources: - W3C: Understanding 2.5.7 Dragging Movements: https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#dragging-movements ## WCAG 2.5.8: Target Size (Minimum) https://whatisada.com/wcag/2-5-8-target-size-minimum Updated: 2026-09-11 At Level AA, pointer targets are generally at least 24 by 24 CSS pixels or satisfy a defined exception. For undersized targets, the spacing option uses centered 24-pixel circles and their relationship to neighboring targets. Example: A row of small icon buttons is difficult to select precisely. Increase each button's interactive padding, or evaluate the exact spacing exception rather than assuming a small visual gap is sufficient. Checks: 1. Measure each target's bounding box in CSS pixels, including the interactive padding. 2. For an undersized target relying on spacing, center a 24-pixel-diameter circle on its box and check for prohibited intersections. 3. Document any equivalent-control, inline, browser-control or essential-presentation exception and test the responsive layout. Limitations: A 24-pixel gap is not the wording of the spacing rule. Avoid describing “legacy controls” as a general exception; evaluate the specific conditions in the standard. Sources: - W3C: Understanding 2.5.8 Target Size (Minimum): https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#target-size-minimum ## WCAG 3.1.1: Language of Page https://whatisada.com/wcag/3-1-1-language-of-page Updated: 2026-09-11 The default human language of a page must be available programmatically. In HTML, a valid lang value on the root element helps screen readers choose appropriate pronunciation and other software process the text. Example: An English page inherits lang="fr" from a copied template. Set the page's actual default language to English and verify that localized routes declare their own language rather than sharing the same root value. Checks: 1. Identify the predominant language of each representative route. 2. Inspect the document's root language declaration and check that its value is valid and accurate. 3. Navigate between localized pages and listen for appropriate pronunciation with a screen reader configured for available voices. Limitations: A language picker does not automatically set the document language. The server-rendered page and client-side navigation both need the correct declaration. Sources: - W3C: Understanding 3.1.1 Language of Page: https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#language-of-page ## WCAG 3.1.2: Language of Parts https://whatisada.com/wcag/3-1-2-language-of-parts Updated: 2026-09-11 Identify the language of passages or phrases that differ from the page's default, except for defined cases such as proper names, technical terms and words adopted into surrounding usage. This helps pronunciation follow the content. Example: An English travel page contains a full Spanish announcement. Wrap that passage with lang="es" while keeping the rest of the page English, instead of changing the language of the entire article. Checks: 1. Locate passages written in a language different from the page default. 2. Inspect the nearest applicable language attribute and check its value. 3. Read the passage with suitable screen-reader voices and confirm that the language switches and returns at the right boundaries. Limitations: Do not tag every borrowed word or personal name as a language change. The exceptions and actual usage matter, and voice availability can affect the listening test. Sources: - W3C: Understanding 3.1.2 Language of Parts: https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#language-of-parts ## WCAG 3.1.3: Unusual Words https://whatisada.com/wcag/3-1-3-unusual-words Updated: 2026-09-11 At Level AAA, provide a way to identify specific meanings of unusual or restricted words, including jargon and idioms. A short explanation where the term first matters is often the most useful route. Example: A service guide tells users to “reconcile the account.” Explain what reconcile means in this process and link to a relevant definition, rather than assuming the user understands accounting terminology. Checks: 1. Review the page for specialized terms, idioms and ordinary words used with a restricted meaning. 2. Find a definition mechanism that supplies the intended meaning in this context. 3. Check that the mechanism is accessible by keyboard and assistive technology and does not require understanding more unexplained jargon. Limitations: A general dictionary entry may not explain the product's specific meaning. Tooltips that cannot be reached or dismissed can create an additional barrier while trying to explain the word. Sources: - W3C: Understanding 3.1.3 Unusual Words: https://www.w3.org/WAI/WCAG22/Understanding/unusual-words.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#unusual-words ## WCAG 3.1.4: Abbreviations https://whatisada.com/wcag/3-1-4-abbreviations Updated: 2026-09-11 At Level AAA, users can identify the expansion or meaning of abbreviations. This includes acronyms and shortened forms that may be familiar to the team but unfamiliar to a visitor. Example: A procurement page introduces “Accessibility Conformance Report (ACR)” before using ACR later. An adjacent glossary link supports visitors who enter the page at a later section. Checks: 1. List acronyms, initialisms and shortened forms in the content. 2. Check that a usable mechanism reveals their expansion or intended meaning. 3. Verify ambiguous abbreviations in context and test the mechanism without a mouse. Limitations: An abbr title may not be exposed consistently to touch and assistive-technology users. Plain-text expansion or a clearly linked glossary can be easier to discover and verify. Sources: - W3C: Understanding 3.1.4 Abbreviations: https://www.w3.org/WAI/WCAG22/Understanding/abbreviations.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#abbreviations ## WCAG 3.1.5: Reading Level https://whatisada.com/wcag/3-1-5-reading-level Updated: 2026-09-11 At Level AAA, material requiring reading ability above lower-secondary education needs supplemental content or a simpler version, after excluding proper names and titles from that assessment. Preserve the actual meaning when simplifying. Example: A technical eligibility policy keeps its full wording and adds a plain-language explanation with examples and a step-by-step eligibility walkthrough. The simpler route communicates the same important conditions. Checks: 1. Review whether the main text requires advanced reading ability, using both editorial judgment and appropriate assessment. 2. Locate supplemental material or a version within the criterion's reading-level target. 3. Compare the alternatives for preserved conditions, instructions and consequences, including important exceptions. Limitations: A readability score alone cannot establish comprehension or equivalent meaning. Replacing long words while deleting essential qualifications is not a useful accessible alternative. Sources: - W3C: Understanding 3.1.5 Reading Level: https://www.w3.org/WAI/WCAG22/Understanding/reading-level.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#reading-level ## WCAG 3.1.6: Pronunciation https://whatisada.com/wcag/3-1-6-pronunciation Updated: 2026-09-11 At Level AAA, provide a way to identify pronunciation when a word's meaning in context depends on how it is spoken and would otherwise be ambiguous. This is a targeted requirement, not a demand to pronounce every word. Example: A language lesson uses the same written word for two meanings distinguished by pronunciation. Add a phonetic explanation or an accessible audio example associated with each use so learners can distinguish them. Checks: 1. Find words where pronunciation is necessary to disambiguate the intended meaning. 2. Check for an available pronunciation mechanism suited to the language and audience. 3. Verify that a text or audio explanation is associated with the correct occurrence and can be operated accessibly. Limitations: A pronunciation guide is not required for every unfamiliar word under this criterion. Assess ambiguity of meaning in context and consider whether audio-only help needs an additional usable explanation. Sources: - W3C: Understanding 3.1.6 Pronunciation: https://www.w3.org/WAI/WCAG22/Understanding/pronunciation.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#pronunciation ## WCAG 3.2.1: On Focus https://whatisada.com/wcag/3-2-1-on-focus Updated: 2026-09-11 Receiving focus must not itself trigger a change of context. Users need to inspect a control before deciding to activate it, especially when navigating with a keyboard or assistive technology. Example: Tabbing to a subscription field immediately opens a new page. Remove the focus-triggered navigation and provide a clearly labeled action that the user activates when ready. Checks: 1. Move focus through all controls without activating them. 2. Watch for navigation, new windows, unexpected focus relocation or other context changes. 3. Repeat in menus, conditional forms and embedded widgets, where focus handlers may behave differently. Limitations: Revealing helpful content is not automatically a change of context, but it can have its own requirements. Distinguish ordinary state information from changes that disrupt the user's current task or location. Sources: - W3C: Understanding 3.2.1 On Focus: https://www.w3.org/WAI/WCAG22/Understanding/on-focus.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#on-focus ## WCAG 3.2.2: On Input https://whatisada.com/wcag/3-2-2-on-input Updated: 2026-09-11 Changing a control's setting must not unexpectedly change context unless the user was told beforehand. Explicit action buttons are often clearer than automatically navigating when a radio or select value changes. Example: A question advances as soon as a radio answer is chosen, losing keyboard focus. Keep the selection on the current question and let the person press Next, then move focus predictably to the next question. Checks: 1. Change checkboxes, radio buttons and select values using keyboard and pointer input. 2. Observe whether the change causes navigation, new windows, moved focus or a major context shift. 3. For any automatic context change, verify an understandable warning provided before the control is used. Limitations: Updating a nearby price or showing relevant fields is not necessarily a context change. Evaluate the actual effect; a visible animation does not compensate for unexpected navigation or lost focus. Sources: - W3C: Understanding 3.2.2 On Input: https://www.w3.org/WAI/WCAG22/Understanding/on-input.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#on-input ## WCAG 3.2.3: Consistent Navigation https://whatisada.com/wcag/3-2-3-consistent-navigation Updated: 2026-09-11 Navigation repeated across a set of pages must keep the same relative order unless the user initiates a change. Predictability helps users find familiar destinations without relearning the layout. Example: A help center reverses the positions of Contact and Documentation on different article templates. Use a shared navigation source so those links remain in the same relative order across the page set. Checks: 1. Select pages using different templates within the same site section. 2. Compare the repeated navigation items in reading and focus order. 3. Test the same responsive variation across pages and document any ordering change that the user intentionally requests. Limitations: This does not prohibit adding a context-specific link or responsive layouts. The relevant test is the relative order of repeated mechanisms under comparable conditions. Sources: - W3C: Understanding 3.2.3 Consistent Navigation: https://www.w3.org/WAI/WCAG22/Understanding/consistent-navigation.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#consistent-navigation ## WCAG 3.2.4: Consistent Identification https://whatisada.com/wcag/3-2-4-consistent-identification Updated: 2026-09-11 Components with the same functionality in a page set should be identified consistently. Consistent labels and recognizable indicators let users transfer what they learned from one page to another. Example: The same support action is called “Ask us,” “Help desk” and “Open assistance” on three templates. Use a consistent identification scheme while preserving distinctions between genuinely different functions. Checks: 1. Inventory repeated actions and components across representative templates. 2. Compare their visible labels, accessible names and meaningful icons. 3. Resolve inconsistent identification for equivalent functions and ensure different actions are not misleadingly given the same name. Limitations: Consistency does not require identical text for every link. “Download invoice” and “Download statement” can consistently identify the same kind of action while describing different objects. Sources: - W3C: Understanding 3.2.4 Consistent Identification: https://www.w3.org/WAI/WCAG22/Understanding/consistent-identification.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#consistent-identification ## WCAG 3.2.5: Change on Request https://whatisada.com/wcag/3-2-5-change-on-request Updated: 2026-09-11 At Level AAA, context changes happen only at the user's request, or a mechanism allows the changes to be turned off. Users should retain control over their location and focus. Example: A dashboard automatically redirects to a new detail view when fresh data arrives. Keep the user on the current view and offer an explicit Open update action, or provide a setting that disables the automatic transition. Checks: 1. Observe the page during normal activity, waiting periods and background updates. 2. Identify navigation, focus shifts, new windows and comparable context changes. 3. Verify that each follows a user request or can be disabled through an accessible mechanism. Limitations: A countdown warning can make a change less surprising but does not necessarily satisfy this enhanced rule. Compare this criterion separately with the A-level rules for focus and input. Sources: - W3C: Understanding 3.2.5 Change on Request: https://www.w3.org/WAI/WCAG22/Understanding/change-on-request.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#change-on-request ## WCAG 3.2.6: Consistent Help https://whatisada.com/wcag/3-2-6-consistent-help Updated: 2026-09-11 When specified help mechanisms repeat across a set of pages, keep their order relative to other content consistent unless the user changes it. This includes human contact, self-help and automated contact routes. Example: An application places Contact support after the main form on every step. Keeping the help route in a predictable place lets someone find assistance without starting over when a difficult question appears. Checks: 1. Identify repeated contact details, contact mechanisms, self-help links and automated help. 2. Compare their relative order across pages at the same layout variation. 3. Check that responsive or user-customized changes are understood separately from unexplained differences between templates. Limitations: The criterion does not require every page to add a new help mechanism. It governs consistency when the listed mechanisms are present and repeated. Sources: - W3C: Understanding 3.2.6 Consistent Help: https://www.w3.org/WAI/WCAG22/Understanding/consistent-help.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#consistent-help ## WCAG 3.3.1: Error Identification https://whatisada.com/wcag/3-3-1-error-identification Updated: 2026-09-11 When an input error is detected automatically, identify the field and describe the error in text. A colored border alone does not tell users what went wrong. Example: A registration form rejects a date with only a red outline. Add “Enter a real calendar date” next to the date field and associate it with that field; an error summary can also link back to the problem. Checks: 1. Submit empty, malformed and out-of-range values that the application can detect. 2. Check that each affected item is identified and has a meaningful text explanation. 3. Verify the error relationship in the accessibility tree and make sure the user can return to the field without losing other entries. Limitations: “Something went wrong” may be appropriate for an unknown server failure but is inadequate when a specific input error is known. Keep input errors distinct from service outages. Sources: - W3C: Understanding 3.3.1 Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#error-identification ## WCAG 3.3.2: Labels or Instructions https://whatisada.com/wcag/3-3-2-labels-or-instructions Updated: 2026-09-11 Provide labels or instructions when users must enter information. Explain the requested value and necessary conditions at the point where the person needs them. Example: A document uploader accepts only PDF files below a size limit. Name the input “Upload your application PDF” and show the allowed format and size before submission, rather than revealing every condition only after failure. Checks: 1. Review each field, selection group and upload control for a visible label or useful instruction. 2. Check that required formats, limits and unusual constraints are explained before input. 3. Complete the form without relying on placeholder text that disappears as soon as typing begins. Limitations: More instruction is not always better. Keep essential guidance close and concise, then provide optional details without making every field label excessively long. Sources: - W3C: Understanding 3.3.2 Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#labels-or-instructions ## WCAG 3.3.3: Error Suggestion https://whatisada.com/wcag/3-3-3-error-suggestion Updated: 2026-09-11 When automatically detected input errors have known corrections, suggest how to fix them unless doing so would compromise security or the content's purpose. A diagnosis and a repair instruction solve different problems. Example: A booking rejects an arrival date because it is before today. State “Choose today or a later date” so the visitor knows how to correct it rather than repeatedly guessing at the accepted format. Checks: 1. Trigger errors for formats, ranges and incompatible selections. 2. Check whether the system knows a useful correction and whether it communicates that correction. 3. Verify that suggestions remain accurate for the current state and do not reveal protected account or security information. Limitations: A password-recovery page may intentionally avoid revealing whether an account exists. Apply the security exception carefully while still giving safe, usable recovery instructions. Sources: - W3C: Understanding 3.3.3 Error Suggestion: https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#error-suggestion ## WCAG 3.3.4: Error Prevention (Legal, Financial, Data) https://whatisada.com/wcag/3-3-4-error-prevention-legal-financial-data Updated: 2026-09-11 For specified consequential submissions, provide a reversible action, error checking with a chance to correct, or review/confirmation with correction before finalizing. Covered cases include legal commitments, financial transactions, stored user-data changes and test responses. Example: Before a customer places a paid order, show the items, quantities, delivery address and total with working Edit controls. The final action clearly commits the order after the customer has had a chance to correct it. Checks: 1. Identify submissions creating commitments, transactions, stored-data changes or test-response submission. 2. Verify at least one permitted protection: reversal, checking with correction, or review/confirm/correct. 3. Deliberately make a mistake and use the protection to recover before or after commitment as designed. Limitations: A confirmation dialog saying only “Are you sure?” may provide little opportunity to review the actual information. Check the complete workflow and whether corrections really reach the final submission. Sources: - W3C: Understanding 3.3.4 Error Prevention (Legal, Financial, Data): https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#error-prevention-legal-financial-data ## WCAG 3.3.5: Help https://whatisada.com/wcag/3-3-5-help Updated: 2026-09-11 At Level AAA, context-sensitive help is available. Users should be able to understand the current task or field without leaving the process to search through unrelated documentation. Example: A tax-identifier field includes a help link explaining where to find the identifier and which format the current application expects. The help opens predictably and preserves the entered form values. Checks: 1. Identify steps and inputs where users may need task-specific assistance. 2. Find help relevant to that exact field, question or action. 3. Open, read and dismiss the help using keyboard navigation, checking that focus and previously entered data remain intact. Limitations: A general contact page can be useful but may not provide the context-sensitive explanation needed here. Help content itself must be understandable and accessible. Sources: - W3C: Understanding 3.3.5 Help: https://www.w3.org/WAI/WCAG22/Understanding/help.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#help ## WCAG 3.3.6: Error Prevention (All) https://whatisada.com/wcag/3-3-6-error-prevention-all Updated: 2026-09-11 At Level AAA, all pages requiring information submission provide reversal, checking with correction, or review/confirmation with correction. This extends error-prevention protection beyond the consequential categories in 3.3.4. Example: A feedback form lets someone review the selected category and message before sending, with an Edit action that returns to the completed fields. The final step does not silently change the submitted values. Checks: 1. Inventory every information-submission flow, including simple feedback and preferences. 2. Verify a permitted prevention route for each flow. 3. Make and correct an intentional mistake, then confirm the final submitted values reflect the correction. Limitations: Do not assume that a protection added to checkout also covers unrelated forms. This AAA criterion has broader scope than the AA requirement. Sources: - W3C: Understanding 3.3.6 Error Prevention (All): https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-all.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#error-prevention-all ## WCAG 3.3.7: Redundant Entry https://whatisada.com/wcag/3-3-7-redundant-entry Updated: 2026-09-11 Within the same process, information already entered by or provided to the user and required again should be auto-filled or selectable, unless re-entry is essential, security-related or the prior information is no longer valid. Example: A checkout asks for a billing address after collecting a shipping address. Offer “Use shipping address” and preserve the earlier values, while allowing a different billing address when needed. Checks: 1. Walk through the complete process and note repeated requests for the same information. 2. Check that previous values are populated or offered for selection at the later step. 3. Change earlier data and verify that the reuse option updates correctly; document any valid security or freshness exception. Limitations: Browser autofill alone is not a dependable replacement for the process making earlier information available. The rule is about the same process, not a requirement to retain every value across unrelated visits. Sources: - W3C: Understanding 3.3.7 Redundant Entry: https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#redundant-entry ## WCAG 3.3.8: Accessible Authentication (Minimum) https://whatisada.com/wcag/3-3-8-accessible-authentication-minimum Updated: 2026-09-11 Authentication steps should not require an unassisted cognitive test unless a defined exception applies. Alternatives or assistance such as password-manager support and paste can remove memory and transcription barriers; AA also permits specified recognition exceptions. Example: A sign-in form blocks pasting a one-time code and separates it into six fields. Allow the complete code to be pasted and correctly distributed or use one clearly labeled field, then test the full login and recovery process. Checks: 1. List cognitive tasks in sign-in, multifactor verification, account recovery and re-authentication. 2. Test password managers, copy/paste and alternative authentication routes at each affected step. 3. Check any claimed object-recognition or user-provided-content exception against the precise AA conditions. Limitations: Allowing paste in the password field does not establish that the recovery or verification step works. An inaccessible third-party challenge remains part of the user's authentication process. Sources: - W3C: Understanding 3.3.8 Accessible Authentication (Minimum): https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#accessible-authentication-minimum ## WCAG 3.3.9: Accessible Authentication (Enhanced) https://whatisada.com/wcag/3-3-9-accessible-authentication-enhanced Updated: 2026-09-11 At Level AAA, authentication cannot require a cognitive test unless an alternative avoids it or a mechanism assists the user. The object-recognition and personal-content exceptions from the AA criterion are not included. Example: A login flow uses an image-identification challenge as its only recovery route. Provide an alternative or assisting mechanism that removes the cognitive test, and verify that it works through all recovery stages. Checks: 1. Review every authentication and recovery step for memory, transcription and puzzle demands. 2. Verify a usable non-cognitive alternative or an effective assisting mechanism for each. 3. Repeat the workflow without relying on the recognition exceptions available only in the minimum criterion. Limitations: An AA authentication pass does not automatically establish AAA. Record which route the user can actually complete, including any third-party identity provider. Sources: - W3C: Understanding 3.3.9 Accessible Authentication (Enhanced): https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-enhanced.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#accessible-authentication-enhanced ## WCAG 4.1.1: Parsing (legacy) https://whatisada.com/wcag/4-1-1-parsing Updated: 2026-09-11 Parsing was removed from WCAG 2.2. W3C now says the legacy 2.0/2.1 criterion is always satisfied for HTML or XML. Markup problems that break names, relationships or operation should be reported under the relevant retained criteria. Example: An older procurement template includes a Parsing row. Record the required WCAG version and the applicable reporting guidance instead of silently deleting the row; separately repair a duplicate ID that makes a label point to the wrong input. Checks: 1. Identify the exact WCAG version required by the evaluation or contract. 2. For a 2.0/2.1 report on HTML or XML, follow W3C's current always-satisfied note and document the version and technology. 3. Investigate actual user-facing effects of markup errors and report them under the relevant retained criteria. Limitations: Do not list Parsing as an active WCAG 2.2 A criterion. Equally, removal from 2.2 does not mean broken HTML associations or duplicate accessible identifiers are harmless. Sources: - W3C: current WCAG 2.1 Parsing guidance: https://www.w3.org/WAI/WCAG21/Understanding/parsing.html - W3C: Understanding 4.1.1 Parsing (Obsolete and removed): https://www.w3.org/WAI/WCAG22/Understanding/parsing.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#parsing ## WCAG 4.1.2: Name, Role, Value https://whatisada.com/wcag/4-1-2-name-role-value Updated: 2026-09-11 User-interface components need programmatically determinable names and roles, and their user-settable states, properties and values must be available to software. Assistive technology must be informed when those values change. Example: A custom disclosure visually opens a panel but exposes neither a button role nor its expanded state. Use a native button with a useful name and update aria-expanded in sync with the visible panel. Checks: 1. Inspect the computed role, name and relevant states of each native or custom control. 2. Operate the control and watch the accessibility tree for accurate value and state changes. 3. Use a screen reader to check that a person can identify the control and understand its current state during the task. Limitations: ARIA does not implement keyboard behavior. A control can expose a plausible role while remaining unusable, and a stale expanded or selected value can contradict the actual interface. Sources: - W3C: Understanding 4.1.2 Name, Role, Value: https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#name-role-value ## WCAG 4.1.3: Status Messages https://whatisada.com/wcag/4-1-3-status-messages Updated: 2026-09-11 In markup-based content, status messages must have roles or properties that allow assistive technology to announce them without moving focus. Users need to hear results, progress and errors while continuing their task. Example: A filter changes a product list from 40 items to 6. Keep focus in the filter and update a concise status region to “6 products found,” rather than making the entire results grid a live region. Checks: 1. Identify messages about results, progress, waiting states and errors that do not receive focus. 2. Inspect the message's semantic role or live-region properties and trigger a real update. 3. With a screen reader, verify a timely, concise announcement while focus stays where the user expects. Limitations: Not every content update is a status message. Avoid assertive announcements for routine updates and prevent repeated or excessively long announcements that interrupt the task. Sources: - W3C: Understanding 4.1.3 Status Messages: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html - WCAG 2.2 standard: https://www.w3.org/TR/WCAG22/#status-messages ## Accessible buttons: Examples and Testing https://whatisada.com/patterns/buttons Updated: 2026-09-11 Use a native button for an action performed on the current page, such as saving a draft or opening a dialog. Its visible name should describe the action, and its type should avoid accidental form submission. Example: An invoice card includes “Email invoice.” Make it a button, preserve focus while the action runs and announce the actual result. A failed request must not produce the same success message as an accepted one. Checks: 1. Reach the button with Tab and activate it with both Enter and Space. 2. Check the computed name, disabled/loading states and visible focus in each theme. 3. Confirm that the action occurs once and that success and failure both leave a usable next step. Limitations: A clickable div needs behavior that a native button already supplies. Do not combine an action button with nested links or other interactive children. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/button/ ## Accessible toggle buttons: Examples and Testing https://whatisada.com/patterns/toggle-buttons Updated: 2026-09-11 A toggle button represents an on/off state for an action or mode. Keep a stable label and expose its pressed state so a user can distinguish the action from whether it is currently active. Example: An editor has a Bold button. The label stays “Bold” while aria-pressed changes with the selected formatting, and the appearance supplies a second visible state cue. Checks: 1. Activate the toggle with Enter, Space and pointer input. 2. Inspect aria-pressed and the visible state before and after activation. 3. Verify that the label stays understandable and that unrelated state updates do not reset the toggle. Limitations: Changing both the label and the pressed semantics can make the meaning confusing. A command whose wording changes from Play to Pause is often better expressed as an ordinary action button. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/button/ ## Accessible links: Examples and Testing https://whatisada.com/patterns/links Updated: 2026-09-11 Use a real anchor with a destination when the purpose is navigation. Write link text that identifies the destination or resource, and preserve normal browser behaviors such as opening in a new tab. Example: A billing page links to “Download April invoice (PDF).” The destination and file type are understandable without a vague “click here,” and the user can copy the link normally. Checks: 1. Navigate and activate the link by keyboard, then use the browser's open-in-new-tab behavior. 2. Read its accessible name and compare it with its visible label and destination. 3. Check focus, color-independent identification and any advance information needed for a file or external workflow. Limitations: An anchor without href is not an ordinary navigational link. Do not use href="#" to imitate a button or make the user infer the destination from an unlabeled icon. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/link/ ## Accessible checkboxes: Examples and Testing https://whatisada.com/patterns/checkboxes Updated: 2026-09-11 Use a checkbox for an independently selectable choice. Associate its visible label and preserve the checked state across validation, navigation and other updates so the user remains in control. Example: A preferences form offers separate options for product news and event invitations. Each can be chosen independently; changing one does not navigate away or silently change the other. Checks: 1. Use Tab to focus and Space to toggle each checkbox. 2. Select multiple options and verify independent state, label activation and persistence after an error. 3. Read the control with a screen reader and check that its name and checked state agree with the visible form. Limitations: Do not store choices only as shared numeric scores. Distinct options need distinct values, even when their downstream weighting happens to match. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/checkbox/ ## Accessible radio groups: Examples and Testing https://whatisada.com/patterns/radio-groups Updated: 2026-09-11 Radio buttons let users choose one option within a named group. Give each option a unique value, use a shared group name and let selection stay in place until the user requests the next step. Example: An audit planner asks which environment will be tested. “Public website” and “Signed-in application” remain distinct choices even if both happen to lead to a similar checklist. Checks: 1. Enter the group with Tab and change the choice with arrow keys and Space according to browser behavior. 2. Verify one checked option, a useful group legend and activation through each label. 3. Go forward with an explicit Next action, return and confirm that exactly the original option remains selected. Limitations: Auto-advancing after a radio change can remove focus before the user finishes choosing. Group identity and option identity must not depend on a score or array position that can collide. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/radio/ ## Accessible switches: Examples and Testing https://whatisada.com/patterns/switches Updated: 2026-09-11 A switch represents a setting that is on or off. Keep its label stable, expose the current state and make activation work through the expected keyboard behavior, without depending on the thumb's position or color alone. Example: A reading view has a “Reduced motion” switch. Turning it on suppresses nonessential transitions immediately while leaving the same label in place and displaying the current state in text. Checks: 1. Focus the switch and operate it using the expected key, including Space. 2. Check that the accessible state and visible on/off indication update together. 3. Reload or revisit the setting if persistence is promised and verify that the preference still applies. Limitations: A decorative slider shape does not create switch semantics. A native checkbox with appropriate styling may be simpler; if role="switch" is used, test its supported state mapping. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/switch/ ## Accessible text inputs: Examples and Testing https://whatisada.com/patterns/text-inputs Updated: 2026-09-11 Give text inputs visible labels and explain important constraints before entry. Use semantic input types and accurate autocomplete values where the input purpose is covered, then associate hints and errors without replacing the label. Example: A contact form asks for an email address. It uses an email input, a visible label and a short hint explaining where replies will go. The label remains visible after typing begins. Checks: 1. Focus the field and verify the announced label, type and associated hint. 2. Enter a valid value and a malformed value, checking that validation preserves the entry and identifies the error. 3. Test autocomplete where appropriate and compare the accessible name with the visible label. Limitations: Disappearing input hints cannot replace persistent labels. An aria-label that conflicts with the printed label can also make speech input less reliable. Sources: - Primary implementation guidance: https://www.w3.org/WAI/tutorials/forms/labels/ ## Accessible text areas: Examples and Testing https://whatisada.com/patterns/textareas Updated: 2026-09-11 Use a labeled textarea for multiline input. If there is a length limit, explain it, preserve the user's draft after errors and provide a useful way to understand any remaining limit without incessant announcements. Example: An accessibility feedback form accepts a detailed barrier description. Its instructions invite the page name, expected outcome and what happened, while warning the user not to include confidential information. Checks: 1. Enter several paragraphs with a keyboard and verify that the label and instructions remain available. 2. Approach the stated limit and check how the interface communicates the boundary. 3. Trigger a recoverable submission error and verify that the whole message remains editable. Limitations: A live announcement on every keystroke can overwhelm screen-reader users. Announce meaningful thresholds or validation outcomes instead of continually reading a long character count. Sources: - Primary implementation guidance: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/textarea ## Accessible select controls: Examples and Testing https://whatisada.com/patterns/selects Updated: 2026-09-11 For a straightforward choice from a fixed list, a native select supplies familiar keyboard and platform behavior. Give it a visible label and keep its value separate from unrelated actions such as form submission. Example: A resource filter lets visitors select a document type. Changing the select updates nearby results without moving focus; a short status reports the new count. Checks: 1. Use the keyboard to open and change the selection under the browser's native interaction model. 2. Verify the visible label, current value and handling of an empty or required choice. 3. Check that result updates preserve focus and do not unexpectedly navigate to a different page. Limitations: Replacing a native select with a custom listbox creates additional keyboard and assistive-technology responsibilities. A styled div does not preserve the browser's built-in behavior. Sources: - Primary implementation guidance: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/select ## Accessible numeric inputs: Examples and Testing https://whatisada.com/patterns/number-inputs Updated: 2026-09-11 Use numeric controls when the value is a quantity, and explain units, bounds and valid increments. Keep identifiers such as postal codes or account numbers in text inputs when arithmetic does not describe their purpose. Example: A budget worksheet asks for the number of templates. Label the field with that unit, reject negative or nonfinite values and update the total from the validated quantity. Checks: 1. Enter boundary values, a decimal where disallowed, a negative value and an empty value. 2. Check that the control exposes its name and any valid range while errors explain how to correct the input. 3. Verify that totals do not silently use a stale value behind invalid visible text. Limitations: type="number" alone does not validate your calculation or server input. Decide deliberately whether zero, blank and unknown represent different states. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/spinbutton/ ## Accessible range sliders: Examples and Testing https://whatisada.com/patterns/range-sliders Updated: 2026-09-11 A slider selects a value from an ordered range. Prefer a native range input when it fits, expose the current value and provide a direct-entry alternative when precision or non-dragging operation is important. Example: A text-size preview includes a slider and a numeric percentage field. Either control updates the same value, allowing a person to choose 150 percent without dragging precisely. Checks: 1. Focus the slider and use arrows and supported boundary keys to change its value. 2. Check the announced label, current value, bounds and any text needed to explain units. 3. Set a precise value without dragging and confirm that the preview and alternate input remain synchronized. Limitations: A visible number adjacent to a custom slider may not be its accessible value. Touch assistive-technology support needs real-device testing, particularly for custom slider implementations. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/slider/ ## Accessible progress indicators: Examples and Testing https://whatisada.com/patterns/progress-indicators Updated: 2026-09-11 Use a progress indicator for completion of an ongoing task. Distinguish known progress from an indeterminate wait, provide a useful name and ensure completion or failure is communicated in text. Example: A file processor shows “Preparing report, step 2 of 4.” If the system cannot measure completion, it uses an indeterminate state rather than inventing a percentage that stalls at 99. Checks: 1. Start the operation and inspect the indicator's name and value semantics. 2. Check both measured and unknown-duration states, including cancellation or failure. 3. Verify that a concise status announces meaningful milestones or completion without continually interrupting the user. Limitations: A progress bar is not a rating or a measure of risk. Do not announce every percentage tick or report completion before the underlying operation succeeds. Sources: - Primary implementation guidance: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/progress ## Accessible meters and gauges: Examples and Testing https://whatisada.com/patterns/meters Updated: 2026-09-11 A meter describes a scalar measurement within a known range, such as storage used. It is different from task progress. Show the units and meaning in text so the color or fill length is not the only explanation. Example: An upload area reports 650 MB of a 1,000 MB quota used. The meter visualizes the amount, while the text tells the user how much space is left without implying an upload is currently running. Checks: 1. Inspect the accessible name, minimum, maximum and current value. 2. Compare the visible units and explanation with the value exposed to assistive technology. 3. Test warning thresholds in more than color and confirm that an out-of-range value is handled intentionally. Limitations: Do not use a meter to make an unsupported legal-risk score look like a measured fact. If the number is an estimate or assumption, explain that before visualizing it. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/meter/ ## Accessible form error summaries: Examples and Testing https://whatisada.com/patterns/error-summaries Updated: 2026-09-11 An error summary gives users a compact route to all detected problems after submission. Name the failed action, link each message to its field and preserve the person's entries so correction does not require starting over. Example: A grant form reports two missing items at the top. Each summary link names the field and its required correction; following the link takes focus to that field, where the same error is available. Checks: 1. Submit a form with several known errors and inspect the summary's wording and placement. 2. Follow each error link with a keyboard and verify its focus destination. 3. Correct the errors, resubmit and check that stale messages and invalid states are removed. Limitations: Do not move focus on every keystroke. Focus management after a requested submission can be appropriate, while inline changes usually need less intrusive feedback. Sources: - Primary implementation guidance: https://www.w3.org/WAI/tutorials/forms/notifications/ ## Accessible inline validation errors: Examples and Testing https://whatisada.com/patterns/inline-errors Updated: 2026-09-11 Inline errors identify the affected field and explain what must change. Connect the message to the control, keep useful instructions available and distinguish invalid user input from a service failure. Example: A date input receives “Choose a date after your arrival date.” The field exposes its invalid state and references the message while retaining the entered date for correction. Checks: 1. Trigger a specific validation failure through the intended user action. 2. Inspect aria-invalid and the description relationships, including any persistent hint. 3. Correct the value and verify that both visual and programmatic error states clear at the appropriate time. Limitations: Avoid marking untouched required fields invalid as soon as the page loads. A red outline without text cannot explain the correction, and a stale hidden error can keep being announced. Sources: - Primary implementation guidance: https://www.w3.org/WAI/tutorials/forms/validation/ ## Accessible status messages: Examples and Testing https://whatisada.com/patterns/status-messages Updated: 2026-09-11 Routine status messages should communicate results without taking focus. Use a persistent, concise status region and update it only when there is meaningful information, such as a completed save or new result count. Example: A resource filter changes the visible cards and announces “8 resources found.” The query field keeps focus, and the full list is available to browse normally rather than being read aloud after every change. Checks: 1. Trigger a completed save, result update or other routine status change. 2. Verify that a status/live-region container exists and the message updates without moving focus. 3. Listen with a screen reader for one useful announcement, including the empty-results case. Limitations: Making an entire large panel live can bury the useful update in repeated content. Do not announce success merely because a button was clicked; tie it to the accepted operation. Sources: - Primary implementation guidance: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html ## Accessible urgent alerts: Examples and Testing https://whatisada.com/patterns/alerts Updated: 2026-09-11 Use an alert for important, time-sensitive information that needs prompt announcement without requiring focus. Keep it brief and actionable, and reserve assertive behavior for situations where interruption is justified. Example: A payment request fails after the user submits it. An error message explains that payment was not completed and gives a retry route, while preserving the entered information and avoiding a false confirmation. Checks: 1. Trigger the real failure or important state change in a controlled test. 2. Check that the message is announced and remains available long enough to read. 3. Verify a clear recovery action and ensure duplicate requests do not create repeated alerts. Limitations: Not every update is urgent. Routine counts and successful saves usually fit a polite status message, and an alert that requires a decision may instead need a carefully designed dialog. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/alert/ ## Accessible tooltips and help text: Examples and Testing https://whatisada.com/patterns/tooltips Updated: 2026-09-11 A tooltip supplies a brief description for a focused or hovered control. Make the information available on keyboard focus and satisfy applicable hover/focus persistence and dismissal requirements; use a different pattern for interactive content. Example: A compact help icon describes what an audit template means. The explanation stays open while the user moves onto it and can be dismissed without forcing focus away from the trigger. Checks: 1. Reveal the description through both pointer and keyboard interaction. 2. Test Escape or the intended dismissal method, pointer movement into the tooltip and persistence while reading. 3. Check its association with the trigger and ensure it contains no controls requiring a separate focus model. Limitations: Essential instructions are often clearer as visible text. A tooltip containing links or buttons needs a different interaction design, such as a disclosure or nonmodal dialog. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/ ## Accessible carousels: Examples and Testing https://whatisada.com/patterns/carousels Updated: 2026-09-11 A carousel needs understandable slide controls and an accessible way to stop automatic rotation when used. Preserve meaningful reading order, distinguish the current slide and avoid unexpected motion or focus changes. Example: A product carousel shows several views of the same item. Previous and Next buttons have clear names, the current slide is identified, and rotation remains stopped after the user requests a pause. Checks: 1. Operate previous/next and any slide-selection controls with the keyboard. 2. Pause automatic rotation and check focus/hover behavior and whether rotation restarts unexpectedly. 3. Read the current slide and verify hidden slides do not create confusing focus stops or repeated announcements. Limitations: A rotating carousel often adds complexity without helping the task. Prefer a stable gallery when possible, and never use continuous announcements to narrate every automatic slide change. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/carousel/ ## Accessible autocomplete comboboxes: Examples and Testing https://whatisada.com/patterns/comboboxes Updated: 2026-09-11 A combobox combines an input or selection control with an associated popup. Implement the complete focus, active-option, selection and dismissal model, and keep the typed query distinct from the committed value. Example: A city field suggests matches as the person types. Arrow keys inspect suggestions, Enter commits a choice and Escape dismisses the list without unexpectedly deleting the query. Checks: 1. Type a query and inspect expanded state, popup relationship and the active suggestion. 2. Use arrows, Enter, Escape and Tab according to the chosen combobox pattern. 3. Test no matches, slow responses and a value typed without selecting a suggestion. Limitations: Combobox behavior is more than adding aria-autocomplete. A stale aria-activedescendant can reference a removed option, and asynchronous results can otherwise replace the user's current selection. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/ ## Accessible listboxes: Examples and Testing https://whatisada.com/patterns/listboxes Updated: 2026-09-11 A listbox presents selectable options with a managed keyboard interaction model. Distinguish focus from selection, expose selected states and choose a native select when it can perform the same task more simply. Example: An asset chooser lists one selectable document at a time. The active option moves with the expected keys, selection is clear, and the chosen document name is available to assistive technology. Checks: 1. Enter the widget and navigate options using its documented keyboard model. 2. Check focus, selected state and single- or multiple-selection behavior. 3. Test a long list, scrolling, type-ahead if implemented and changes to the available options. Limitations: Options should not contain unrelated interactive controls. A list of links is generally ordinary navigation, not a listbox, and its expected behavior should remain link-like. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/listbox/ ## Accessible tree views: Examples and Testing https://whatisada.com/patterns/tree-views Updated: 2026-09-11 A tree represents a hierarchical collection with expandable branches and a full tree keyboard model. It can suit a file explorer, but ordinary nested navigation often works better as a list of disclosures and links. Example: A document manager presents folders and documents. Arrow keys move within the hierarchy, expand or collapse branches and preserve a clear active item, while selection remains a separate intentional action where needed. Checks: 1. Navigate with the expected arrow, Home and End behavior, including collapsed and expanded branches. 2. Inspect treeitem levels, expanded states and the active or selected item. 3. Collapse a branch containing the active item and verify that focus moves logically rather than disappearing. Limitations: Do not apply tree/treeitem roles to a static outline without implementing the keyboard contract. A nested list can communicate hierarchy without adding a complex widget interaction. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/treeview/ ## Accessible toolbars: Examples and Testing https://whatisada.com/patterns/toolbars Updated: 2026-09-11 A toolbar groups a related set of controls and, when using the ARIA toolbar pattern, provides efficient keyboard movement within that group. Supply a useful name and preserve each control's own role and state. Example: An editor groups text-formatting controls in a Formatting toolbar. A single entry point and arrow navigation reduce repeated Tab stops while Bold and Italic retain their pressed states. Checks: 1. Enter and leave the toolbar using Tab and navigate inside using the chosen arrow-key model. 2. Operate each type of control, checking that its own key behavior does not conflict with toolbar navigation. 3. Verify roving focus, disabled controls and the toolbar's accessible name. Limitations: A row of ordinary buttons does not always need a toolbar role. Adding the role without its keyboard behavior can create expectations the interface does not fulfill. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/toolbar/ ## Accessible file upload controls: Examples and Testing https://whatisada.com/patterns/file-uploads Updated: 2026-09-11 Keep a labeled native file input available even when a drag-and-drop area is offered. Explain allowed types and limits before selection, and provide clear states for upload progress, rejection and removal. Example: An intake form accepts supporting PDFs. A Choose file control works without dragging, selected filenames are shown in text, and an oversized file gets a specific recoverable error. Checks: 1. Choose a file using keyboard navigation and the platform picker. 2. Test accepted, unsupported and oversized files, including cancellation before upload. 3. Check that progress, failure and removal actions are announced and that the user can replace a file without losing other form data. Limitations: The accept attribute helps the picker but is not server validation. Never make drag-and-drop the sole way to provide a file or hide the real input from all keyboard users. Sources: - Primary implementation guidance: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/file ## Accessible password fields: Examples and Testing https://whatisada.com/patterns/password-fields Updated: 2026-09-11 Password inputs need clear labels, appropriate autocomplete and support for password managers and paste. A reveal control can help users check their entry, but it must accurately describe its action and preserve the field value. Example: A login form lets the password manager fill the password and includes Show password. Activating it changes the presentation while keeping the user's entry and keyboard position stable. Checks: 1. Use a password manager and paste a password into the field. 2. Operate the reveal/hide control by keyboard and inspect its name and state. 3. Test errors and recovery without clearing valid unrelated fields or requiring unnecessary cognitive tasks. Limitations: Blocking paste does not provide a reliable security benefit and creates an authentication barrier. Review the whole sign-in and recovery process, not just the password input. Sources: - Primary implementation guidance: https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html ## Accessible search forms: Examples and Testing https://whatisada.com/patterns/search-forms Updated: 2026-09-11 A search form needs a discoverable search region, a labeled query field, a clear submit action and understandable results. Preserve the query and give users a useful way to recover from an empty result set. Example: A reference site searches both article titles and descriptions. After submission it shows the query, number of results and links with meaningful titles, while filters remain keyboard accessible. Checks: 1. Find the search region and submit a query using Enter and the visible button. 2. Try a useful query, a query with no results and an empty query. 3. Verify the query is preserved, results are announced appropriately and each result link reaches the right page. Limitations: A search interface that indexes only a few hand-written links cannot serve as reliable site navigation. Keep the index connected to the content source and avoid broken legacy destinations. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/practices/landmark-regions/ ## Accessible term and value lists: Examples and Testing https://whatisada.com/patterns/description-lists Updated: 2026-09-11 A description list expresses associations between terms and their descriptions or values. Use it for glossary entries, metadata and compact fact lists when a table or ordinary paragraph would imply a different structure. Example: An audit record lists Scope, Browser and Test date. A description list keeps each term with its value even when the layout changes from two columns to a vertical mobile presentation. Checks: 1. Inspect the term/description relationships in the markup. 2. Read the sequence without visual columns and verify each value stays associated with its term. 3. Test long values, empty values and narrow layouts without truncating essential information. Limitations: A two-column appearance alone does not establish a relationship. Avoid using a description list merely to achieve a visual layout for unrelated content. Sources: - Primary implementation guidance: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/dl ## Accessible disclosure controls: Examples and Testing https://whatisada.com/patterns/disclosures Updated: 2026-09-11 A disclosure reveals or hides a section in place. A native details/summary pair is useful for ordinary expandable content; a custom button-based disclosure needs an accurate expanded state and a reliable relationship to its panel. Example: A shipping page hides optional packaging details below a clear summary. Expanding it leaves focus on the trigger, reveals the information in reading order and does not move the visitor to another page. Checks: 1. Open and close the disclosure using keyboard and pointer input. 2. Verify that the trigger's name and state match the visible panel. 3. Check that hidden panel controls cannot receive focus and that the content remains readable at enlarged text sizes. Limitations: Do not place competing interactive controls inside the disclosure trigger. If content is essential to completing a task, make its availability clear instead of hiding it behind vague wording. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/ ## Accessible accordions: Examples and Testing https://whatisada.com/patterns/accordions Updated: 2026-09-11 An accordion organizes related expandable sections. Each section needs a descriptive heading and a keyboard-operable trigger whose expanded state matches its panel. Choose deliberately whether several sections may remain open. Example: A policy page groups Returns, Delivery and Repairs. Visitors can expand the relevant section, compare two sections and reach links inside open panels without traversing controls in collapsed ones. Checks: 1. Use Tab to reach each header and Enter or Space to open it. 2. Verify heading levels, expanded states and trigger-to-panel relationships. 3. Move through the open panel's controls, collapse it and confirm that hidden content leaves the focus order. Limitations: An accordion is not a tablist. Arrow-key shortcuts can be an optional enhancement, but they do not replace normal Tab access or the Enter/Space activation contract. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/accordion/ ## Accessible modal dialogs: Examples and Testing https://whatisada.com/patterns/modal-dialogs Updated: 2026-09-11 A modal dialog temporarily makes the rest of the page unavailable while the user completes a focused task. Use native dialog with showModal where suitable, supply a visible title and plan opening, closing and focus restoration. Example: An audit planner opens a dialog to name a saved scope. Focus enters the dialog, background controls are unavailable, Escape or Cancel closes it, and focus returns to the button that opened it. Checks: 1. Open the dialog by keyboard and check its name and initial focus. 2. Cycle with Tab and Shift+Tab, checking that the background is inert and all dialog actions are reachable. 3. Close through every supported route and verify logical focus restoration and preserved page state. Limitations: aria-modal does not itself block background interaction. Do not hide the dialog inside an aria-hidden ancestor or force a long structured description into a single announcement. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/ ## Accessible confirmation dialogs: Examples and Testing https://whatisada.com/patterns/alert-dialogs Updated: 2026-09-11 Use an alert dialog for a brief, important interruption that requires a response, such as confirming a consequential deletion. Describe the consequence clearly and make the safe path easy to identify and operate. Example: Deleting a saved test record opens “Delete this test record?” with a concise statement of what will be removed. Initial focus goes to Cancel when that is the appropriate least-destructive action. Checks: 1. Trigger the confirmation and check that its title, message and actions are announced meaningfully. 2. Verify focus containment, Escape/cancel behavior and clear action labels. 3. Confirm or cancel, then check the actual result and the logical destination for focus. Limitations: A generic “Are you sure?” message may leave the user unable to review the consequence. Use this interruption only when it helps prevent an actual error. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/ ## Accessible tab interfaces: Examples and Testing https://whatisada.com/patterns/tabs Updated: 2026-09-11 Tabs switch among associated panels within a single interface. Implement a coherent tablist, selected tab and panel relationship, with keyboard movement and activation matching the chosen automatic or manual model. Example: A component guide has Example and Code tabs. Arrow keys move between the tabs, the selected state follows the model, and only the active panel is presented as current content. Checks: 1. Enter the tablist with Tab and use arrows, Home and End as supported by the pattern. 2. For manual activation, use Enter or Space and check that focus and selection are distinct until activation. 3. Verify aria-selected, tab/panel associations and access to the active panel's contents. Limitations: Putting role="tab" on several ordinary navigation buttons does not implement tabs. Slow-loading panels usually need manual activation to avoid a delay on every arrow-key move. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/tabs/ ## Accessible dropdown navigation: Examples and Testing https://whatisada.com/patterns/navigation-disclosures Updated: 2026-09-11 Most website dropdown navigation is a disclosure containing ordinary links, not an application menu. Keep normal link behavior and Tab navigation while making the disclosure's state and closing behavior clear. Example: A Learn button opens links to Guides, WCAG Reference and Glossary. Keyboard users can open it, Tab through the links and close it without having to discover an application-menu key model. Checks: 1. Activate the disclosure and inspect its expanded state and panel visibility. 2. Tab and Shift+Tab through its links and verify Escape returns focus to the trigger when the disclosure is open. 3. Follow a link and check that the menu closes without leaving stale focus or obstructing the destination. Limitations: ARIA menu/menuitem roles imply a different keyboard contract. Avoid those roles for ordinary site navigation unless you actually implement and need that model. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/ ## Accessible breadcrumbs: Examples and Testing https://whatisada.com/patterns/breadcrumbs Updated: 2026-09-11 Breadcrumbs communicate a page's location within a site hierarchy. Use a labeled navigation region, meaningful parent links and a clearly identified current page; separators should not obscure the names. Example: A detailed reference shows Home → WCAG Reference → Keyboard. A visitor arriving directly can navigate to the reference collection without relying on browser history. Checks: 1. Read the breadcrumb as a navigation region and inspect the sequence of parent links. 2. Check that the final item identifies the current page and that separators are not announced as confusing content. 3. Follow each parent link and verify that it reflects the real hierarchy. Limitations: Breadcrumbs describe structure rather than the user's exact navigation history. Structured data should describe the same hierarchy the visitor can see. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/breadcrumb/ ## Accessible pagination: Examples and Testing https://whatisada.com/patterns/pagination Updated: 2026-09-11 Pagination needs understandable page links, a current-page indication and predictable behavior when results change. Use real destinations when pages have URLs and explain previous/next actions in the context of the results. Example: A resource list has links for pages 1, 2 and 3, with page 2 marked current. Previous and Next use meaningful destinations and do not appear operable when no previous or next page exists. Checks: 1. Navigate the pagination by keyboard and read the name of each page action. 2. Check the current-page state and the start/end boundaries. 3. Move to a different results page and verify its URL, title, results count and focus behavior for the chosen navigation model. Limitations: Tiny unlabeled dots are difficult targets and poor page names. Client-side result changes should provide a concise update without unexpectedly returning focus to the document body. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/practices/landmark-regions/ ## Accessible skip links: Examples and Testing https://whatisada.com/patterns/skip-links Updated: 2026-09-11 A skip link lets keyboard users bypass repeated navigation and reach the page's main task. Put it early in the focus order, make it visible when focused and verify the actual focus destination. Example: A long service menu precedes every guide. “Skip to main content” appears on first Tab and moves the user past the menu to the article, so the next keyboard action continues there. Checks: 1. Start at the document and press Tab to find the skip link. 2. Activate it and inspect both scroll position and the active or subsequent focus destination. 3. Repeat on different templates and with a sticky header that could cover the target. Limitations: Scrolling alone may not produce a reliable keyboard jump in every implementation. The target must exist exactly once and should not be hidden under fixed page furniture. Sources: - Primary implementation guidance: https://www.w3.org/WAI/WCAG22/Techniques/general/G1 ## Accessible page landmarks: Examples and Testing https://whatisada.com/patterns/landmarks Updated: 2026-09-11 Landmarks identify major page regions such as navigation, main content, search and the footer. Prefer native elements and give repeated regions distinct names when the user needs to tell them apart. Example: A documentation page has primary navigation, article content and a separate “Related guides” navigation region. Useful names help a screen-reader user choose the intended region directly. Checks: 1. List landmarks through a screen reader or inspect the accessibility tree. 2. Check for one clear main content region and appropriately identified repeated navigation regions. 3. Compare the landmark order with the visual and reading order and remove redundant wrapper landmarks. Limitations: More regions do not always mean better navigation. Do not label every card as a landmark or add redundant roles to native elements without a specific compatibility reason. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/practices/landmark-regions/ ## Accessible heading structures: Examples and Testing https://whatisada.com/patterns/headings Updated: 2026-09-11 Use heading elements to express the content's hierarchy, and write headings that describe their sections. Choose heading levels from the document structure rather than the desired font size. Example: A guide has an H1 title, H2 sections for Preparation and Testing, and H3 steps within Testing. A sidebar uses an appropriate separate heading without turning every small label into a heading. Checks: 1. Read the heading outline independently of the paragraphs. 2. Inspect the semantic levels and whether they represent the intended parent/child relationships. 3. Navigate by heading with a screen reader and check whether someone can locate a specific task efficiently. Limitations: A visually large paragraph is not a heading, and an H4 chosen only for its smaller style may misrepresent the hierarchy. A skipped level is a signal to inspect meaning, not a substitute for judgment. Sources: - Primary implementation guidance: https://www.w3.org/WAI/tutorials/page-structure/headings/ ## Accessible data tables: Examples and Testing https://whatisada.com/patterns/data-tables Updated: 2026-09-11 Use a table when cells have meaningful row and column relationships. Identify the table's subject and associate data with its headers; complex tables need careful explicit relationships or simplification. Example: A comparison table lists audit tasks by owner and due date. Column headers and row headers let someone understand “September 20” as the due date for a specific task rather than an isolated value. Checks: 1. Read the caption or surrounding introduction and identify the table's purpose. 2. Inspect header cells and associations, then navigate representative data cells with a screen reader. 3. At narrow widths, keep any necessary table scrolling inside its own region while surrounding text reflows. Limitations: Do not use tables purely for page layout. A visual bold row is not a header association, and a complicated merged layout may be clearer as several simpler tables. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/table/ ## Accessible sortable tables: Examples and Testing https://whatisada.com/patterns/sortable-tables Updated: 2026-09-11 A sortable table retains its table structure while exposing sorting as an action in the relevant header. Indicate the active sort direction and update the result without losing the user's place. Example: An issue table can sort by Priority or Page. A button in the Priority header applies the sort, aria-sort identifies the current direction on that header, and a short message reports the change. Checks: 1. Reach each sortable header button and activate it with keyboard input. 2. Check aria-sort on the actively sorted column and compare the actual row ordering. 3. Verify that focus remains usable and that repeated sorting does not rebuild the table in a way that loses the user's context. Limitations: An arrow icon alone does not communicate the sorting state to everyone. Apply aria-sort to the appropriate header rather than every column, and do not use grid semantics unless the table needs that interaction model. Sources: - Primary implementation guidance: https://www.w3.org/WAI/ARIA/apg/patterns/table/ ## Run a First NVDA Website Review https://whatisada.com/workflows/nvda-first-pass Updated: 2026-09-11 Use NVDA on Windows to inspect the structure and basic interaction of a representative page. Record the NVDA, browser and Windows versions, the starting URL and the page state before testing. This is a focused screen-reader pass to complement visual and keyboard checks. Example: On a service page, find eligibility information by heading, inspect the available links, then open the application form without using the mouse. Checks: 1. Start NVDA, load the page, and read its title and opening content. Note unexpected announcements or repeated navigation before the main content. 2. Use NVDA's heading, landmark and link navigation to locate the service instructions. Compare the announced structure with the intended content hierarchy. 3. Tab through controls, activate a link, and record whether the next page is identifiable. Save the exact announcement and reproduction steps for each barrier. Limitations: A successful read-through does not test every state or establish accessibility for other screen readers. Browse mode and focus mode serve different tasks; record a mode change when it affects the result. Sources: - Primary workflow guidance: https://download.nvaccess.org/documentation/userGuide.html - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 2.4.2: Page Titled: https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html ## Test Form Labels and Errors with NVDA https://whatisada.com/workflows/nvda-forms Updated: 2026-09-11 Review a form in NVDA from initial instructions through error recovery. Use fictional information and a test endpoint. The useful result is a record of names, requirements, validation feedback and whether the user can complete the task. Example: A permit form asks for an email address and a permit type. Submit it once empty and once with a malformed address before testing a valid submission. Checks: 1. Read the instructions in browse mode, then navigate into each form control. Record the announced label, type, required state and any description. 2. Enter deliberately invalid test data and submit. Check where focus lands and whether errors identify both the problem and the field needing correction. 3. Correct the fields without losing valid information. Confirm the success message is announced and does not require searching the entire page. Limitations: Reading only the labels misses conditional questions, disabled states, error summaries and completion feedback. Browser-native validation and custom validation may announce differently. Sources: - Primary workflow guidance: https://download.nvaccess.org/documentation/userGuide.html - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html ## Review Data Tables with NVDA https://whatisada.com/workflows/nvda-tables Updated: 2026-09-11 Evaluate whether someone can understand a data value together with its row and column context. Select a table containing real relationships, including any totals or grouped headers, and record its title and location. Example: In a monthly expense table, identify the March travel total without visually following the column borders. Checks: 1. Navigate to the table with NVDA and listen for its name and dimensions. Check whether the table describes data rather than page layout. 2. Move through cells using NVDA table navigation. Record the row and column headers announced for values in the first, middle and final rows. 3. Test merged headers, sorting controls and pagination if present. Verify that updated rows retain their associations after interaction. Limitations: A visually aligned table can still have missing or incorrect header relationships. Do not accept a single correctly announced cell as evidence for a complex table. Sources: - Primary workflow guidance: https://download.nvaccess.org/documentation/userGuide.html - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 4.1.2: Name, Role, Value: https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html ## Review a Website with VoiceOver and Safari https://whatisada.com/workflows/voiceover-safari-first-pass Updated: 2026-09-11 Use VoiceOver on macOS with Safari to review page structure, control names and a short task. Record the browser, operating system, VoiceOver settings and whether keyboard navigation is enabled for the controls being tested. Example: Find a help article through the navigation, expand its related questions, then follow a contact link. Checks: 1. Enable VoiceOver and inspect the page title and main content. Use the rotor to compare available headings, links and landmarks with the intended organization. 2. Navigate through the chosen task using VoiceOver commands. Check the names and states of collapsed sections, buttons and form fields. 3. Activate an internal route or dialog and verify the new context is announced. Record the spoken output and the control that should receive focus. Limitations: Safari keyboard preferences can affect ordinary Tab navigation. Keep that configuration in the evidence so a browser preference is not confused with a site defect. Sources: - Primary workflow guidance: https://support.apple.com/guide/voiceover/welcome/mac - WCAG 2.4.3: Focus Order: https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html - WCAG 2.4.6: Headings and Labels: https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels.html ## Test a Mobile Web Journey with iOS VoiceOver https://whatisada.com/workflows/voiceover-ios-mobile Updated: 2026-09-11 Test the actual mobile page with VoiceOver on an iPhone or iPad. Record device, iOS version, browser, orientation and the journey. Include the on-screen keyboard and overlays that do not appear in desktop layouts. Example: Choose an appointment time, enter contact details and review the booking summary on a narrow screen. Checks: 1. Navigate sequentially by swiping and separately by exploring the screen. Confirm that the same essential controls can be found in a meaningful order. 2. Open the mobile menu and any date or time selector. Check expanded state, dismissal and whether hidden background content remains exposed unexpectedly. 3. Enter sample data with the on-screen keyboard, trigger an error and complete the review step. Note content covered by the keyboard or a sticky action bar. Limitations: Desktop emulation does not reproduce VoiceOver touch navigation or the software keyboard. A mobile viewport screenshot is insufficient evidence for this workflow. Sources: - Primary workflow guidance: https://support.apple.com/guide/iphone/turn-on-and-practice-voiceover-iph3e2e415f/ios - WCAG 1.3.2: Meaningful Sequence: https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html - WCAG 2.4.3: Focus Order: https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html ## Review an Android Website with TalkBack https://whatisada.com/workflows/talkback-android Updated: 2026-09-11 Use TalkBack on an Android device to test names, reading order and actions on a mobile web page. Record the device, Android, TalkBack and browser versions, since gestures and support may differ between configurations. Example: Locate a product, open its options, select a size and inspect the cart without relying on visual labels alone. Checks: 1. Read the page sequentially with TalkBack and compare the spoken order with the intended task sequence. 2. Explore the product options and cart controls by touch. Confirm labels distinguish repeated actions and selected states are announced. 3. Change orientation where supported, open and dismiss overlays, and check that focus returns to a useful place. Record the exact state preceding a failure. Limitations: A control may respond to a touch exploration gesture while remaining unreachable in sequential navigation. Test both ways of locating important actions. Sources: - Primary workflow guidance: https://support.google.com/accessibility/android/answer/6283677 - WCAG 1.3.2: Meaningful Sequence: https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html - WCAG 2.5.3: Label in Name: https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html ## Test Checkout Announcements with JAWS https://whatisada.com/workflows/jaws-checkout Updated: 2026-09-11 Review a checkout using JAWS in a documented Windows and browser configuration. Work in a sandbox with fictional customer and payment data. Follow one complete purchase path, including a recoverable error and a review stage. Example: A test shopper changes quantity, adds a delivery address and corrects a missing postal code before confirming an order in the sandbox. Checks: 1. Identify product names, quantities and prices using JAWS navigation. Change a quantity and check how the updated total is announced. 2. Move through delivery and payment controls, including any embedded payment frame. Verify that names, requirements and errors remain understandable across those boundaries. 3. Review the final items, amount and destination. Test the available correction mechanism and record the completion announcement without recording sensitive payment data. Limitations: A payment provider can introduce a barrier outside the merchant's theme. Record the provider and frame alongside the reproduction steps so the issue reaches the correct owner. Sources: - Primary workflow guidance: https://www.freedomscientific.com/training/jaws/ - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html - WCAG 3.3.4: Error Prevention (Legal, Financial, Data): https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html ## Test Visible Labels with Speech Input https://whatisada.com/workflows/speech-input-controls Updated: 2026-09-11 Check whether a person using speech input can activate controls by saying the labels they see. Record the speech product, language and browser. Include repeated buttons, icon controls and a dialog where labels change. Example: A user says the visible words “Add to cart” and “Continue to delivery” instead of using a pointing device. Checks: 1. List the visible labels of the task's primary controls. Compare each with its accessible name, including any hidden text or ARIA naming. 2. Use the speech tool to activate those controls by their visible names. Record ambiguous matches and controls that require a different spoken phrase. 3. Repeat inside a dialog and after a state change. Confirm that visible names remain useful and that a numbering overlay is a fallback rather than the only practical path. Limitations: A descriptive hidden label can accidentally replace the visible words. More text is not automatically better if it makes speech commands unpredictable. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html - WCAG 4.1.2: Name, Role, Value: https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html ## Review Sequential Navigation with Switch Control https://whatisada.com/workflows/switch-input-navigation Updated: 2026-09-11 Evaluate whether the essential task can be completed using a switch access system's sequential selection. Record the device, scanning mode and switch settings. Plan enough time to test slow navigation and cancellation as well as activation. Example: A visitor scans through a registration form and selects a session without dragging a calendar item or racing a short timeout. Checks: 1. Choose a supported switch configuration and document how it moves and selects. Locate the page's first useful task control. 2. Complete the task through sequential selection. Note excessive repeated navigation, unreachable controls and actions requiring simultaneous or complex gestures. 3. Pause during input, reopen a menu and cancel an action. Check whether time limits and focus changes erase progress or strand the user. Limitations: Keyboard success is useful evidence but does not replace testing the selected switch setup. Scanning speed and repeated controls can make an otherwise reachable journey impractical. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 2.1.2: No Keyboard Trap: https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html ## Run a Keyboard-Only End-to-End Test https://whatisada.com/workflows/keyboard-only-full-flow Updated: 2026-09-11 Review one complete process without a mouse, from entry to confirmation. Keep a visible focus indicator and use the expected keys for each control type. Record each unreachable action or unexpected focus movement as a separate observation. Example: Register for an event, choose a ticket type, correct an invalid email and reach a test confirmation. Checks: 1. Reload the starting page and use Tab and Shift+Tab to inspect focus order. Try the skip link and check whether focus is visible near sticky headers. 2. Operate menus, radios, selects and dialogs using their appropriate keys. Check that every task action is reachable and that no component traps focus unintentionally. 3. Trigger validation, move between steps and cancel or finish the process. Record where focus goes after each large content change. Limitations: Tab is not the expected navigation key inside every composite widget. A test should distinguish a missing interaction from an unfamiliar but documented keyboard pattern. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 2.1.2: No Keyboard Trap: https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html ## Choose an Image Alternative by Purpose https://whatisada.com/workflows/alt-text-decision-review Updated: 2026-09-11 Decide what an image contributes in its specific context before writing alt text. Distinguish informative images, functional images, text images, complex graphics and decoration. Record the reason for the decision so future editors can maintain it. Example: The same arrow graphic is decorative beside a text link in one place and the only content of a Next button in another. Checks: 1. Read the surrounding content and identify information or function that would be lost without the image. Check whether nearby text already supplies it. 2. Choose an alternative that preserves that purpose. Use a concise functional name for an image-only control and an empty alternative for genuine decoration. 3. Review the page with images unavailable and with a screen reader. Check for missing meaning, duplicated phrases and unnecessary descriptions of decoration. Limitations: A description of appearance is not always the right alternative. The arrow button needs its action named, not a detailed account of the arrow's shape. Sources: - Primary workflow guidance: https://www.w3.org/WAI/tutorials/images/decision-tree/ - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html - WCAG 2.4.4: Link Purpose (In Context): https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html ## Create a Text Alternative for a Data Chart https://whatisada.com/workflows/chart-text-alternative Updated: 2026-09-11 Make the chart's message and relevant data available without requiring visual interpretation. Start with the decision the chart supports and preserve relationships such as trends, categories and units. Keep the alternative synchronized with the chart's data. Example: A line chart compares three service wait times and highlights a sharp increase in one category. Checks: 1. Write a short identification of the chart and its main point. Identify which values or relationships readers need to verify the conclusion. 2. Provide a nearby structured explanation, data table or accessible detailed description. Include labels, units and important changes without relying on color names alone. 3. Compare the alternative against the chart and underlying data. Test the route to the detailed information with the keyboard and assistive technology. Limitations: A table of numbers may preserve the data while omitting the chart's intended conclusion. A good alternative often needs both a concise interpretation and access to detail. Sources: - Primary workflow guidance: https://www.w3.org/WAI/tutorials/images/complex/ - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html - WCAG 1.4.1: Use of Color: https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html ## Audit Link Text and Destination Clarity https://whatisada.com/workflows/link-text-audit Updated: 2026-09-11 Review whether readers can determine where links lead from their text and available context. Include repeated cards, document downloads and icon-only links. Record the actual destination before rewriting labels. Example: A resource list repeats “Read more” beneath several articles and uses an unnamed icon for PDF downloads. Checks: 1. Collect the links in a representative page or template and inspect their text, context and destinations. Identify identical labels leading to different purposes. 2. Rewrite unclear labels or improve their programmatically associated context. Give image-only links an appropriate accessible name and identify useful file information where needed. 3. Review the links in context and through a screen reader's link navigation. Confirm that revised names remain concise and match visible wording used for speech input. Limitations: Making every link excessively long can create new friction. Keep the label focused on destination or action, with supporting detail in a useful adjacent context. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html - WCAG 2.5.3: Label in Name: https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html ## Audit a Page's Heading Outline https://whatisada.com/workflows/heading-outline-audit Updated: 2026-09-11 Compare the visible sections of a page with its semantic heading structure. Look for useful navigation and meaningful relationships instead of treating heading numbers as a styling system. Record template-generated headings as well as editor content. Example: An article has a clear title but its sidebar labels are headings while the actual section titles are plain bold paragraphs. Checks: 1. List the intended sections and inspect the rendered heading outline. Identify missing section headings, misleading headings and relationships that are not represented clearly. 2. Apply semantic headings to the actual section labels and choose levels that reflect their hierarchy. Adjust styles separately from the structure. 3. Navigate the page by headings with assistive technology. Confirm that each heading describes the content that follows and that repeated template content is understandable. Limitations: An automated skipped-level warning is a prompt for review, not the entire assessment. The main question is whether the structure and relationships are conveyed accurately. Sources: - Primary workflow guidance: https://www.w3.org/WAI/tutorials/page-structure/headings/ - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 2.4.6: Headings and Labels: https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels.html ## Audit Page and Passage Language Markup https://whatisada.com/workflows/page-language-audit Updated: 2026-09-11 Review the language identified for the page and for meaningful passages in another language. Include translated routes, embedded quotations and forms. Correct language markup helps assistive technology choose appropriate pronunciation rules. Example: An English article contains a French quotation and links to a separately translated French version. Checks: 1. Inspect the page's primary language declaration and compare it with the actual content. Check each translated route rather than assuming the template changes correctly. 2. Identify passages requiring a language change and apply appropriate markup. Consider the criterion's exceptions for names, technical terms and similar cases. 3. Listen to representative passages with a screen reader configured for the relevant languages. Verify that navigation and forms on translated pages use the intended language as well. Limitations: A language switcher alone does not set the document language. Automatic translation can also leave labels or validation messages in a different language from the main content. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/language-of-parts.html - WCAG 3.1.1: Language of Page: https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html ## Write Clear Instructions for a Complex Form https://whatisada.com/workflows/plain-language-form-instructions Updated: 2026-09-11 Explain what people need to provide before they encounter an error. Keep instructions close to the relevant decision and connect them programmatically where appropriate. Separate necessary requirements from internal implementation details. Example: A reimbursement form asks for a receipt date, an amount and evidence but does not explain accepted files or currency. Checks: 1. List the information users need before starting: documents, formats, required answers and any meaningful limits. Remove unexplained internal terminology. 2. Write concise field-level instructions and examples where the format is not obvious. Make required and optional choices clear without relying only on an asterisk or color. 3. Test the instructions with representative invalid entries. Check that error messages add a specific correction and do not contradict the original guidance. Limitations: Long instructions can be ignored when every field repeats the same warning. Put general information once and use local guidance for the decisions that need it. Sources: - Primary workflow guidance: https://www.w3.org/WAI/tutorials/forms/instructions/ - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html - WCAG 3.3.3: Error Suggestion: https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html ## Review a Marketing or Service Email for Accessibility https://whatisada.com/workflows/accessible-email-review Updated: 2026-09-11 Test the actual sent email in representative clients, including its text, links, images and reading order. Email rendering differs from a web page, so keep client and device details in the evidence. Use a test list rather than a live audience. Example: A service notice contains a banner, an important deadline and a button linking to an account action. Checks: 1. Check that essential information is real text and that images have useful alternatives or are appropriately decorative. Review headings, link names and any layout tables in the rendered email. 2. Read the test email with images disabled and with assistive technology. Verify that the message and primary action remain understandable in a sensible sequence. 3. Review text enlargement, contrast and the destination page. Confirm that the test copy has no accidental live-recipient data and that the plain-text alternative is useful where provided. Limitations: An accessible web preview does not prove the email client preserves the same structure. Image-only promotional text can disappear when remote images are blocked. Sources: - Primary workflow guidance: https://www.w3.org/WAI/tips/writing/ - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html - WCAG 2.4.4: Link Purpose (In Context): https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html ## Review Social Images, Captions and Link Context https://whatisada.com/workflows/accessible-social-post-review Updated: 2026-09-11 Prepare social content so its message remains available beyond the visual asset. Use the platform's current alternative-text and caption features, and verify the published result. Keep important instructions in the post text or an accessible destination. Example: An event announcement uses a graphic with the date, venue and registration link while a short video explains the agenda. Checks: 1. Identify all essential information in the graphic or video. Put key event details in ordinary post text and add a purposeful image alternative using the platform's supported feature. 2. Review video captions for accuracy, timing and meaningful sounds. Avoid relying on automatic output without checking names, dates and instructions. 3. Inspect the post after publication or in an appropriate test preview. Check link context, image alternatives and captions on the platform and device users will encounter. Limitations: Accessibility features vary by platform and post type. An alternative entered during composition may be lost when content is cross-posted or converted to another format. Sources: - Primary workflow guidance: https://www.w3.org/WAI/tips/writing/ - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html - WCAG 1.2.2: Captions (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded.html ## Repair Heading Structure in Word https://whatisada.com/workflows/word-heading-structure Updated: 2026-09-11 Make the document's visible sections available as a navigable heading hierarchy. Work in the editable Word source and record the application version. Distinguish the document title, major sections and subordinate topics before changing styles. Example: A policy uses large bold paragraphs as section labels but offers no useful heading navigation. Checks: 1. Outline the policy's sections in order and identify which paragraphs actually introduce content. Apply the appropriate built-in heading styles to those paragraphs. 2. Inspect the navigation outline and move between sections with a screen reader. Check that heading text describes the section and nesting reflects the document's relationships. 3. Adjust the styles for the intended visual design, then export a test PDF if that is the distribution format. Verify that the heading structure survives export. Limitations: Changing a font size does not create a semantic heading. Conversely, applying a heading style to decorative text adds misleading navigation entries. Sources: - Primary workflow guidance: https://support.microsoft.com/en-us/accessibility/word/make-your-word-documents-accessible-to-people-with-disabilities - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 2.4.6: Headings and Labels: https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels.html ## Review Data Table Structure in Word https://whatisada.com/workflows/word-data-tables Updated: 2026-09-11 Inspect tables as relationships between headers and values rather than as visual grids. Prefer a simple structure and repair the source before PDF export. Record tables that require a specialist review because of multi-level or merged headers. Example: A fee schedule has a service column, a standard fee column and a reduced fee column, with a separate total beneath it. Checks: 1. Confirm that the table is needed for data and identify each header. Remove layout-only tables or replace them with ordinary structured content where practical. 2. Set and verify the header structure in Word. Review merged cells, blank spacer rows and information encoded only by shading. 3. Navigate the table with a screen reader and inspect the exported PDF's table structure. Record values whose row or column context is unclear. Limitations: A bold first row may look like a header without providing a reliable programmatic association. Export can also change the structure, so test the distributed file. Sources: - Primary workflow guidance: https://support.microsoft.com/en-us/accessibility/word/make-your-word-documents-accessible-to-people-with-disabilities - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html ## Write Useful Image Alternatives in Word https://whatisada.com/workflows/word-image-alternatives Updated: 2026-09-11 Review each image in its document context and decide whether it conveys information, performs a function or is decorative. Keep short alternatives focused on purpose and place longer explanations in the document body. Example: A report includes a decorative cover photograph and a chart that shows which costs increased over the year. Checks: 1. Inventory the images and write the information each contributes beyond nearby text. Mark purely decorative images appropriately and avoid repeating adjacent captions without adding meaning. 2. Add concise alternatives for informative images. For a complex chart, provide its key message and a structured explanation or data table in the document. 3. Read the surrounding text and alternative together with a screen reader. Check the exported version so the alternative remains associated with the correct figure. Limitations: Automatically generated descriptions may identify objects while missing the report's message. A detailed chart usually needs more than a long string in one alternative-text field. Sources: - Primary workflow guidance: https://support.microsoft.com/en-us/accessibility/word/make-your-word-documents-accessible-to-everyone-with-accessibility-assistant - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html ## Export and Verify a Tagged PDF from Word https://whatisada.com/workflows/word-accessible-pdf-export Updated: 2026-09-11 Treat PDF export as a separate quality checkpoint after repairing the Word source. Record the source version and export settings so future updates can reproduce the result. Verify the PDF users will actually receive. Example: A structured application guide is exported for download after its headings, links and figures have been reviewed in Word. Checks: 1. Run Word's accessibility review and resolve source problems that affect structure or alternatives. Save the editable source as the maintained master. 2. Use an export or save option that preserves accessibility tags for your Word version. Record the selected settings rather than relying on a print-to-PDF workflow. 3. Open the resulting PDF and inspect tags, reading order, links, language and image alternatives. Test a representative reading and navigation task with assistive technology. Limitations: A tagged export can still contain incorrect structure. Fix recurring problems in the source or export process so the next edition does not silently restore them. Sources: - Primary workflow guidance: https://learn.microsoft.com/en-us/office/pdf/word/wordpdfaccessibility - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 1.3.2: Meaningful Sequence: https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html ## Review PowerPoint Slide Reading Order https://whatisada.com/workflows/powerpoint-reading-order Updated: 2026-09-11 Check the sequence in which slide objects are presented to a screen reader. Record the PowerPoint version and inspect each distinct slide layout, including slides that depart from the template. Reading order should follow the explanation rather than object creation order. Example: A slide contains a title, a diagram and three callouts that were added after the footer. Checks: 1. Inspect the slide's reading order using the tools available in your PowerPoint version. Identify the intended title, explanation and supporting objects. 2. Reorder meaningful objects and mark decoration appropriately. Check that grouped diagrams have a useful explanation without unnecessary repetition of individual decorative parts. 3. Read the slide with a screen reader and inspect the visual layout after changes. Repeat for the distributed presentation or PDF because export can alter the result. Limitations: Fixing one slide master does not repair every custom slide. Objects copied from another deck can bring a different order or lose their intended relationship. Sources: - Primary workflow guidance: https://support.microsoft.com/en-us/powerpoint/make-slides-easier-to-read-by-using-the-reading-order-pane - WCAG 1.3.2: Meaningful Sequence: https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html ## Add and Check Captions in PowerPoint Media https://whatisada.com/workflows/powerpoint-video-captions Updated: 2026-09-11 Provide and verify captions for meaningful audio in presentation media. Check the exact PowerPoint version and the way the deck will be delivered, because embedded media, online video and exported files can behave differently. Example: A training deck includes a recorded demonstration that participants may watch without audio. Checks: 1. Identify the media type and prepare a reviewed caption file or an appropriately captioned source. Include relevant speaker identification and meaningful sounds. 2. Use the caption support available for that media and PowerPoint version. Play the slide show and verify that users can enable the captions. 3. Check timing, technical terms and legibility, then test the actual shared deck or exported recording. Record any format in which the captions are lost. Limitations: Live presentation subtitles and prerecorded video captions solve different problems. Captions visible on the author's computer may not be included in every exported format. Sources: - Primary workflow guidance: https://support.microsoft.com/en-us/PowerPoint/add-closed-captions-or-subtitles-to-media-in-powerpoint - WCAG 1.2.2: Captions (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded.html ## Prepare an Accessible Excel Data Workbook https://whatisada.com/workflows/excel-accessible-data Updated: 2026-09-11 Organize a workbook so a reader can identify sheets, locate tables and interpret values without relying on color or visual position. Keep formulas and data intact while reviewing the structure. Record the workbook version and intended audience task. Example: A budget workbook has three unnamed sheets, color-coded variance cells and a chart with no accompanying explanation. Checks: 1. Give worksheets descriptive names and provide a short orientation near the start of each relevant sheet. Identify actual data tables and their headers. 2. Review merged cells, blank separators and color-only meaning. Add textual labels for status and a useful explanation or underlying data for charts. 3. Run the available accessibility checker and complete a screen-reader task such as finding a department total. Record any navigation or interpretation problem that the checker did not flag. Limitations: A workbook can pass automated checks while remaining hard to navigate. Protecting sheets or hiding rows can also change the experience of the distributed copy. Sources: - Primary workflow guidance: https://support.microsoft.com/en-US/Accessibility/excel/accessibility-best-practices-with-excel-spreadsheets - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 1.4.1: Use of Color: https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html ## Inspect and Repair a PDF Tag Tree https://whatisada.com/workflows/pdf-tag-structure Updated: 2026-09-11 Review whether PDF tags represent the document's actual structure. Save a working copy before editing and identify whether a source-file repair would be more maintainable. Tag presence alone is not evidence that headings, lists and figures are correct. Example: A report's tag tree contains a long sequence of paragraphs even though the visible document has sections, lists and figures. Checks: 1. Compare the tag tree with the document's intended outline. Identify missing content, incorrect element types and decorative material exposed as meaningful content. 2. Repair a small section and verify the content associated with each tag. Preserve relationships such as list labels and bodies rather than treating every object as an isolated paragraph. 3. Run a PDF accessibility check and read the repaired section with assistive technology. Save evidence of both the structure and the resulting reading experience. Limitations: Automatic tagging is a starting point for review. Re-tagging an already repaired file can undo deliberate structure, so keep a versioned source and repair record. Sources: - Primary workflow guidance: https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html ## Verify PDF Reading Order Across Columns https://whatisada.com/workflows/pdf-reading-order Updated: 2026-09-11 Check that meaningful content is read in an order that preserves the document's explanation. Include multi-column pages, sidebars, footnotes and figures. Record the viewer and assistive technology used because different views can expose different problems. Example: A newsletter has two columns and a sidebar; the intended article should not alternate between unrelated lines in both columns. Checks: 1. Identify the intended reading sequence on a representative page. Compare the PDF's logical structure and reading-order tools with that sequence. 2. Read the page with a screen reader, including transitions between columns and pages. Note text repeated, omitted or inserted in the wrong context. 3. Repair the appropriate structure in the source or PDF, then retest the surrounding pages. Confirm that the visual appearance and links still work. Limitations: The visual order overlay and the tag tree are related but not interchangeable evidence. A correct-looking numbered overlay does not replace testing actual reading behavior. Sources: - Primary workflow guidance: https://helpx.adobe.com/acrobat/using/touch-reading-order-tool-pdfs.html - WCAG 1.3.2: Meaningful Sequence: https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html ## Check PDF Table Headers and Cell Relationships https://whatisada.com/workflows/pdf-table-headers Updated: 2026-09-11 Inspect a PDF table at the cell and header-association level. Work from a copy and determine whether the original authoring file can produce a simpler, more reliable table. Complex headers often need manual review. Example: A report table groups quarterly values under year headers and includes row labels for several service areas. Checks: 1. Identify the row and column context required to interpret each value. Inspect the table, row, header and data-cell structure in the PDF tags. 2. Check header scope or explicit associations where appropriate, including spans across rows or columns. Confirm that every meaningful cell belongs to the correct table. 3. Navigate representative cells with a screen reader, especially at group boundaries and totals. Record the expected and announced headers for any mismatch. Limitations: A checker may detect missing table structure without proving all associations are correct. Do not flatten a complex data table into an image to remove a warning. Sources: - Primary workflow guidance: https://helpx.adobe.com/acrobat/using/touch-reading-order-tool-pdfs.html - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html ## Review OCR Before Remediating a Scanned PDF https://whatisada.com/workflows/scanned-pdf-ocr Updated: 2026-09-11 Convert an image-only document into accurate machine-readable text before building its accessible structure. Preserve the original scan and use a working copy. OCR accuracy and document accessibility are separate checkpoints. Example: A scanned application contains names, dates and a table of fees that must be read precisely. Checks: 1. Run OCR using the correct document language and inspect its output against the scan. Pay particular attention to numbers, punctuation, columns and poor-quality pages. 2. Correct recognition errors and identify meaningful headings, lists, tables and figures. Add or repair tags and reading order after the text is reliable. 3. Search for key terms, copy representative text and read the final document with assistive technology. Record uncertain passages requiring human verification. Limitations: Searchable text alone does not create a usable tagged PDF. An OCR error in a fee or deadline can remain hidden behind a visually correct scan. Sources: - Primary workflow guidance: https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html ## Test Fillable PDF Form Fields https://whatisada.com/workflows/pdf-form-fields Updated: 2026-09-11 Review a fillable PDF through instructions, field entry, validation and saving. Use fictional data and the viewers users are expected to use. Check whether an HTML form would provide a more maintainable route for the same task. Example: An intake PDF has checkboxes, a date field and a signature instruction spread across two pages. Checks: 1. Tab through the form and record field names, types and order. Check that instructions and required information are available without relying on visual placement. 2. Enter test values, select options and trigger any supported validation. Verify that errors and format expectations can be understood with assistive technology. 3. Save, close and reopen the completed test file. Confirm that values remain available and that submission or printing instructions are clear. Limitations: A visible text label does not necessarily become the field's accessible name. Support for validation and submission can differ substantially between PDF viewers. Sources: - Primary workflow guidance: https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html - WCAG 2.4.3: Focus Order: https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html ## Review Links and Bookmarks in a PDF https://whatisada.com/workflows/pdf-links-bookmarks Updated: 2026-09-11 Check the document's navigation as a reader would use it: identifying a destination, activating it and understanding the arrival point. Include internal references and external links, especially in long documents. Example: A handbook has a contents page, section bookmarks and repeated links labeled “more.” Checks: 1. List the main navigation routes and compare their labels with the destination sections. Improve vague link text in the source where possible. 2. Inspect whether links are represented correctly in the PDF structure and can be reached and activated with the keyboard. 3. Follow representative contents links, bookmarks and external links. Check that internal destinations land at the intended section and remain correct after repagination. Limitations: A visible underlined URL may be plain text, and a clickable annotation may still have poor structure. Test both identification and activation. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF11 - WCAG 2.4.4: Link Purpose (In Context): https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html - WCAG 2.4.5: Multiple Ways: https://www.w3.org/WAI/WCAG22/Understanding/multiple-ways.html ## Set and Verify PDF Language and Title https://whatisada.com/workflows/pdf-language-title Updated: 2026-09-11 Give a PDF a meaningful document title and the correct primary language, then review language changes within its content. These settings support identification and pronunciation; they do not replace structural remediation. Example: A bilingual welcome pack opens with a file name and reads Spanish passages using the English voice rules. Checks: 1. Set a descriptive document title in the source or PDF properties and verify how the viewer displays it. Avoid relying on an opaque file name. 2. Set the primary language and mark meaningful passages in another language where the format supports it. Check names and loanwords according to the relevant exception. 3. Open the distributed PDF and listen to representative passages. Record the title, language settings and any pronunciation issue that remains. Limitations: A language property does not translate content. Changing the whole document's language to fix one paragraph can make the rest harder to understand. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF16 - WCAG 2.4.2: Page Titled: https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html - WCAG 3.1.1: Language of Page: https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html ## Audit an Ecommerce Purchase Journey https://whatisada.com/workflows/ecommerce-checkout-audit Updated: 2026-09-11 Scope a purchase from product discovery to confirmation, including variants, stock changes and payment-provider boundaries. Use a sandbox and define which purchase routes are representative of the store. Example: A customer selects a size, adds two items, changes delivery and corrects a payment-entry error. Checks: 1. Map the product, cart, delivery, payment and review states. Include empty-cart, unavailable-variant and invalid-discount cases that affect the chosen route. 2. Complete the route with the keyboard and a screen reader. Check names, focus, errors and announcements when quantities, availability or totals change. 3. Review and correct the order before a permitted test confirmation. Record barriers with the step, provider and state so fixes can be assigned accurately. Limitations: Testing only the homepage or product page misses the process that creates the purchase. A successful visual purchase is not evidence for nonvisual completion. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html - WCAG 4.1.3: Status Messages: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html ## Audit an Appointment Booking Journey https://whatisada.com/workflows/appointment-booking-audit Updated: 2026-09-11 Review the booking process from service choice to confirmation and rescheduling information. Include date, time-zone and availability changes. Use a test calendar so the review does not reserve real appointments. Example: A visitor selects a consultation, changes the date after a slot becomes unavailable and confirms contact details. Checks: 1. Map the service, practitioner, calendar, time and contact steps. Identify alternatives to visual calendar navigation and record time-zone information. 2. Select and change dates and times using the keyboard and assistive technology. Check unavailable states, selected values and announcements when availability updates. 3. Trigger a validation error and complete a test booking. Verify that the confirmation names the service, date, time zone and next action clearly. Limitations: An accessible calendar widget does not guarantee an accessible booking process. Slot expiry, time-zone changes and confirmation details need separate checks. Sources: - Primary workflow guidance: https://www.w3.org/WAI/tutorials/forms/multi-page/ - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html ## Audit a Donation Form and Recurring Gift Flow https://whatisada.com/workflows/donation-form-audit Updated: 2026-09-11 Review how a donor selects an amount, frequency and payment route, then understands the commitment. Use a payment sandbox. Include the distinction between one-time and recurring gifts in the test evidence. Example: A donor chooses a custom monthly amount, adds a dedication and reviews any optional fee contribution. Checks: 1. Inspect the amount and frequency controls, including their names and selected states. Verify that a custom amount has clear currency and format instructions. 2. Test dedication fields, optional fee choices and payment errors. Check that changing frequency updates the summary without silently changing unrelated selections. 3. Review the final amount and recurring terms before confirming a sandbox gift. Verify that the completion message and receipt information match the selection. Limitations: A visually emphasized recurring option can be mistaken for a one-time gift if the selected state is unclear. Do not rely on color or position to communicate the commitment. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html ## Audit an Online Job Application Process https://whatisada.com/workflows/job-application-audit Updated: 2026-09-11 Test an application from vacancy discovery through document upload and submission review. Use a test vacancy and fictional applicant details. Include the applicant-tracking system and any external assessment in the scope. Example: An applicant uploads a résumé, corrects a file-format error and resumes a saved application. Checks: 1. Locate the vacancy requirements and application entry point. Identify account creation, attachments, assessment tools and session limits before testing. 2. Complete fields and uploads with the keyboard and assistive technology. Check file requirements, progress, error messages and whether repeated information can be reused. 3. Save and resume the test application, then review it before a permitted submission. Record barriers that could prevent completion before a deadline. Limitations: A contact address for accommodations does not repair an inaccessible application route. Document the immediate alternative and the underlying product issue separately. Sources: - Primary workflow guidance: https://www.w3.org/WAI/tutorials/forms/ - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html - WCAG 3.3.7: Redundant Entry: https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html ## Audit a Student Admissions Application https://whatisada.com/workflows/student-admissions-audit Updated: 2026-09-11 Review an admissions process across program choice, eligibility questions, documents and status tracking. Use a test account and fictional records. Include dependencies between answers so contradictory or stale values are detected. Example: An applicant switches from domestic to international study and receives different document requirements. Checks: 1. Map the branches that change required questions, documents or fees. Record how the application explains those changes. 2. Complete representative branches with the keyboard and a screen reader. Change an earlier answer and verify that later requirements and stored values remain consistent. 3. Test saving, returning, correcting errors and reviewing the application. Check whether the status page explains missing items in text and provides a clear next action. Limitations: A successful default path can hide failures in transfer, international or returning-student branches. Select branches based on meaningful changes in the process. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/redundant-entry.html - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html ## Audit a Library Search and Hold Request https://whatisada.com/workflows/library-catalog-audit Updated: 2026-09-11 Test discovery, filtering, item details and placing a hold as one connected task. Use a test patron account and avoid changing real circulation records. Include availability and format information in the review. Example: A reader finds a large-print edition, checks its branch availability and requests a hold. Checks: 1. Search for a title and apply format and branch filters. Check labels, result counts and whether focus remains useful when results update. 2. Open an item and inspect edition, format and availability details. Verify that status is understandable without relying on icons or color. 3. Place a test hold, change the pickup branch and inspect confirmation or an error. Record any authentication boundary that interrupts the task. Limitations: Search results can look accessible while omitting the edition or availability details needed to choose the correct item. Evaluate the information needed for the decision. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html ## Audit Statement Discovery and Download https://whatisada.com/workflows/bank-statement-accessibility-review Updated: 2026-09-11 Review how an account holder locates, downloads and reads a statement. Use a test account with synthetic financial records. Treat the web interface and the downloaded document as separate parts of the same task. Example: A customer chooses an account and month, downloads a statement and locates a transaction total. Checks: 1. Navigate account and period selectors, checking names, selected values and loading feedback. Verify that download links identify the document and relevant period. 2. Download the test statement and inspect its title, language, text, tags, table structure and reading order. Test finding a particular synthetic transaction. 3. Return to the account interface and try a missing or unavailable statement. Check whether an accessible alternative and a clear next step are offered. Limitations: A tagged PDF is not automatically a usable financial statement. Likewise, an accessible document does not help if its download controls cannot be operated. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 2.4.4: Link Purpose (In Context): https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html ## Audit an Insurance Quote Questionnaire https://whatisada.com/workflows/insurance-quote-accessibility-audit Updated: 2026-09-11 Review a quote journey with changing questions, validation and a final comparison. Use a sandbox with fictional data. Record how answers affect later questions so the result can be checked for internal consistency. Example: A visitor changes the number of drivers and must review a revised set of driver-detail fields. Checks: 1. Map the conditional questions and identify required formats and explanations. Test whether the user can understand a question without relying on an adjacent icon. 2. Complete the form, change earlier answers and trigger representative errors. Verify that hidden stale answers do not distort the quote or block progress. 3. Inspect the comparison and review stage, including coverage differences, amounts and correction controls. Record inaccessible third-party identity or payment steps separately. Limitations: A questionnaire can be keyboard reachable yet produce contradictory results after an answer changes. Include state consistency in the functional and accessibility review. Sources: - Primary workflow guidance: https://www.w3.org/WAI/tutorials/forms/multi-page/ - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html ## Audit a Hotel Booking and Room Selection https://whatisada.com/workflows/hotel-booking-accessibility-audit Updated: 2026-09-11 Review search dates, room selection, rate conditions and reservation review. Use a booking sandbox or stop before any real reservation. Include information about accessibility features when it is part of the customer's decision. Example: A traveler searches two nights, compares room options and checks cancellation terms before reviewing a booking. Checks: 1. Select dates and occupancy with the keyboard and assistive technology. Check unavailable dates, date-format instructions and search-result announcements. 2. Compare room and rate details, including amenities, accessibility information and cancellation conditions. Verify that important differences are available as text. 3. Change a selection and review the total, dates and guest information. Test validation and correction without confirming an unauthorized reservation. Limitations: A room photograph or generic accessibility icon cannot communicate detailed room features. Record whether the booking flow provides the information needed to choose confidently. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html ## Audit Ticket Selection and Seat Booking https://whatisada.com/workflows/event-ticketing-accessibility-audit Updated: 2026-09-11 Review event choice, ticket quantity, seat selection and checkout. Include any visual seating map and its alternative selection method. Work with test inventory so the review does not hold real seats. Example: A customer selects two adjacent seats, changes a ticket type and reviews a timed cart. Checks: 1. Identify the keyboard and nonvisual route for choosing seats or ticket categories. Check labels for section, row, seat, price and availability. 2. Select and change tickets, including accessible seating options where offered. Verify that selection state and cart updates are announced clearly. 3. Test the time warning, extension or recovery path and the final review. Record any step that requires a visual map, dragging or an unreasonably rapid response. Limitations: A textual seat list must expose the information needed to make the same booking decision. A generic “call us” message is not equivalent evidence of a usable online route. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements.html - WCAG 2.2.1: Timing Adjustable: https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html ## Audit a Government Permit Application https://whatisada.com/workflows/government-permit-accessibility-audit Updated: 2026-09-11 Review the permit process across instructions, eligibility, uploads, fees and submission status. Use a test environment and synthetic records. Include documents and external payment services within the chosen process. Example: A resident reads the requirements, uploads a plan and corrects an address before reviewing a fee. Checks: 1. Map each page and document required to complete the permit. Check whether instructions explain accepted formats, prerequisites and expected information before entry. 2. Complete the process with the keyboard and assistive technology. Test upload errors, conditional questions and saving or resuming the application. 3. Review the submission summary and status route. Verify that confirmation identifies what was submitted and how to correct or follow up on a problem. Limitations: Auditing only public information pages misses authenticated forms and required documents. Scope the complete service journey and document any inaccessible dependency. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/conformance.html - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html - WCAG 3.3.4: Error Prevention (Legal, Financial, Data): https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html ## Audit Sign-In and Account Recovery https://whatisada.com/workflows/account-recovery-accessibility-audit Updated: 2026-09-11 Test account access and recovery without relying on memory puzzles or a single sensory channel. Use a dedicated test account and protect recovery codes. Include password managers, paste and alternate authentication routes where supported. Example: A user forgets a password, requests a recovery link and enters a one-time code without retyping it from memory. Checks: 1. Review sign-in fields, labels and password-manager behavior. Check whether pasting credentials or codes is unnecessarily blocked. 2. Follow the recovery route and inspect messages, time limits and any challenge. Evaluate the authentication requirement and its actual exceptions rather than assuming every challenge is prohibited. 3. Complete the test recovery and sign in again. Verify that success, failure and expired-link states explain the next step without exposing sensitive account information. Limitations: A secure authentication design still needs accessible interaction. Record an inaccessible challenge precisely without weakening security controls or publishing recovery secrets. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html ## Build an Inventory of Page Templates and Components https://whatisada.com/workflows/accessibility-template-inventory Updated: 2026-09-11 Create a map of the structures that generate the site before choosing audit pages. Group pages by meaningful differences in layout, interaction and content. Keep the inventory connected to real URLs and owners. Example: A site has thousands of product URLs but only a few product templates, plus a separate checkout, support portal and document archive. Checks: 1. List domains, authenticated areas, templates, reusable components and important content types. Record a representative URL and owner for each. 2. Identify variants such as mobile navigation, empty results, validation, localized content and third-party widgets. Add states that change behavior even when the URL stays the same. 3. Compare the inventory with the sitemap and product journeys. Resolve missing areas and use the completed map to plan representative testing. Limitations: Counting URLs alone overstates repeated templates and understates interactive states. A single URL can contain several materially different views. Sources: - Primary workflow guidance: https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/ - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html ## Select a Representative Accessibility Audit Sample https://whatisada.com/workflows/accessibility-audit-sampling Updated: 2026-09-11 Choose pages and states that cover the product's important structures and complete processes. Document why each item is included and what remains outside scope. Use a recognized evaluation methodology when making conformance claims. Example: An audit includes a product template, search filters, a complete checkout and a sample of unusual editorial pages. Checks: 1. Start from the inventory and identify common pages, essential tasks, distinct technologies and content variations. Record the target standard and evaluation boundary. 2. Select structured samples and appropriate additional samples using the chosen methodology. Include all views needed to complete selected processes. 3. Review the sample with the product owner and record exclusions and limitations. Expand it when testing reveals a new component, state or recurring defect. Limitations: A small set of popular pages may miss a blocking account or payment step. Sampling reduces work but does not justify conclusions beyond the evaluated scope. Sources: - Primary workflow guidance: https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/ - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html ## Write a Reproducible Accessibility Issue https://whatisada.com/workflows/write-accessibility-issue Updated: 2026-09-11 Turn an observation into a repairable issue with a clear trigger, user impact and expected behavior. Include enough environment detail to reproduce it while removing personal information from evidence. Example: A dialog closes visually, but keyboard focus moves to the start of the page instead of returning to its trigger. Checks: 1. Record the URL, product version, browser and assistive technology. Describe the starting state and the shortest sequence that reproduces the barrier. 2. State what happened, what should happen and how the difference affects the task. Attach relevant screenshots, spoken output or a small code excerpt without sensitive data. 3. Map the issue to a supported criterion where appropriate and assign an owner. Include a concrete retest procedure rather than only a generic instruction to make it accessible. Limitations: A scanner rule name is not a complete issue report. Avoid declaring a legal violation from a technical observation without the relevant applicability analysis. Sources: - Primary workflow guidance: https://www.w3.org/WAI/test-evaluate/report-template/ - WCAG 2.4.3: Focus Order: https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html - WCAG 4.1.2: Name, Role, Value: https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html ## Prioritize Accessibility Issues by User Impact https://whatisada.com/workflows/accessibility-severity-triage Updated: 2026-09-11 Triage findings using a documented impact model and the importance of the affected task. Keep technical severity, business priority and conformance level separate. The result should explain repair order without pretending to predict lawsuits. Example: A keyboard trap blocks checkout while a separate content page has a confusing but usable link label. Checks: 1. For each finding, record who is affected, the task consequence, frequency and whether a practical workaround exists. Identify blockers to essential processes. 2. Group repeated instances by shared cause and owner. Prioritize repairs that remove the largest task barriers or fix a component used across many pages. 3. Record the decision and any temporary alternative, then set a retest condition. Revisit priority when new evidence changes the impact or exposure. Limitations: WCAG Level A is not a universal severity label, and AAA does not mean a problem is unimportant. A numerical score should not hide the reasoning behind a decision. Sources: - Primary workflow guidance: https://www.w3.org/WAI/planning/interim-repairs/ - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 2.1.2: No Keyboard Trap: https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html ## Retest an Accessibility Repair https://whatisada.com/workflows/accessibility-fix-retesting Updated: 2026-09-11 Verify a repair against the original reproduction steps and the surrounding user process. Record the exact build and environment. Keep the original evidence so a reviewer can see what changed. Example: A form error summary now receives focus, but the linked field and success state still need checking. Checks: 1. Reproduce the original issue on the repaired build using the documented environment. Compare actual behavior with the stated acceptance condition. 2. Test adjacent states and another representative use of the shared component. Check that the repair has not introduced a new focus, naming or visual problem. 3. Record the result, evidence and remaining limitations. Close the issue only when the acceptance condition is met, or describe why more work is needed. Limitations: A code change or a developer's screenshot is not the same as a verified result. Retest the user task, especially when the repair affects shared behavior. Sources: - Primary workflow guidance: https://www.w3.org/WAI/test-evaluate/ - WCAG 2.4.3: Focus Order: https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html ## Create an Accessibility Regression Test Plan https://whatisada.com/workflows/accessibility-regression-plan Updated: 2026-09-11 Protect important repaired behavior with a small set of meaningful repeatable tests. Combine automated checks with manual tasks that require judgment or assistive technology. Tie each test to a component or journey that can change. Example: A release updates navigation, form validation and the shared modal used by account settings. Checks: 1. List essential journeys and previously fixed defects affected by the release. Identify which checks can be automated and which need manual interaction. 2. Define stable test data, starting states and expected outcomes. Include keyboard focus, names, validation and responsive states rather than only page-load scans. 3. Run the plan on the release candidate and record the build and results. Update tests when intended behavior changes, preserving the user need behind the original check. Limitations: A large suite of duplicate checks can create noise without protecting additional behavior. A passing automated scan does not replace manual testing of dynamic states. Sources: - Primary workflow guidance: https://www.w3.org/WAI/test-evaluate/tools/selecting/ - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 4.1.2: Name, Role, Value: https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html ## Choose the Appropriate VPAT Edition https://whatisada.com/workflows/choose-vpat-edition Updated: 2026-09-11 Identify the reporting standard requested by the buyer before selecting an ITI VPAT® edition. Record the product, procurement requirement and requested version. The completed report is an ACR; the template itself is not a certification. Example: A software vendor receives one request tied to Revised Section 508 and another requesting a WCAG 2.2 report. Checks: 1. Read the buyer's exact requirements and list the standards, versions and product scope they name. Resolve unclear requirements with the buyer before reporting. 2. Compare those requirements with the current editions on ITI's official VPAT page. Download the appropriate unmodified template and retain its instructions. 3. Record the chosen edition and the evaluation evidence needed to complete it. Keep additional standards or product areas visible instead of silently substituting a different edition. Limitations: Different editions incorporate different WCAG versions and other requirements. Choosing the newest-looking file does not establish that it answers the procurement request. Sources: - Primary workflow guidance: https://www.itic.org/policy/accessibility/vpat - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 4.1.2: Name, Role, Value: https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html ## Evaluate a Vendor Accessibility Conformance Report https://whatisada.com/workflows/review-vendor-acr Updated: 2026-09-11 Read an ACR as evidence about a specific product version and evaluation scope. Compare its statements with the functions your organization will use. Record unanswered questions before treating it as a procurement decision. Example: A report covers a vendor's public website but the purchase includes an authenticated administration console. Checks: 1. Check product name, version, report date, standards and evaluation methods. Confirm that the purchased modules and relevant configurations are included. 2. Read the remarks for criteria affecting your essential tasks. Look for specific limitations, explanations and evidence rather than relying only on a column of support labels. 3. Request clarification or a demonstration of important gaps and document the decision. Track any promised repair separately from current support. Limitations: An ACR is not an ITI approval or a guarantee that every user can complete every task. An outdated or narrowly scoped report may not describe the product being purchased. Sources: - Primary workflow guidance: https://www.section508.gov/buy/ - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html ## Prepare Evaluation Evidence for an ACR https://whatisada.com/workflows/prepare-acr-evidence Updated: 2026-09-11 Organize evidence before completing an Accessibility Conformance Report. Keep product identity, tested configurations and findings traceable to the report's statements. Use ITI's current instructions and the requested standards. Example: A product team has an automated scan, a manual audit and a list of fixes from different releases. Checks: 1. Choose the product version and reporting boundary, then identify the standards and edition required. Separate evidence from older builds or excluded modules. 2. Collect criterion-level observations, test methods, environments and known limitations. Resolve conflicting results and distinguish untested behavior from supported behavior. 3. Draft precise remarks that describe the evaluated functionality and exceptions. Have the report reviewed against the underlying evidence before publication. Limitations: A future repair plan is not evidence of present support. Do not convert an incomplete scan into a product-wide support claim. Sources: - Primary workflow guidance: https://www.itic.org/policy/accessibility/vpat - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 4.1.2: Name, Role, Value: https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html ## Prepare Accessibility Requirements for an RFP https://whatisada.com/workflows/accessibility-rfp-requirements Updated: 2026-09-11 Describe the accessibility outcomes and evidence needed for the actual purchase. Involve procurement and the relevant accessibility owner so requirements fit the product and applicable obligations. Avoid a vague request for an accessibility badge. Example: An organization is buying a scheduling system with a public booking widget, staff console and downloadable reports. Checks: 1. List the user groups, essential tasks, modules and output formats in scope. Identify the applicable standards through the organization's procurement process. 2. Specify the evidence and demonstrations needed to evaluate those requirements, including the relevant ACR, tested version and known limitations. 3. Define how findings, acceptance testing, updates and remediation will be handled. Keep the requirement linked to the purchased configuration and responsible supplier. Limitations: A generic promise to be ADA compliant does not identify a technical target or acceptance method. Requirements should be reviewed for the actual legal and contractual context. Sources: - Primary workflow guidance: https://www.section508.gov/buy/ - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html ## Review Accessibility Responsibilities for a Third-Party Service https://whatisada.com/workflows/third-party-accessibility-handoff Updated: 2026-09-11 Map who can repair each part of an integrated service and how defects will be escalated. Work with the organization's procurement or legal owner for contract terms. This workflow prepares operational evidence, not a legal contract. Example: A website embeds a payment service while the merchant controls the surrounding labels, instructions and error presentation. Checks: 1. Draw the boundary between host content, integration code and vendor interface. Record versions, configuration choices and support contacts for each area. 2. Review available accessibility evidence against the deployed integration. Identify unresolved barriers and the party able to change the affected behavior. 3. Document the reporting route, interim user support and expected retest evidence. Confirm how updates will be communicated and checked after release. Limitations: A supplier's report can exclude the integration layer. Assigning responsibility does not make an inaccessible dependency disappear from the user's process. Sources: - Primary workflow guidance: https://www.w3.org/WAI/planning-and-managing/ - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 4.1.2: Name, Role, Value: https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html ## Write an Evidence-Based Accessibility Statement https://whatisada.com/workflows/write-accessibility-statement Updated: 2026-09-11 Publish a statement that helps visitors understand accessibility support, known limitations and how to report a problem. Base claims on a documented evaluation and give the statement a real owner and update process. Example: A site has completed a scoped audit but still has a known issue in an external booking widget. Checks: 1. Gather the evaluated scope, target standard, methods and date. Separate verified results from goals and work still in progress. 2. Describe known limitations in useful language and provide a working feedback route. Include the information a visitor needs to identify the affected page and request help. 3. Review the statement for accuracy, publish it accessibly and test the contact route. Update it when a significant repair or product change affects its claims. Limitations: A statement that says the site is fully compliant without supporting evidence can mislead visitors. Generic promises are less useful than specific scope and honest limitations. Sources: - Primary workflow guidance: https://www.w3.org/WAI/planning/statements/ - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html - WCAG 2.4.4: Link Purpose (In Context): https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html ## Handle an Accessibility Feedback Report https://whatisada.com/workflows/accessibility-feedback-triage Updated: 2026-09-11 Turn a visitor's report into a respectful support response and a reproducible product issue. Collect only the information needed to understand the barrier. Keep personal or disability information out of public issue records. Example: A visitor says the booking calendar cannot be used with their screen reader and needs to complete a time-sensitive task. Checks: 1. Acknowledge the report through the established support process and identify the task, page and barrier. Offer a practical accessible route when one is available. 2. Ask for optional technical details only when needed to reproduce the problem. Test the reported state and record the user impact without requiring a diagnosis. 3. Assign the issue, track the repair and verify the result. Follow the organization's process for informing the reporter and updating any published known limitation. Limitations: A request for excessive proof can make support another barrier. The immediate task and the long-term product repair both need an owner. Sources: - Primary workflow guidance: https://www.w3.org/WAI/planning/statements/ - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html - WCAG 2.4.4: Link Purpose (In Context): https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html ## Create a Role-Based Accessibility Training Plan https://whatisada.com/workflows/accessibility-training-plan Updated: 2026-09-11 Connect training to the decisions each team makes and the defects the product actually has. Plan practice and follow-up evidence rather than a single awareness presentation. Include content, design, engineering, testing and procurement where relevant. Example: Editors need image and heading skills while engineers need focus management and form-state testing. Checks: 1. Review recent findings and map their causes to roles and workflows. Select a small set of concrete skills for each group. 2. Build practice tasks using representative components or content, with a clear expected result and a review method. Include how to ask for specialist help. 3. Schedule a follow-up check in the normal production process and compare new work with the original failure patterns. Adjust training when the product or team changes. Limitations: Attendance does not demonstrate practical ability. Training is more useful when the team can apply it to its own work and receive specific feedback. Sources: - Primary workflow guidance: https://www.w3.org/WAI/teach-advocate/ - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html ## Review WordPress Image Alt Text in Context https://whatisada.com/workflows/wordpress-image-alt-text Updated: 2026-09-11 Review image alternatives on the rendered WordPress page, not only in the media library. Record the theme and relevant block or plugin, because an image can appear in several contexts with different purposes. Example: A product photograph appears as a linked card on an archive and as an informative image in an article. Checks: 1. Identify the image's purpose in each placement. Inspect the block's alternative-text setting and the rendered image's actual accessible alternative. 2. Use a concise description for information, a purpose-oriented name for an image-only link, or an empty alternative for decoration where appropriate. 3. Preview and publish the intended change, then inspect the live page and responsive variants. Check that cached markup or a custom theme has not retained an old value. Limitations: Updating a media-library field does not necessarily update every existing use. The same file can need different treatment in a card, article and decorative banner. Sources: - Primary workflow guidance: https://wordpress.org/documentation/article/image-block/ - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html - WCAG 2.4.4: Link Purpose (In Context): https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html ## Test WordPress Navigation Blocks and Menus https://whatisada.com/workflows/wordpress-navigation-review Updated: 2026-09-11 Review the rendered WordPress navigation at desktop and mobile widths. Record the active theme and whether the site uses a Navigation block, a classic menu or a plugin, because those implementations have different controls. Example: A site has nested service links and a mobile navigation overlay with a separate close button. Checks: 1. Use the keyboard to reach the navigation, open submenus and follow a link. Check that ordinary destination links and expansion buttons have clear purposes. 2. At a narrow viewport, open and close the navigation overlay. Verify focus placement, visible focus and a usable route back to page content. 3. Inspect names, expanded states and the current-page indication with assistive technology. Retest after a theme or menu-plugin update. Limitations: A well-organized list in the editor does not establish keyboard behavior on the live theme. Hover-only submenus are especially easy to miss during authoring. Sources: - Primary workflow guidance: https://wordpress.org/documentation/article/navigation-block/ - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 2.4.3: Focus Order: https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html ## Audit a WordPress Form Plugin Output https://whatisada.com/workflows/wordpress-form-plugin-review Updated: 2026-09-11 Test the complete form produced by the site's configured plugin and theme. Record the plugin version, custom styles and submission destination. Use a test form or sandbox so validation checks do not send real requests. Example: A contact form includes required fields, a consent checkbox and an anti-spam step. Checks: 1. Inspect visible labels, instructions and programmatic associations in the rendered page. Include fields generated by conditional logic or an integration. 2. Submit empty and invalid test values. Check error identification, focus behavior and whether valid answers survive correction. 3. Complete a permitted test submission and verify the confirmation. Review the anti-spam challenge and any third-party controls separately. Limitations: A plugin's accessibility claim may not cover your theme overrides, custom fields or anti-spam configuration. Record those dependencies with each issue. Sources: - Primary workflow guidance: https://www.w3.org/WAI/tutorials/forms/ - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html ## Review Shopify Product Media Accessibility https://whatisada.com/workflows/shopify-product-media-review Updated: 2026-09-11 Inspect the product gallery as a shopping task, including alternatives, controls and media behavior. Record the theme and gallery app because product media can be rendered differently across storefronts. Example: A product has several angle photographs, a demonstration video and a 3D view used to explain its dimensions. Checks: 1. Review each media item's contribution and add useful alternatives where appropriate. Keep essential dimensions and product facts available as ordinary text. 2. Navigate gallery thumbnails, zoom views and video controls with the keyboard. Check names, selected states, focus and dismissal. 3. Review captions or other media alternatives and test the mobile gallery. Confirm that a customer can understand the product without operating a 3D view. Limitations: A product description can contain important information that should not exist only inside a video or rotating model. Theme and app updates can change gallery behavior. Sources: - Primary workflow guidance: https://help.shopify.com/en/manual/products/product-media - WCAG 1.1.1: Non-text Content: https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html - WCAG 1.2.2: Captions (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded.html ## Test Shopify Cart and Checkout Accessibility https://whatisada.com/workflows/shopify-checkout-accessibility-test Updated: 2026-09-11 Review the actual cart and checkout configuration as a complete purchase process. Include accelerated checkout and installed extensions where they are offered. Use an authorized test mode and fictional customer information. Example: A shopper adds a variant, changes quantity, applies a discount and chooses a delivery method before reviewing the total. Checks: 1. Test product options and cart updates, checking names, errors and price-change announcements. Include a cart drawer if the theme uses one. 2. Follow each offered checkout route through delivery and payment entry in the test environment. Record any provider or extension boundary where behavior changes. 3. Review the order, correct an error and reach a permitted test confirmation. Check mobile layout, keyboard focus and the clarity of the final amount. Limitations: Theme repairs do not necessarily affect hosted checkout or accelerated payment interfaces. Keep the responsible theme, extension or provider attached to each finding. Sources: - Primary workflow guidance: https://help.shopify.com/en/manual/online-store/themes/customizing-themes/accessibility - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html - WCAG 3.3.4: Error Prevention (Legal, Financial, Data): https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html ## Review a Webflow Form Before Launch https://whatisada.com/workflows/webflow-form-accessibility-review Updated: 2026-09-11 Check the published Webflow form with its real labels, styles and success and error states. Use the project's audit tools as one input, then test the user process manually. Record any custom code or third-party form handling. Example: A newsletter form has an email field, a consent checkbox and custom success text that replaces the form. Checks: 1. Inspect field labels, instructions and required states in the published markup. Confirm that text shown inside an empty field is not its only label. 2. Trigger validation and a controlled submission failure. Check the announcements, field associations and focus behavior as messages appear. 3. Complete a permitted test submission and inspect the success state at mobile width and enlarged text. Verify that the visitor receives useful confirmation without an unexpected focus loss. Limitations: An editor audit cannot prove that a custom submission script or success animation behaves accessibly. Test the hosted version users will encounter. Sources: - Primary workflow guidance: https://university.webflow.com/courses/web-accessibility - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html ## Use Wix's Accessibility Wizard and Verify the Result https://whatisada.com/workflows/wix-accessibility-wizard-review Updated: 2026-09-11 Use the Wix Accessibility Wizard to identify supported issues, then complete its manual tasks and review the published site. Record the editor and site language because tool coverage is limited and can vary by feature. Example: A business site contains a booking widget, a side cart and a second language alongside ordinary content pages. Checks: 1. Run the wizard in the supported editor and review its detected issues. Resolve relevant site-level and page-level settings, keeping a record of changes. 2. Complete the manual tasks and inventory features the wizard does not cover. Include custom code, commerce overlays and additional languages in a separate review. 3. Publish the intended fixes and test keyboard navigation, zoom, forms and media in the live configuration. Record remaining barriers by feature and owner. Limitations: Completing the wizard is not a whole-site conformance result. Its documented exclusions and language limits are part of the review scope. Sources: - Primary workflow guidance: https://support.wix.com/en/article/accessibility-using-the-accessibility-wizard - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 1.4.10: Reflow: https://www.w3.org/WAI/WCAG22/Understanding/reflow.html ## Review Squarespace Content and Layout Accessibility https://whatisada.com/workflows/squarespace-content-accessibility-review Updated: 2026-09-11 Review the site's published content structure and responsive layout after editing in Squarespace. Record the site version and any custom CSS. Focus on the blocks and content decisions that visitors encounter in the chosen task. Example: A landing page uses overlapping blocks, image-based promotional text and a form beneath a large banner. Checks: 1. Inspect the heading structure, links and image alternatives in the rendered page. Replace essential image-only text with real content where practical. 2. Review block overlap at mobile width and enlarged text. Check that the reading order and visible order still communicate the same relationships. 3. Navigate the page and form with the keyboard, including error states. Verify that custom CSS has not hidden focus or clipped labels. Limitations: A layout that looks balanced in the editor may overlap differently on mobile. Default platform behavior can also be changed by custom CSS and third-party blocks. Sources: - Primary workflow guidance: https://support.squarespace.com/hc/en-us/articles/13638524256397-Make-your-site-accessible-with-inclusive-design-practices - WCAG 1.3.1: Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html - WCAG 1.4.10: Reflow: https://www.w3.org/WAI/WCAG22/Understanding/reflow.html ## Test Text Resizing to 200 Percent https://whatisada.com/workflows/text-resize-200-percent Updated: 2026-09-11 Review whether text can be enlarged to twice its original size without losing content or functionality. Use a documented browser and check both reading content and controls with constrained dimensions. Keep this test separate from the narrower reflow test. Example: An account page contains a narrow billing card, a renewal button and a help tooltip. Enlarged text must remain readable and actionable. Checks: 1. Record the default viewport and text size. Increase text to 200 percent using an appropriate browser zoom or text-resize setting and document which method you used. 2. Inspect headings, buttons, inputs, error messages and cards for clipping, overlap or lost labels. Open content that was initially collapsed. 3. Complete a short task at the enlarged size. Record any information or action that disappears and capture its default and enlarged states. Limitations: A fixed-height button can retain its outline while losing half its label. Check actual text and functionality, not just whether the page still looks organized. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html - WCAG 1.4.10: Reflow: https://www.w3.org/WAI/WCAG22/Understanding/reflow.html ## Test Page Reflow at 400 Percent Zoom https://whatisada.com/workflows/reflow-400-percent Updated: 2026-09-11 Check a vertically scrolling page at a width equivalent to 320 CSS pixels. A common desktop setup is a 1280 CSS-pixel-wide viewport enlarged to 400 percent. Record the effective viewport instead of assuming a device's physical pixel width is equivalent. Example: A service directory changes from several columns to one, while its filter controls and result descriptions remain available without horizontal page scrolling. Checks: 1. Set and record the initial viewport, then zoom to produce an effective width of 320 CSS pixels. Inspect the main reading flow without reducing the zoom. 2. Open navigation, filters, validation messages and sticky panels. Look for content that overlaps, vanishes or requires scrolling in two directions to read ordinary paragraphs. 3. Review any claimed exception, such as a data table or map, separately. Check whether surrounding headings and controls still reflow and document why two-dimensional layout is necessary. Limitations: The exception for content needing a two-dimensional layout does not exempt the whole page. A wide table should not force every paragraph to scroll horizontally. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/reflow.html - WCAG 2.4.11: Focus Not Obscured (Minimum): https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html ## Test WCAG Text Spacing Overrides https://whatisada.com/workflows/text-spacing-overrides Updated: 2026-09-11 Apply the specified line, paragraph, letter and word spacing simultaneously to check for lost content or functionality. This evaluates resilience to user overrides; it does not require every site's default typography to use these values. Example: A pricing card contains a heading, a short explanation and a purchase button inside a fixed-height container. Checks: 1. Set line height to at least 1.5 times font size, paragraph spacing after paragraphs to at least twice font size, letter spacing to at least 0.12 times font size and word spacing to at least 0.16 times font size. 2. Inspect navigation, cards, labels, validation messages and overlays for clipping or overlap. Expand hidden sections while the overrides remain active. 3. Try the affected actions and record the smallest reproducible example of any lost content. Restore the original styles and compare the same state. Limitations: A screenshot of body paragraphs alone misses components with fixed dimensions. Apply the overrides together and record any language or content exceptions relevant to the criterion. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html ## Review a Site in Forced Colors Mode https://whatisada.com/workflows/forced-colors-review Updated: 2026-09-11 Inspect a site with an operating system contrast theme or a documented forced-colors test setup. Check whether boundaries, selected states and focus remain visible when the browser substitutes system colors. Record the actual environment used. Example: A selected pricing plan uses a background fill and an icon; the selection must remain understandable when that background is replaced. Checks: 1. Enable the contrast theme and reload the representative page. Inspect links, controls, focus indicators and important icons against the substituted background. 2. Operate checkboxes, tabs, validation and dialogs. Verify that selected, checked, expanded and error states remain distinguishable without the original color palette. 3. Inspect decorative and informative background images separately. Record controls that depend on box shadows or background fills and test a border or system-color treatment as a possible repair. Limitations: Forced-colors simulation does not reproduce every user theme. Disabling forced-color adjustment broadly can remove the user's chosen contrast and should not be the default repair. Sources: - Primary workflow guidance: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/forced-colors - WCAG 1.4.11: Non-text Contrast: https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html - WCAG 2.4.7: Focus Visible: https://www.w3.org/WAI/WCAG22/Understanding/focus-visible.html ## Test Reduced Motion Preferences https://whatisada.com/workflows/reduced-motion-review Updated: 2026-09-11 Review how a site responds to a user's reduced-motion preference. Inventory movement before testing, including transitions, smooth scrolling and effects triggered by interaction. Document which movement is essential and how nonessential motion is reduced. Example: A dashboard normally animates cards into place and scrolls smoothly between sections. With reduced motion enabled, the same information appears without a large sweeping transition. Checks: 1. Enable reduced motion in the operating system or a documented browser emulation, then reload the page and inspect initial animations. 2. Trigger menus, route changes, accordions and scrolling actions. Check whether nonessential movement is removed or replaced while focus and state changes remain clear. 3. Test pause or stop controls for automatically moving content separately. Record the preference, motion trigger and alternative behavior for each issue. Limitations: Honoring reduced motion alone does not satisfy every timing, flashing or moving-content requirement. Essential movement and nonessential decoration need different decisions. Sources: - Primary workflow guidance: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion - WCAG 2.3.3: Animation from Interactions: https://www.w3.org/WAI/WCAG22/Understanding/animation-from-interactions.html - WCAG 2.2.2: Pause, Stop, Hide: https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html ## Measure Text Contrast on Images and Gradients https://whatisada.com/workflows/contrast-on-images-and-gradients Updated: 2026-09-11 Review the actual background behind text when it varies across an image or gradient. A single sampled color can hide the weakest part of the text. Test the relevant visual states and responsive crops before choosing a repair. Example: White text overlays a photograph that becomes much brighter behind the heading on mobile. Checks: 1. Identify the rendered foreground and the background immediately behind the text, including opacity and overlays. Sample the least favorable areas that the letters occupy. 2. Compare the resulting color pairs against the applicable text threshold, accounting for actual size and weight. Repeat for responsive crops and changing slides. 3. Try a stable background, stronger scrim or separate text placement. Recheck all tested states and save the colors, crop and viewport with the observation. Limitations: A contrast result for the darkest corner of an image says little about letters over a bright area. Automated tools may be unable to evaluate this background reliably. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html - WCAG 1.4.5: Images of Text: https://www.w3.org/WAI/WCAG22/Understanding/images-of-text.html ## Check Focus Behind Sticky Headers and Banners https://whatisada.com/workflows/sticky-header-focus Updated: 2026-09-11 Test whether focused controls are hidden by sticky or fixed content. Include both forward and reverse keyboard navigation, because scrolling can position the same control differently. Record the page state and viewport for each overlap. Example: A cookie banner covers the last two form fields when focus moves backward from the footer. Checks: 1. Open every persistent banner relevant to the task and Tab through the page. Watch the focused component as the browser scrolls it into view. 2. Reverse direction with Shift+Tab and repeat at a narrow viewport and enlarged zoom. Include links reached through an error summary or in-page anchor. 3. Record whether focus is entirely hidden and whether part remains visible. Adjust scroll margins, layout or banner behavior, then repeat the same navigation sequence. Limitations: A focus outline visible in one direction does not prove the component remains unobscured in the other. WCAG 2.4.11 and the stricter 2.4.12 have different thresholds. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html - WCAG 2.4.12: Focus Not Obscured (Enhanced): https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-enhanced.html ## Test Focus After Client-Side Navigation https://whatisada.com/workflows/route-change-focus Updated: 2026-09-11 Review what happens when a single-page application changes its main view without a full browser load. Check the document title, announcement and next keyboard position together. The goal is an understandable transition, not a mandatory identical focus rule for every route. Example: Selecting an account section replaces the main content while the navigation remains mounted. Checks: 1. Activate an internal route with the keyboard. Record the active element before and after the transition and whether the new page title is meaningful. 2. Read the new content with a screen reader. Check whether a user can identify the destination and reach its primary content without re-reading unrelated material. 3. Test browser Back, filtered results and nested views separately. Verify that intentional focus restoration does not override a user's interaction after the route has loaded. Limitations: Moving focus on every minor update can be disruptive. Distinguish a new page-like context from an inline update that should preserve focus and announce a status. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html - WCAG 2.4.2: Page Titled: https://www.w3.org/WAI/WCAG22/Understanding/page-titled.html ## Test a Form's Error Recovery Path https://whatisada.com/workflows/form-error-recovery Updated: 2026-09-11 Evaluate the process from an invalid submission to a successful correction. Choose representative errors that the form actually supports, and preserve valid information between attempts. Use a test environment so a successful submission has no unwanted real-world effect. Example: A grant application contains a missing required answer and an attachment in an unsupported format. Checks: 1. Submit the form with the planned invalid values. Check that the feedback identifies the affected fields and describes the problems in text. 2. Navigate from the error summary or announcement to each field. Verify that labels and instructions still provide enough context to make a correction. 3. Correct one error at a time and resubmit. Check that resolved messages disappear appropriately, remaining errors stay accurate and valid entries are retained. Limitations: Red borders alone do not explain an error. A message that only appears visually after submission can be missed when focus stays far away. Sources: - Primary workflow guidance: https://www.w3.org/WAI/tutorials/forms/validation/ - WCAG 3.3.1: Error Identification: https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html - WCAG 3.3.3: Error Suggestion: https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion.html ## Review Conditional Questions in a Form https://whatisada.com/workflows/conditional-form-fields Updated: 2026-09-11 Test each answer that reveals or removes dependent fields. Check the resulting reading order, required state and stored answers. Prepare a small branch matrix so every meaningful path is exercised instead of reviewing only the default form. Example: Selecting postal delivery reveals an address section; switching back to email removes that requirement. Checks: 1. List the controlling answers and the fields each should reveal. Test the initial state for hidden controls that remain focusable or incorrectly required. 2. Choose each branch with the keyboard and inspect its announcement and location. Check that newly required fields have names, instructions and appropriate validation. 3. Enter data in one branch, change the controlling answer and submit. Verify that stale hidden answers do not create contradictory results or an unexplained error. Limitations: Hiding a field visually does not clear its validation or stored value. Decide explicitly whether switching paths preserves, clears or ignores dependent answers. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/on-input.html - WCAG 3.3.2: Labels or Instructions: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html ## Test Session Warnings and Extensions https://whatisada.com/workflows/session-timeout-review Updated: 2026-09-11 Review a time-limited process using a documented test account and a controlled timeout. Identify the applicable timing requirement and any specific exception before assessing behavior. Record what a user can do before expiry and what information survives afterward. Example: A benefits form warns that the session will end and offers an extension without discarding entered answers. Checks: 1. Find the configured time limit and reproduce its warning in a test environment. Check that the warning is perceivable and the extension control is keyboard accessible. 2. Use the offered extension and verify the remaining task stays intact. Assess timing against the actual criterion rather than an assumed universal duration. 3. Allow the session to expire and test recovery. Record whether reauthentication preserves entered data and whether the user receives a clear explanation. Limitations: A visible countdown is not an extension mechanism. Security or server architecture alone does not establish that a WCAG timing exception applies. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html - WCAG 2.2.6: Timeouts: https://www.w3.org/WAI/WCAG22/Understanding/timeouts.html ## Review Caption Accuracy and Timing https://whatisada.com/workflows/caption-quality-review Updated: 2026-09-11 Watch a complete representative media item with its captions enabled and compare the captions with the audio. Review names, numbers, speaker changes and meaningful sounds rather than relying only on the presence of a caption track. Example: A training video explains a safety sequence while two speakers demonstrate different steps. Checks: 1. Check that captions are available from the player and can be enabled with the keyboard. Record the media version and caption language. 2. Compare speech, speaker identification and meaningful non-speech audio with the captions. Note missing information, incorrect terms and timing that makes lines difficult to associate with the action. 3. Review captions over busy visuals and during rapid exchanges. Confirm that essential on-screen information is not obscured and that corrected captions are published with the right media version. Limitations: Automatic captions can contain plausible-looking errors in technical terms or numbers. A transcript does not replace synchronized captions where captions are required. Sources: - Primary workflow guidance: https://www.w3.org/WAI/media/av/captions/ - WCAG 1.2.2: Captions (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/captions-prerecorded.html - WCAG 1.2.4: Captions (Live): https://www.w3.org/WAI/WCAG22/Understanding/captions-live.html ## Identify Audio Description Needs in Video https://whatisada.com/workflows/audio-description-review Updated: 2026-09-11 Review visual information that a listener cannot obtain from the existing audio. Start with the video's purpose and target conformance level. Record the moments where actions, diagrams or on-screen text carry information needed to understand it. Example: A tutorial silently highlights a control and displays a warning while the narrator discusses a different step. Checks: 1. Listen to the video without watching and note unclear references. Then inspect the corresponding visuals to identify information absent from the soundtrack. 2. List the necessary visual details and available pauses. Evaluate whether the original narration can integrate them or whether a described version is needed. 3. Review the resulting description in context, including access through the player or an equivalent clearly identified version. Check that it does not obscure essential dialogue. Limitations: Repeating every visual detail can overwhelm the listener. The purpose is access to meaningful visual information, and a text alternative does not always substitute for audio description at the selected level. Sources: - Primary workflow guidance: https://www.w3.org/WAI/media/av/description/ - WCAG 1.2.3: Audio Description or Media Alternative (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/audio-description-or-media-alternative-prerecorded.html - WCAG 1.2.5: Audio Description (Prerecorded): https://www.w3.org/WAI/WCAG22/Understanding/audio-description-prerecorded.html ## Audit a Third-Party Embed in Context https://whatisada.com/workflows/third-party-embed-review Updated: 2026-09-11 Test an embedded widget as part of the page and the complete user process. Record its vendor, version, integration settings and frame boundaries. Separate defects the site owner can repair from defects requiring the provider. Example: A support page embeds a scheduling widget that opens a time selector and then a contact form. Checks: 1. Navigate to, into and out of the embed using the keyboard. Check its frame title, entry point, reading order and exit behavior. 2. Complete the embedded task, including validation and cancellation. Review zoom, mobile layout and screen-reader announcements at each boundary. 3. Document failures with the host URL, widget state and vendor details. Identify an interim accessible route that accomplishes the same task while a repair is pursued. Limitations: A vendor accessibility statement does not verify your configured integration. An alternative route should be usable and discoverable, not merely an instruction to try another browser. Sources: - Primary workflow guidance: https://www.w3.org/WAI/WCAG22/Understanding/conformance.html - WCAG 2.1.1: Keyboard: https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html - WCAG 2.1.2: No Keyboard Trap: https://www.w3.org/WAI/WCAG22/Understanding/no-keyboard-trap.html # Glossary definitions - Accessibility Overlay: An accessibility overlay is a third-party JavaScript widget that claims to automatically detect and fix website accessibility issues, but independent research, court rulings, and disability advocacy organizations have consistently found that overlays do not deliver meaningful accessibility and may increase legal risk. (https://whatisada.com/glossary/accessibility-overlay) - ADA Compliance Audit: A systematic evaluation of a website, application, or physical space to determine whether it meets ADA requirements and WCAG standards for accessibility. (https://whatisada.com/glossary/ada-compliance-audit) - ADA Compliance: ADA compliance means meeting the requirements of the Americans with Disabilities Act to ensure that people with disabilities have equal access to facilities, services, employment, and digital content — including websites and mobile applications. (https://whatisada.com/glossary/ada-compliance) - ADA Lawsuit: An ADA lawsuit is a civil rights legal action filed under the Americans with Disabilities Act alleging that a business or organization has discriminated against people with disabilities by failing to provide accessible facilities, services, or digital experiences. (https://whatisada.com/glossary/ada-lawsuit) - ADA Title III: ADA Title III prohibits discrimination on the basis of disability in places of public accommodation operated by private entities, including hotels, restaurants, retail stores, healthcare providers, and — as courts and the DOJ have increasingly affirmed — their websites and digital services. (https://whatisada.com/glossary/ada-title-iii) - ADA (Americans with Disabilities Act): The Americans with Disabilities Act (ADA) is a landmark U.S. civil rights law enacted in 1990 that prohibits discrimination against individuals with disabilities in all areas of public life, including employment, education, transportation, and access to public and private places open to the general public. (https://whatisada.com/glossary/ada) - ARIA (Accessible Rich Internet Applications): ARIA (Accessible Rich Internet Applications) is a set of HTML attributes defined by the W3C that add semantic meaning to web elements, enabling assistive technologies like screen readers to understand and interact with dynamic content and custom interface components. (https://whatisada.com/glossary/aria) - Audio Description: Audio description is a narration track added to video content that describes important visual information, actions, and scene changes during natural pauses in dialogue, making video accessible to people who are blind or have low vision. (https://whatisada.com/glossary/audio-description) - Color Contrast Ratio: Color contrast ratio is a mathematical measurement of the luminance difference between foreground text and its background color, used by WCAG to ensure text is readable for people with low vision or color vision deficiencies. (https://whatisada.com/glossary/color-contrast-ratio) - Keyboard Navigation: Keyboard navigation is the ability to use a website or application entirely through keyboard input — using Tab, Enter, arrow keys, and other keys — without requiring a mouse, which is essential for users with motor disabilities and screen reader users. (https://whatisada.com/glossary/keyboard-navigation) - Remediation: The process of identifying and fixing accessibility barriers in digital content, websites, or applications to bring them into compliance with WCAG and legal requirements. (https://whatisada.com/glossary/remediation) - Screen Reader: A screen reader is assistive technology software that converts on-screen text, images, and interface elements into synthesized speech or braille output, enabling people who are blind or visually impaired to use computers and navigate websites. (https://whatisada.com/glossary/screen-reader) - Section 508: Section 508 is a provision of the Rehabilitation Act of 1973 that requires federal agencies to make their electronic and information technology accessible to people with disabilities, including federal websites, software, documents, and digital services. (https://whatisada.com/glossary/section-508) - Switch Access: An assistive technology method that allows people with severe motor disabilities to operate computers and mobile devices using one or more switches instead of a keyboard or touchscreen. (https://whatisada.com/glossary/switch-access) - Text Alternative: A text alternative is a textual description that serves as a substitute for non-text content such as images, videos, audio, and charts, making the information accessible to people who cannot perceive the original format. (https://whatisada.com/glossary/text-alternative) - Voice Control: Assistive technology that allows users to operate computers and mobile devices using spoken commands, enabling people with motor disabilities to navigate, type, and interact without a keyboard or mouse. (https://whatisada.com/glossary/voice-control) - VPAT (Voluntary Product Accessibility Template): A VPAT (Voluntary Product Accessibility Template) is a standardized document that explains how a digital product or service conforms to accessibility standards, primarily used in government and enterprise procurement to evaluate whether technology meets Section 508 and WCAG requirements. (https://whatisada.com/glossary/vpat) - WCAG (Web Content Accessibility Guidelines): WCAG (Web Content Accessibility Guidelines) is a set of internationally recognized technical standards published by the W3C that defines how to make web content more accessible to people with disabilities, organized around four principles: Perceivable, Operable, Understandable, and Robust. (https://whatisada.com/glossary/wcag) - Web Accessibility: Web accessibility is the practice of designing and developing websites, tools, and technologies so that people with disabilities can perceive, understand, navigate, interact with, and contribute to the web equally and independently. (https://whatisada.com/glossary/web-accessibility)