Enacted in 1990, the Americans with Disabilities Act (ADA) is a civil-rights law that prohibits disability discrimination and requires equal access—including online.
The ADA has five titles; the two that most affect websites, apps, forms, and documents are Title III, which applies to private businesses that serve the public, and Title II, which applies to state and local governments.
This guide explains who each title applies to, how each relates to web accessibility, and what you will need to do to comply with the law. We’ll also explain the relevant timelines, and offer a practical plan to move forward.
ADA Title III — the law governing private businesses
ADA Title III applies to businesses considered “public accommodations.” This is a broad category that covers most public-facing organizations. Basically, if your business is public-facing, you are likely legally bound by the ADA Title III.
Title III applies to physical spaces as well as to digital ones.
Along with physical stores and facilities, relevant businesses must ensure their websites, mobile apps, online documents, and other public-facing digital assets are accessible to people with disabilities.
Examples of entities that need to comply with ADA Title III:
- Banks and credit unions
- Colleges and universities (private)
- Hotels and hospitality businesses
- Retail stores and eCommerce sites
- Restaurants and food service providers
- Transportation companies
- Theaters, museums, and entertainment venues
- Real estate agencies and property management firms
- Healthcare providers, including private clinics and dental offices
- Gyms, fitness centers, and recreational facilities
- Law firms, accounting firms, and other professional service providers
View the complete list of entities covered by ADA Title III.
ADA Title II — the law governing public entities
Unlike Title III, which covers private businesses, Title II ensures equal access to government programs, services, and digital content, offered by municipalities, public schools and universities, transit systems, and other government-managed institutions and services. In practice, that means public websites, online forms, documents, and digital tools must be accessible to people with disabilities.
Examples of entities that need to comply with ADA Title II include, but aren’t limited to:
- State and local government websites and digital services
- Public schools, universities, and libraries
- Public transportation authorities and transit systems
- County and city offices
- Police and fire departments
- Courts and judicial branches
- Public hospitals and health departments
- Housing authorities and public benefit programs
- Election boards and government service portals
What about Section 508 of the Rehabilitation Act?
You may have heard of Section 508 of the Rehabilitation Act, another federal law that deals with digital accessibility. Section 508 applies to U.S. federal agencies and the contractors that work with them, requiring their websites, software, and electronic documents to be accessible to people with disabilities.
If you’re part of a state or local government, Section 508 doesn’t apply to you—your responsibilities fall under ADA Title II.
To learn more about Section 508, who it applies to, and what complying with it entails, press here.
How do you comply with ADA Title II and III?
To comply with ADA Titles II and III, you will need to fulfill a number of requirements pertaining to both your physical and online domains.
For physical environments, compliance means your facilities and operations provide equal access. That includes accessible routes and entrances, appropriate door widths and clear floor space, compliant restrooms and parking, elevators where required, readable signage, and accessible service counters or seating. It also includes policies that enable access, such as permitting service animals and providing effective communication in person when needed.
For more comprehensive instructions on this matter, press here.
For digital environments, compliance means your websites, apps, and public-facing documents conform to the Web Content Accessibility Guidelines WCAG 2.1 Level AA.
In practice, that standard covers keyboard operation, screen-reader compatibility through semantic code, sufficient color contrast, alt text for meaningful images, clear heading structure, captions and transcripts for media, accessible forms and errors, and correctly tagged PDFs and office files.
WCAG: The key to legal compliance
The Web Content Accessibility Guidelines (WCAG) are technical standards developed by the World Wide Web Consortium (W3C) to make digital content usable for people with disabilities. They’re built on four principles—perceivable, operable, understandable, and robust—and each maps to everyday usability.
- Perceivable means people can detect and consume content in more than one way, for example with text alternatives or captions.
- Operable means every feature works with different inputs, including keyboard and assistive tech.
- Understandable means layouts, language, and interactions are clear and predictable.
- Robust means the code follows standards so content works reliably with current and future assistive technologies.
You’ll find these pillars summarized in our ADA Title II guide.
WCAG exists in versions 2.0, 2.1, and 2.2, with WCAG 2.1 being the version most commonly referenced in U.S. requirements today.
Conformance is measured at three levels: A, AA, and AAA. Level AA is the expected bar under the law for public entities (Title II) and the typical benchmark for ADA compliance.
In practical terms, aligning with WCAG 2.1 Level AA means your websites, apps, and public-facing documents support assistive technologies and inclusive interaction patterns.
For example, compatibility with screen readers, full keyboard operation, sufficient color contrast, meaningful alt text, clear headings, captions, and transcripts for media, accessible forms, and properly tagged PDFs and office files.
Is WCAG the official codified standard for compliance under ADA Titles II and III?
Under ADA Title II, yes. The Department of Justice set WCAG 2.1 Level AA as the technical standard for state and local government websites and mobile apps, with defined deadlines by entity size.
Under ADA Title III, there is no single technical rule written into the regulation. In practice, WCAG Level AA is the benchmark. U.S. courts and the DOJ regularly reference WCAG when evaluating whether business websites and apps provide accessible experiences. Think of WCAG AA as the de facto yardstick for private-sector digital access.
Are ADA Title II and III currently enforced in regards to digital accessibility?
Title III of the ADA has been applied to the digital domain for years, withgaps in digital accessibility leading to demand letters and lawsuits against businesses across industries. The DOJ has, since at least 2018, reinforced that businesses should make their digital environments accessible and has repeatedly referenced WCAG in guidance and enforcement. Expect active scrutiny today, driven both by private litigation and agency actions.
Title II of the ADA - as it pertains to digital accessibility, will begin to be enforced in April 2026, with smaller entities and special districts having until April 2027 to comply. The requirements are set, the timelines are public, and agencies should be planning and executing now.
What conforming to WCAG looks like: A short checklist
Here are some of the most important action items you will need to see to ensure your website and other digital environments adhere to WCAG and are in compliance with the law.
Important note: This is a partial list.
Allow for keyboard-only navigation
Ensure every interactive element—menus, buttons, links, tabs, accordions, dialogs, forms—can be reached and used with the keyboard alone (Tab, Shift+Tab, Enter/Space, Arrow keys). Visible focus styles must be clear and consistent.
Ensure full compatibility with assistive technologies
Use semantic HTML (proper landmarks, headings, lists, tables) and meaningful ARIA only when needed so screen readers announce content, roles, names, and states accurately.
Use highly contrasting colors
Meet WCAG 2.1 Level AA contrast: at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Apply the same care to text in images, buttons, banners, and infographics.
Provide alt text for meaningful images
Write concise, informative alternative text for images that convey information or function. Mark decorative images as decorative so screen readers skip them.
Use proper heading structure
Organize content with a logical H1 → H2 → H3 hierarchy. Headings should describe sections, not be used only for visual styling.
Include captions and transcripts for media
Add accurate captions to videos and provide transcripts for audio so users who are Deaf or hard of hearing can access the information. For live streams, supply real-time captions and post corrected captions with the recording.
Design accessible forms
Associate labels with inputs, provide clear instructions and examples, group related fields, indicate required fields, and present errors with text that’s announced to screen readers and linked back to the field.
Keep layout responsive and flexible
Ensure pages work across screen sizes and orientations. Support zoom up to 200% without loss of content or functionality and without forcing horizontal scrolling on small screens.
Don’t rely on color alone
Use text labels, patterns, or icons—not just color—to convey meaning in charts, status badges, form errors, and interactive controls.
Write clear, descriptive links
Avoid “click here.” Use link text that states the action or destination (e.g., “Download 2026 transit schedule (PDF)”).
Maintain consistent navigation
Keep menus, search, and key controls in predictable locations with consistent names and order across pages to reduce cognitive load.
Control motion, flashing, and autoplay
Avoid content that flashes more than three times per second. Provide an obvious way to pause/stop autoplaying video or audio and respect user settings that reduce motion.
Support error prevention and recovery
For critical transactions (payments, applications), provide confirmations, review screens, and clear ways to fix mistakes before submission.
Make documents accessible
Tag PDFs and Office files with proper headings, lists, table structure, alt text, and reading order so assistive technologies can parse them. Use true text—not scanned images of text.
Announce dynamic updates
For content that changes without a page reload (alerts, form validation, live results), use appropriate ARIA live regions or native semantics so screen readers notify users.
Ensure focus management in modals and menus
When opening dialogs or menus, move focus inside, trap it until closed, and return focus to the trigger on close.
Test with tools and people
Combine automated scans with manual checks and usability testing by people with disabilities to validate real-world accessibility, then track and fix issues at the template/component level.
accessiBe’s here to help
accessiBe is an end-to-end accessibility platform that unites AI automation, expert services, and developer tools. The result is a customizable program that supports obligations under Title II and Title III across websites, apps, and digital documents.
Leverage the power of AI to meet necessary WCAG criteria
accessWidget applies AI-assisted adjustments that address many core WCAG needs so users benefit immediately while deeper fixes roll out. This includes keyboard support, focus management and visible focus styles, screen-reader compatibility cues, and on-page controls for contrast and text size. accessWidget can be tailored to your site and paired with expert work, allowing you to make fast progress without relying solely on shortcuts.
Additional help for complex websites
accessiBe offers two deeper layers of support for high-stakes scenarios:
MTCR (Manual testing and custom remediation)
Certified accessibility experts manually test critical user journeys with assistive technologies, identify root-cause code issues, and deliver targeted fixes or implementation guidance. This can include custom configurations for accessWidget, refined ARIA patterns, and component-level remediation your developers can ship quickly.
Litigation Support
If you receive a demand letter or lawsuit, accessiBe provides you with a dedicated case manager, expert analysis of each alleged violation, tailored response documentation that shows your accessibility posture, and consultation with an ADA attorney. Additionally, depending on your plan, you will be eligible to a monetary pledge of $15k+ to cover damages (terms and conditions apply). The goal is to help you respond confidently while continuing real accessibility improvements.
Make sure all your digital assets are compliant
accessServices - accessiBe’s team of accessibility experts, provides human expertise where automation alone will not suffice. Services include PDF and Office remediation with proper tagging and reading order, user testing by people with disabilities, and full expert audits with prioritized action plans. Deliverables are production-ready and documented so teams can prevent regressions.
Build compliant digital experiences at the source code level
An accessibility management platform for developers, accessFlow integrates accessibility testing and remediation directly into existing development workflows. It automatically scans websites using a headless browser to detect WCAG 2.1 violations, ranks issues by severity, and provides developers with detailed guidance for fixes. Through its dashboard, teams can monitor accessibility status across projects, explore issue breakdowns, and define user journeys—like sign-up or checkout flows—to ensure critical paths remain accessible.
Built to embed accessibility into every stage of the software development lifecycle, accessFlow connects seamlessly with CI/CD pipelines and IDEs, enabling teams to identify and resolve issues before they reach production. Its AI-driven capabilities—like auto-resolving recurring problems, generating accurate alt text, and validating false positives—streamline remediation while improving precision.
Closing thoughts
ADA Title II and Title III differ in who they cover and how they’re enforced, but they point to the same outcome: accessible digital services. With WCAG 2.1 Level AA being the guiding document for compliance in terms of digital accessibility, relevant entities have a clear path toward fulfilling their legal obligations.
Providing the best in automation and human expertise, accessiBe is here to help you reach your compliance goals, end to end, and mitigate legal risk.
To talk to an accessibility expert today, press here.
Frequently asked questions on ADA Title II vs. Title III
Q1. What is the difference between ADA Title II and Title III?
A1. Title II covers government services (state and local). Title III covers public-facing businesses. Both expect accessible websites, apps, and documents.
Q2. Does the ADA apply to websites and mobile apps?
A2. Yes. Public entities must meet WCAG 2.1 AA under Title II, and private businesses are commonly evaluated against WCAG AA in Title III matters.
Q3. What are the ADA Title II website deadlines for 2026 and 2027?
A3. Larger public entities have a 2026 date, and smaller entities/special districts have a 2027 date. Build to WCAG 2.1 AA.
Q4. What is WCAG 2.1 AA, and does the ADA require it?
A4. WCAG 2.1 AA is the accessibility benchmark for web and app content. Title II explicitly uses it. Title III cases frequently rely on it in practice.
Q5. How do I make my website ADA accessible?
A5. Aim for WCAG 2.1 AA, combine automated checks with expert audits, fix templates/components, and remediate PDFs and media.
Q6. Do small businesses need ADA website accessibility?
A6. Yes. If you serve the public, you’re a public accommodation under Title III and should meet WCAG AA to reduce risk and improve usability.
Q7. Are accessibility overlays enough to meet ADA expectations?
A7. No single tool is sufficient. Interfaces can help users, but you still need code fixes, accessible content and documents, and ongoing testing.
Q8. What’s the difference between Section 508 and ADA Title II?
A8. Section 508 applies to federal agencies and their contractors, while ADA Title II applies to state and local governments. Both laws require accessible websites, apps, and documents that meet WCAG 2.1 Level AA, but they operate under different statutes. If you’re a state or local agency, complying with Title II already aligns with Section 508 standards—you don’t need to meet both separately.
