Website Redesign ADA Compliance Guide
How to handle ADA compliance during a website redesign — WCAG standards, accessibility testing, and avoiding legal risk post-launch.

Website redesign ADA compliance is no longer a consideration for large enterprises only.
Web accessibility lawsuits exceeded 4,000 in the United States in 2023, and the most common defendant is a mid-size business that never addressed accessibility during its last website redesign.
The legal landscape has changed faster than most businesses have responded. Courts have applied ADA Title III to websites, the DOJ issued WCAG 2.1 AA requirements in 2024, and plaintiff attorneys identify violations at scale.
This guide covers what compliance requires, who it applies to, and how to build it into a redesign from the start.
Key Takeaways
- ADA applies to most business websites: Title III's broad interpretation has been consistently upheld for places of public accommodation, which courts have extended to online spaces.
- WCAG 2.1 AA is the standard: Every recent court settlement, DOJ guideline, and accessibility regulation points to WCAG 2.1 Level AA as the technical minimum for compliance.
- Lawsuits target fixable violations: The most common ADA web cases involve missing alt text, inaccessible forms, and poor keyboard navigation, all addressable in a redesign.
- Accessibility helps everyone: Changes that serve users with disabilities, such as clearer labels, sufficient contrast, and keyboard navigation, improve the experience for all users.
- Ongoing maintenance is required: An accessible site at launch can become non-compliant as content is added; accessibility must be part of governance, not a one-time fix.
The Legal Landscape for Web Accessibility
Understanding the specific legal framework for web accessibility helps businesses assess their actual exposure and make informed compliance decisions.
ADA Title III and Website Coverage
ADA Title III prohibits discrimination in places of public accommodation. Courts have increasingly applied this to business websites, creating a legal risk that businesses cannot ignore.
- Circuit court precedent: The Ninth and Eleventh Circuits have both upheld ADA Title III claims against business websites, establishing precedent in major commercial markets.
- DOJ guidance letters: The Department of Justice has issued multiple guidance letters confirming its position that websites of public accommodations must be accessible.
- Consent agreement record: Published DOJ consent agreements with universities, retailers, and healthcare providers establish what remediation programs in practice look like.
- No "website exception" in the statute: Federal courts have consistently rejected arguments that the ADA's pre-internet drafting excludes websites from its coverage.
While no single federal statute explicitly names websites as covered, the weight of judicial precedent and DOJ guidance has effectively settled the question for most business categories.
DOJ's 2024 Rule for State and Local Government Websites
The March 2024 DOJ rulemaking represents the clearest federal signal yet about the direction of web accessibility enforcement across sectors.
- Explicit WCAG 2.1 AA codification: The rule explicitly establishes WCAG 2.1 Level AA as the required technical standard for state and local government websites.
- Compliance deadlines: Large entities with populations over 50,000 had a two-year compliance period; smaller entities received three years, creating a near-term enforcement horizon.
- Private sector signaling: The explicit adoption of WCAG 2.1 AA as the legal standard for public entities signals that the same standard is increasingly likely to apply to private sector enforcement.
- Existing precedent compatibility: The rule is consistent with the WCAG 2.0 AA standard already referenced in Section 508 and in existing consent agreements across multiple sectors.
The 2024 rule is the most significant federal action on web accessibility in decades. Businesses that treat it as applying only to government sites are misreading the direction of enforcement.
The Anatomy of a Web Accessibility Lawsuit
Understanding how ADA web lawsuits actually work in practice helps businesses understand their real risk profile and make proportionate compliance investments.
- Automated audit pipeline: Serial plaintiff attorneys use automated accessibility scanning tools to identify technical violations across thousands of sites efficiently and at low cost.
- Demand letter first: Most cases begin with a demand letter identifying violations and requesting remediation and monetary settlement rather than proceeding directly to litigation.
- Settlement cost range: Web accessibility settlements typically range from $25,000 to $150,000, plus legal fees and remediation costs, depending on business size and violation scope.
- Consent agreement requirements: Settlements require documented remediation plans, often with third-party auditing, employee training, and annual monitoring commitments.
The economics of web accessibility litigation favor plaintiffs in demand letter scenarios because the cost of defense and settlement typically exceeds the cost of proactive compliance.
WCAG 2.1 AA: The Technical Standard Explained
WCAG 2.1 AA is the technical standard referenced in virtually every web accessibility legal context. Understanding what it requires makes compliance feel achievable rather than overwhelming.
The Four WCAG Principles: POUR
WCAG 2.1 is organized around four principles that define what an accessible web experience must provide at the most fundamental level.
- Perceivable: All information and interface components must be presentable to users in ways they can perceive, including through screen readers, captions, and text alternatives to visual content.
- Operable: All interface components and navigation must be operable by keyboard, providing sufficient time, and without causing seizures or physical reactions.
- Understandable: Information and the operation of the interface must be understandable, including readable text, predictable behavior, and input assistance for forms.
- Robust: Content must be robust enough to be reliably interpreted by a wide variety of assistive technologies, including current and future user agents.
The POUR framework is a useful lens for evaluating any design or content decision. If a decision undermines perceivability, operability, understandability, or robustness, it creates an accessibility violation.
The Most Commonly Violated WCAG Success Criteria
A small number of WCAG violations account for the majority of ADA web lawsuits and automated audit findings.
- Image alt text (1.1.1): Missing or inadequate alternative text for images is the single most commonly cited violation in both automated audits and ADA demand letters.
- Color contrast (1.4.3): Text that fails the 4.5:1 contrast ratio requirement for normal text (3:1 for large text) affects users with low vision and is detectable by automated tools.
- Form labels (1.3.1 and 4.1.2): Form fields without associated labels, or with labels that are only visual rather than programmatically associated, are common and fixable violations.
- Keyboard focus indicators (2.4.7): Interactive elements that have no visible focus state when keyboard navigation is used make keyboard-only navigation practically impossible for many users.
These violations are not obscure edge cases. They appear on the majority of business websites that have not been through a deliberate accessibility review.
AA vs. AAA: What Level Is Required
WCAG has three conformance levels: A (minimum), AA (standard), and AAA (enhanced). Understanding the practical difference helps businesses set the right compliance target.
- Level A requirements: The absolute minimum accessibility requirements. A site that is only Level A compliant is still likely to face ADA claims, as courts and DOJ guidance reference Level AA.
- Level AA requirements: The standard referenced in every court settlement, DOJ consent agreement, and legal guidance document. This is the correct compliance target for all business websites.
- Level AAA requirements: Enhanced requirements that go beyond what is legally required and that are not achievable for all content types. Aspirational but not legally mandated.
- Practical implication: Design to WCAG 2.1 Level AA compliance. Document the effort. Level AAA enhancements that are practical to implement are worth adding but are not required.
Building to Level AA is both the legal floor and the practical right target. Chasing AAA without achieving AA first is a misallocation of compliance effort.
Who Is Required to Comply
Determining which organizations have legal web accessibility obligations helps businesses assess their specific risk exposure accurately.
Public Accommodations Under ADA Title III
ADA Title III covers 12 categories of public accommodations. Courts have consistently found that these organizations' websites are subject to ADA requirements.
- Retailers and restaurants: Physical places of public accommodation with websites have been consistently subject to ADA web claims across multiple circuit courts.
- Healthcare providers: Medical practices, hospitals, pharmacies, and healthcare service businesses face both ADA and Section 504 obligations for their patient-facing websites.
- Educational institutions: Private universities and schools are covered under Title III. Public institutions face Title II requirements, which are now explicitly codified for websites.
- Entertainment and hospitality: Hotels, theaters, gyms, and entertainment venues have been among the most frequently sued categories in ADA web litigation.
If your business operates a physical location that serves the public, or if you sell goods or services to the public online, ADA web accessibility obligations most likely apply to you.
Federal Contractors and Section 508
Section 508 of the Rehabilitation Act applies to federal agencies and to companies that develop, procure, or use information technology with federal funding.
- Direct coverage: Federal agencies are directly subject to Section 508 for all electronic and information technology, including websites and web-based applications.
- Contractor coverage: Companies receiving federal contracts for technology development or services must ensure that technology delivered to the government meets Section 508 standards.
- WCAG alignment: Section 508's technical standard was updated to reference WCAG 2.0 AA and is moving to WCAG 2.1 AA alignment, making the practical requirements essentially identical.
- Compliance implications: Businesses that work with government clients should treat WCAG 2.1 AA compliance as a procurement requirement rather than a voluntary practice.
Federal contractors who deliver non-compliant technology face contract performance risk and potential procurement disqualification that makes compliance a commercial issue, not just a legal one.
State Laws More Stringent Than Federal ADA
Several states have enacted accessibility laws with higher damages exposure than federal ADA, creating elevated risk for businesses operating in those jurisdictions.
- California Unruh Civil Rights Act: California's Unruh Act applies to all business establishments and allows statutory damages of $4,000 per violation per visit, significantly exceeding federal ADA damages.
- New York State Human Rights Law: New York has been among the most active enforcement jurisdictions for web accessibility claims, with a large volume of annual filings.
- State law interaction: Some state laws do not require the "nexus to physical location" argument that some federal courts have required, creating broader website coverage.
- Multi-state businesses: Businesses operating nationally should calibrate their compliance effort to the most stringent applicable state law, not just the federal minimum standard.
For more information on how accessibility requirements vary by sector, the government website ADA requirements and healthcare site accessibility requirements resources cover sector-specific compliance details.
Building Accessibility Into the Redesign Process
Integrating accessibility into each phase of a redesign costs significantly less than retrofitting it after launch. The earlier accessibility requirements are specified, the cheaper they are to implement.
Reviewing web accessibility best practices during the discovery and planning phase ensures that accessibility is treated as a design specification rather than a quality assurance afterthought.
Accessibility in the Design Phase
Accessibility requirements addressed during design are the cheapest version of those requirements in the entire project timeline.
- Color contrast verification: Use a contrast checker (Figma plugins like Stark or Contrast, or web tools like WebAIM's contrast checker) to verify every text-on-background color combination against WCAG 4.5:1 and 3:1 thresholds.
- Focus state design: Design visible keyboard focus states for every interactive element: buttons, links, form fields, and navigation items must all have clearly visible focus indicators.
- Touch target sizing: Design all interactive elements to meet the WCAG 2.5.5 minimum 44x44 CSS pixel touch target recommendation, building this into the component library rather than retrofitting it.
- Typography minimums: Establish a minimum body text size of 16px (or 1rem) in the design system, ensuring readability for users with mild visual impairments without assistive technology.
Accessibility decisions made in Figma during the design phase cost zero additional development time. The same decisions discovered in a post-launch audit cost one to three hours of development time per violation.
Accessibility in the Development Phase
Development-phase accessibility requires semantic HTML structure, correct ARIA implementation, and thorough keyboard navigation testing for every interactive element.
- Semantic HTML: Use heading hierarchy (H1 through H4) correctly, label form fields with associated label elements, and use landmark elements (main, nav, header, footer) to define page regions.
- ARIA implementation: Apply ARIA roles, states, and properties only where semantic HTML is insufficient. Over-use of ARIA is as problematic as under-use for screen reader users.
- Keyboard navigation testing: Test every interactive element for keyboard access by disconnecting the mouse. Tab focus order, focus visibility, and actionability must all work correctly.
- Screen reader testing: Test completed pages with NVDA on Windows and VoiceOver on macOS and iOS to verify that content is announced correctly to screen reader users.
Development-phase accessibility testing should be continuous, not a final-stage check. Accessibility problems discovered page by page during build are far cheaper to fix than those found in a final audit.
Accessibility QA Before Launch
A structured pre-launch accessibility audit combines automated scanning and manual testing to identify violations before the site goes live.
- Automated scanning: Run completed pages through axe DevTools, WAVE, or Lighthouse accessibility audits to identify programmatically detectable violations across all pages.
- Manual keyboard testing: Complete every primary user journey using only a keyboard to verify focus management, skip navigation links, and interactive element accessibility.
- Screen reader journey testing: Complete primary journeys with NVDA and VoiceOver active to verify that the site's content and navigation work correctly for blind and low-vision users.
- Remediation documentation: Document every identified violation, its WCAG success criterion reference, and the remediation action taken, creating a due diligence record.
Pre-launch audit documentation serves two purposes: it confirms compliance before launch and it creates a record of due diligence that is relevant if an ADA claim is later filed.
Accessibility and Mobile Design Overlap
Mobile design and accessibility share a large set of requirements. Designing for mobile usability and designing for accessibility are more complementary than separate in practice.
Accessibility in mobile website redesigns covers the full intersection of mobile UX requirements and accessibility compliance, showing where the design decisions overlap.
Touch Target Sizing as Both Mobile and Accessibility Requirement
WCAG 2.5.5 (target size) and mobile UX guidelines both specify the same minimum touch target dimensions, making the design decision identical for both objectives.
- WCAG 2.5.5 requirement: A minimum target size of 44x44 CSS pixels for interactive elements, or spacing around smaller targets that provides equivalent effective touch area.
- Mobile UX guideline alignment: Apple's Human Interface Guidelines and Google's Material Design both recommend 44-48dp minimum touch targets for the same usability reasons WCAG specifies.
- Component library integration: Build minimum touch target sizing into the component design system so every button, link, and interactive element meets the standard automatically.
- Testing across devices: Verify touch target sizing on actual devices at the smallest physical screen size the site is designed for, not only in emulator views in development tools.
Minimum touch target sizing is a single design system decision that satisfies both WCAG 2.5.5 and mobile UX guidelines simultaneously, making it one of the highest-efficiency accessibility investments in a redesign.
Reflow and Responsive Design for Visual Impairments
WCAG 1.4.10 (Reflow) requires that content be presentable without horizontal scrolling at 400% zoom. Responsive design built for mobile viewports satisfies this requirement as a byproduct.
- 400% zoom test: A site designed with responsive breakpoints at 320px width will typically reflow correctly at 400% zoom on a 1280px display without horizontal scroll.
- Content completeness at zoom: Verify that no content is hidden, clipped, or inaccessible when the page is zoomed to 400%. Overlapping elements and hidden overflow are common failure modes.
- Mobile-first design benefit: A mobile-first design approach, where the smallest viewport is designed first, naturally produces reflow-compliant layouts as a consequence of the design process.
- Testing requirement: Browser zoom testing to 400% on key page templates should be part of the pre-launch accessibility QA checklist on every redesign project.
Reflow compliance is essentially free for sites built with genuine mobile-first responsive design. It becomes expensive to retrofit on sites where mobile was treated as a secondary concern.
Captioning and Transcripts for Audio and Video
Audio and video accessibility requirements apply equally on mobile and desktop and must be addressed as part of content production workflows, not just site development.
- Closed caption requirement: All pre-recorded video with audio must include synchronized closed captions that accurately represent dialogue, speaker identification, and relevant non-speech audio.
- Transcript provision: Audio-only content (podcasts, audio guides) must be accompanied by a full text transcript that conveys the same information as the audio.
- Live content requirements: Live video with audio must provide real-time captions. The technical requirement exists even when automated captioning accuracy is imperfect.
- Production workflow integration: Caption and transcript production must be built into the content creation workflow, not added as a post-publication accessibility retrofit.
Captioning and transcripts are among the most commonly missed accessibility requirements on business websites. They are also among the most common violations cited in DOJ consent agreements for media companies and educational institutions.
Conclusion
Website redesign ADA compliance is not a legal technicality to manage around.
It is the minimum standard for building a site that every person, regardless of ability, can actually use, and it is the legal floor that protects businesses from preventable and expensive litigation.
Run your current site through the WAVE accessibility tool today at wave.webaim.org. The errors it identifies are the exact violations that trigger ADA demand letters.
The report is free, and it is the most actionable hour you can spend before your redesign brief is written.
LOW/CODE Agency Builds Accessible Websites That Meet WCAG 2.1 AA Standards
LOW/CODE Agency integrates accessibility compliance into every phase of a website redesign: design-phase contrast checking and component specification, development-phase semantic HTML and ARIA implementation, and pre-launch automated and manual accessibility auditing.
Accessibility is not a final QA pass; it is a continuous build requirement.
We work as a strategic product team, not a dev shop. Every project includes documented accessibility compliance at handoff, giving clients both a compliant site and a clear due diligence record.
- Design-Phase Accessibility Review: Color contrast verification, focus state design, touch target specification, and typography minimums built into the design system before development begins.
- Semantic HTML and ARIA Development: Correct heading hierarchy, landmark elements, ARIA implementation, and keyboard navigation built into every page and component as standard.
- WCAG 2.1 AA Compliance Audit: Pre-launch audit combining axe DevTools automated scanning, manual keyboard testing, and screen reader verification with NVDA and VoiceOver.
- Document Accessibility Review: Assessment of PDF and document accessibility risk within the site scope, with remediation recommendations and workflow change guidance.
- Post-Launch Accessibility Governance: Annual audit recommendations, content author training materials, and user feedback mechanisms to maintain compliance as content is added.
- Accessibility Documentation: VPAT (Voluntary Product Accessibility Template) documentation and compliance record created at handoff for regulated industry clients and government contractors.
- Accessible Component Library: Fully accessible button, form, navigation, modal, and interactive component designs documented for development and available in Figma and in-platform.
Our clients include Coca-Cola, American Express, and Sotheby's. We have shipped over 350 digital products worldwide. Explore our ADA-compliant website redesign services or Start with a scoping call to discuss your accessibility compliance requirements.
Last updated on
July 10, 2026
.










