The Americans with Disabilities Act (ADA) splits digital accessibility obligations into two tracks. Knowing which one applies to you determines everything from the standards you follow to who signs off on compliance. Title II covers public entities, such as government websites, public university portals, and state agency services. ADA Title III generally applies to private businesses that are ‘public accommodations’ (e.g., many retail, hospitality, healthcare, and private education providers).
Courts have not been uniform on how Title III applies to online-only services, but DOJ guidance makes clear that businesses open to the public must ensure their online offerings are accessible. Both can apply to digital services—including websites, mobile apps, and documents—but they operate differently: Title II now has a DOJ web rule with a defined technical standard, while Title III generally requires accessibility under broader nondiscrimination and effective-communication duties.
The disconnect happens when Legal sends over regulatory language that reads like tax code, Leadership wants a compliance road map by next quarter, and your product team needs to know what changes this sprint. Those three conversations rarely overlap. This turns accessibility into a checkbox exercise instead of something that works.
This guide connects the dots between ADA obligations and decisions your team can execute.
- Identify which title applies to your organization and what that means for your digital properties.
- Map ADA requirements to specific standards, workflows, and ownership models.
- Build a practical compliance road map with clear milestones and progress metrics.
- Assign accountability across design, content, development, and QA without needing legal expertise.
First, let’s clarify what Titles II and III require and why your website, app, and document strategy fall under their scope.
Scope of coverage (who’s included)
Title II applies to state and local governments (every department, agency, and program they run). When a public entity operates public libraries, DMV portals, city permitting systems, community college websites, or public transit apps, Title II covers its digital presence. Because Title II applies to state and local governments, accessibility requirements apply to their services, programs, and activities—including digital services—regardless of how they’re funded.
ADA Title III covers private entities that operate “places of public accommodation.” The law lists twelve categories. What matters for digital teams is if your business serves the public, your website and apps are part of that public accommodation. An insurance company’s policy portal, a hospital’s patient scheduling system, a retail chain’s e-commerce site, and a private university’s course registration are all Title III territory.
The digital footprint extends beyond your main website. Mobile apps count. Customer portals and self-service tools count. Digital kiosks, PDFs, interactive forms, third-party widgets, and video players all count. You don’t get a pass because a vendor built the tool or a contractor manages the content. Under Title II’s web rule, a public entity must ensure accessibility for content it provides directly or through contractual, licensing, or other arrangements (subject to limited exceptions like undue burden/fundamental alteration).
The practical difference between Title II and Title III mostly shows up in enforcement, but the baseline accessibility requirements look similar across both. WCAG conformance is commonly used as the yardstick in digital accessibility work. For Title II, DOJ’s rule requires conformance with WCAG 2.1 Level A and AA for covered web content and mobile apps; for Title III, WCAG is frequently used in settlements and litigation as a benchmark, even though Title III does not (today) have a single codified technical standard like Title II’s web rule.
The ADA’s nondiscrimination and effective-communication obligations have long applied to covered entities’ services, including those delivered digitally. DOJ’s Title II web rule adds specific, enforceable requirements for state and local government web content and mobile apps.
Entities covered (public vs. private)
Title II obligations sit with state and local government entities. It doesn’t cover federal agencies, which fall under Section 508. So, city websites, county health departments, public school districts, state universities, municipal courts, and public transportation systems all answer to Title II. The key qualifier is whether the organization is a state or local government entity (and therefore responsible for ensuring its services, programs, and activities are accessible).
Title III covers private businesses in twelve categories of public accommodation: hotels, restaurants, theaters, stores, service establishments, healthcare facilities, gyms, parks, private schools, recreation centers, and professional offices. If the public can walk through your door or log in to your service, Title III likely applies. That includes private hospitals, retail chains, insurance companies, banks, law firms, and private universities.
Where it gets interesting is when public and private entities overlap. A private vendor building a city’s permitting portal doesn’t inherit Title II obligations. The city remains responsible for accessibility even though someone else wrote the code.
The same goes the other way. If you’re a private business using a third-party booking system or payment processor, Title III obligations stay with you. The contract might spell out who fixes what, but liability doesn’t transfer because a vendor owns the infrastructure.
Partnerships add another layer. A private healthcare system contracting with a state Medicaid program needs to meet accessibility standards for those services, even if the rest of their digital presence might have different requirements. Public universities licensing learning management systems from private companies still own the accessibility outcomes for students, regardless of what the LMS vendor provides by default.
Accessibility requirements (what you need to do)
WCAG 2.1 is the most common technical benchmark used for digital accessibility. For Title II entities, WCAG 2.1 Level A and AA is required under DOJ’s 2024 rule for covered web content and mobile apps. For Title III, WCAG is frequently used as the benchmark in litigation and settlements, but the legal obligation is framed in terms of nondiscrimination and effective communication rather than a single codified technical standard.
These guidelines have become the benchmark for digital accessibility. For Title II entities, it’s mandatory under the DOJ’s 2024 rule. For Title III, it’s what courts cite when evaluating accessibility lawsuits. This standard organizes around four principles: perceivable, operable, understandable, and robust. However, what matters for your team are the success criteria that those principles create.
Effective communication requires covered entities to provide communication that is as effective for people with disabilities as it is for others. Separately, both Title II and Title III have requirements around reasonable modifications to policies, practices, or procedures (with limits such as fundamental alteration).
The table below shows what that looks like in your daily work.
| Requirement | What it means in practice |
|---|---|
| Alt text | Descriptive alt text for images, not "image1.jpg" or blank |
| Captions and transcripts | Video gets captions, audio gets transcripts; auto-generated doesn't count unless verified |
| Keyboard navigation | Every interactive element works without a mouse |
| Color contrast | Text meets 4.5:1 ratio (3:1 for large text) against backgrounds |
| Form labels | Clear labels and error messages, not placeholder text as instructions |
| Heading structure | Logical H1-H6 hierarchy that screen readers can navigate |
| Link context | "Download the application form," not "Click here" |
| Sign language interpretation | Video content includes sign language interpretation or clear alternatives for deaf users |
These requirements need to live in your workflow. This means that designers should choose accessible color palettes and build keyboard navigation into prototypes, content writers must add alt text while they’re drafting, and developers need to code with semantic HTML and test with keyboards and screen readers as they build. QA should catch accessibility issues before anything ships, and someone must own periodic audits because even good processes let problems slip through over time.
Don’t forget PDFs, Word docs, and Excel files. They fall under the same requirements as your website. Start with accessible templates instead of trying to remediate hundreds of legacy files later.
All digital content should be made accessible. In practice, many organizations use WCAG-aligned requirements across websites, documents, and multimedia—but the exact legal standard and enforcement posture can differ depending on whether you’re under Title II or Title III.
Examples of compliance (what good looks like)
Good compliance doesn’t mean perfect from day one. It means you’ve knocked out the critical barriers, woven accessibility into how your team works, and can prove things are getting better quarter after quarter.
Websites and mobile apps
Start with semantic HTML that matches how content works, not just how it looks. Headings should reflect real hierarchy: H1 for the page title, H2s for major sections, and H3s nested under those. That structure lets screen reader users navigate by jumping between sections instead of listening to everything linearly.
Forms need labels explicitly tied to their inputs, not solely positioned nearby. When something breaks, error messages should explain what went wrong and how to fix it. And because invisible focus is a maze with no exit signs, make sure focus indicators show keyboard users where they are on the page.
Mobile apps follow similar rules with platform-specific tweaks. VoiceOver and TalkBack support lets screen readers parse what’s on screen. Touch targets should be large enough to activate reliably (and spacing should prevent accidental taps), especially on mobile. Text should reflow when users increase font size. A banking app passes when someone using a screen reader can check balances, transfer money, and pay bills without workarounds.
When evaluating your web content for accessibility, test with assistive technology, not only automated scanners. Real users with screen readers will reveal issues that algorithms miss.
Documents and multimedia
PDFs trip up more teams than anything else. Hitting “print to PDF” doesn’t create an accessible structure. Instead, start with accessible source documents, such as Word or InDesign files with real headings, alt text for images, and logical reading order. Build accessibility into your templates once, and everything generated from them inherits the structure.
Video captions need dialogue, speaker identification, and relevant sound effects. Audio descriptions fill in visual information that the narration doesn’t cover. If your training video shows software clicks without narrating them, descriptions explain what’s happening on screen.
Show progress over time
Progress shows up in metrics trending upward. To make those trends easier to prove, some teams use platforms like Siteimprove.ai to continuously surface new issues as content changes and to document what was fixed, when, and where—so progress doesn’t depend on one-off audits.
Fewer critical issues in audits. Faster turnaround when problems surface. Accessibility checks in QA, not after launch. Component libraries accelerate this. When your design system ships accessible patterns by default, teams stop recreating the same problems every sprint.
Impact on teams and budget
Accessibility doesn’t require hiring a new team, but it does shift how your current one works. Designers start checking color contrast in their mockups. Content writers add alt text while drafting instead of backfilling it later. Developers test with keyboards and screen readers as they build. QA adds accessibility to their checklist. Product owners prioritize fixes alongside new features instead of letting the backlog pile up forever.
Budget depends on your starting point. Sites with foundational issues (broken heading hierarchy, unlabeled forms, missing alt text) need significant upfront investment to fix structural problems. Work this in phases: critical barriers that completely block access first, then high-impact friction points, and then everything else.
Once you’ve addressed the backlog, accessibility becomes part of normal velocity. Teams move more slowly initially while building new habits then speed up once accessible patterns become second nature. Integrated accessibility costs less than retrofitting after launch, especially when you factor in legal risk.
Start with high-traffic, high-value pages: homepage, main navigation, checkout, account management, and top landing pages. Prioritize pages tied to critical tasks, such as applying for services or completing transactions. Assign clear ownership. Someone needs to own strategy; another person needs to track issues. Each discipline needs accountability for their part.
Note: This article is for informational purposes only and does not constitute legal advice. For guidance on how these requirements apply to your specific organization, consult qualified counsel.
Compliance risks and responsibilities
ADA compliance translates into business accountability through enforcement mechanisms and legal exposure. Title II entities face DOJ enforcement with specific compliance dates: April 24, 2026 for most public entities serving a population of 50,000+, and April 26, 2027 for public entities serving under 50,000 and for special district governments.
Miss those, and you’re dealing with investigations, settlement agreements or court orders, and litigation costs (including attorney’s fees), and in some cases damages under applicable remedies. Title III entities face ongoing private lawsuits with no deadline to hit, which means continuous exposure. Demand letters request settlements, legal fees pile up, and remediation costs accumulate even when cases settle quickly.
You’re responsible for third-party tools, too. That chatbot, payment processor, or CMS you licensed? Liability stays with you even when vendors built it, subject to limited exceptions like undue burden/fundamental alteration. Contracts can define who fixes what, but accessibility obligations don’t transfer.
Building internal ownership means assigning clear roles without needing legal experts on call. Someone owns accessibility strategy (usually a product or digital experience lead). An ADA coordinator role (whether formal or informal) makes sure someone tracks compliance status and coordinates responses to accessibility concerns. Someone tracks and audits issues (QA or an accessibility specialist). Each discipline (design, content, or dev) owns their part of the workflow. This creates accountability without routing every decision through Legal.
The following table shows what maintaining compliance across properties does.
| Strategy | What it does |
|---|---|
| Continuous monitoring | Catches new issues as content and features ship |
| Regular audits | Validates progress and identifies patterns |
| Remediation tracking | Documents fixes and timelines for remaining work |
| Centralized reporting | Gives leadership visibiloty without technical deep dives |
If you want a lightweight way to keep leadership informed without constant manual updates, a platform like Siteimprove.ai can consolidate monitoring results, audit findings, and remediation status into one reporting view.
Accessibility platforms, such as Siteimprove.ai, automate the monitoring and tracking piece. Continuous scans flag issues across your digital footprint, detailed reports show what needs fixing and why, and dashboards track remediation progress over time. This shifts accessibility from periodic panic audits to an operational system that runs alongside your normal workflows.
What to do next: Your accessibility road map
You know which title applies to you and what the requirements look like. Now you need to do something about it.
Run a baseline audit on your highest-traffic pages and critical flows. Find out where the biggest barriers are, assign someone to own the fixes, and set deadlines you can hit. Then weave accessibility into how your team already works instead of treating it like a separate compliance project.
Track what’s getting better: fewer critical issues appearing in audits, faster turnaround on fixes, accessibility checks during launch instead of after. Platforms run continuous monitoring so that issues surface when they happen instead of six months later. See how Siteimprove.ai works in your workflow today.
Ilyssa Russ
Ilyssa leads the charge for Accessibility product marketing! All things assistive technology and inclusive digital environments. She has spent years designing and curating Learning & Development programs that scale. Teacher and writer at heart. She believes in the power of language that makes things happen.