The Americans with Disabilities Act, commonly known as the ADA, is a United States
civil-rights law that prohibits discrimination against people with disabilities.
The law applies across areas such as employment, state and local government services,
businesses open to the public, transportation and telecommunications.
Website and mobile-app accessibility are relevant because many essential services,
purchases, applications, appointments and public programmes are now delivered
digitally. An inaccessible digital experience can prevent a person with a disability
from receiving the same goods, services, information or opportunities available to
other users.
What is the Americans with Disabilities Act?
The ADA was signed into law in 1990. Its purpose is to ensure that people with
disabilities have equal access and opportunity in areas of public life covered by
the Act.
The ADA is divided into several titles, each addressing a different area.
Title I: Employment
Prohibits disability discrimination in employment and requires reasonable
accommodations for qualified employees and applicants, subject to the law’s
conditions and limitations.
Title II: State and local governments
Covers services, programmes and activities provided by state and local government
entities.
Title III: Businesses open to the public
Covers public accommodations such as retailers, restaurants, hotels, banks,
healthcare providers, theatres and private education providers.
Title IV: Telecommunications
Addresses accessible telecommunications services for people with hearing and
speech disabilities.
Title V: Miscellaneous provisions
Contains provisions concerning the ADA’s relationship with other laws,
retaliation, attorney fees and other matters.
Does the ADA apply to websites?
The ADA was enacted before modern websites, mobile applications and online commerce
became central to daily life. It does not contain a standalone chapter titled
“website accessibility.”
However, the United States Department of Justice has consistently taken the position
that ADA requirements apply to the goods, services, programmes and activities that
covered organisations provide online.
A digital barrier can therefore create an ADA problem when it prevents a person with
a disability from obtaining equal access to:
- A government programme or service.
- A retail purchase.
- A hotel or travel booking.
- A medical appointment.
- A banking or financial service.
- An educational programme.
- An employment application.
- A customer-support service.
- A ticket or event reservation.
ADA Title II and digital accessibility
Title II applies to state and local governments. It prohibits disability
discrimination in their services, programmes and activities.
Covered public entities may include:
- State governments.
- Counties.
- Cities and towns.
- Public schools.
- Public colleges and universities.
- Police and emergency services.
- Public libraries.
- Public hospitals and health departments.
- Transit authorities.
- Special district governments.
Title II applies to web content and mobile applications that a public entity provides
directly or makes available through contractual, licensing or other arrangements.
The ADA Title II web and mobile-app rule
In 2024, the Department of Justice published a final rule establishing a specific
technical accessibility standard for web content and mobile applications provided by
state and local governments.
The required technical standard is:
WCAG 2.1 Level A and Level AA.
Following an interim final rule published in April 2026, the compliance dates are:
-
April 26, 2027:
public entities with a total population of 50,000 or more. -
April 26, 2028:
public entities with a total population below 50,000 and special district
governments.
Organisations should verify their classification, applicable exceptions and current
compliance date through official Department of Justice resources.
What Title II digital content can be covered?
Covered content may include:
- Government websites.
- Mobile applications.
- Online forms.
- Payment portals.
- Public meeting information.
- Voting and election information.
- School registration systems.
- Public-benefit applications.
- Emergency information.
- Documents and downloadable files.
- Third-party services supplied under contract.
A public entity cannot automatically avoid responsibility by using a third-party
vendor. Contracted or licensed content may still fall within the rule.
Title II exceptions
The Title II rule contains limited exceptions for certain content. Depending on the
circumstances, these may include:
- Archived web content meeting the rule’s conditions.
- Certain pre-existing conventional electronic documents.
- Content posted by third parties where the content is not posted on behalf of the public entity.
- Individualised password-protected documents in specified circumstances.
- Pre-existing social-media posts.
An exception should not be assumed solely because content is old, externally hosted
or difficult to remediate. The precise conditions in the rule must be reviewed.
Fundamental alteration and undue burdens
The Title II rule recognises limitations where conformance would fundamentally alter
the nature of a service, programme or activity, or create undue financial and
administrative burdens.
These limitations are narrow and require an appropriate assessment. Even where a
limitation applies, the public entity should take other action that provides people
with disabilities access to the greatest extent possible.
ADA Title III and business websites
Title III applies to businesses and nonprofit organisations that operate places of
public accommodation.
Examples include:
- Retail stores.
- Restaurants and cafés.
- Hotels and lodging businesses.
- Banks.
- Medical offices and private hospitals.
- Theatres and entertainment venues.
- Gyms and recreation facilities.
- Private schools.
- Day-care centres.
- Professional courses and examination providers.
Title III generally requires covered businesses to provide people with disabilities
an equal opportunity to access their goods and services and to communicate effectively
where necessary.
Is there a Title III WCAG regulation?
Unlike the current Title II web and mobile-app rule, Title III does not currently
contain a federal Department of Justice regulation requiring all covered business
websites to meet one specified version of WCAG.
Businesses still must satisfy the ADA’s requirements for nondiscrimination, equal
access and effective communication.
WCAG is widely used as the primary technical framework for evaluating whether website
and application content is accessible. Court settlements, consent decrees, contracts
and organisational policies may also identify a particular WCAG version or level.
Businesses should not interpret the absence of one Title III technical regulation as
permission to leave digital barriers unresolved.
Why court decisions can differ
Federal courts have not applied one identical legal interpretation to every Title III
website case.
Questions that have arisen include:
- Whether a website must have a connection to a physical place.
- Whether an online-only business can be a public accommodation.
- Whether the plaintiff has standing to bring the claim.
- Whether the requested modification is reasonable.
- Whether effective alternative access was provided.
Results can vary by federal circuit, facts, business model and the specific digital
barrier. Organisations should obtain qualified legal advice when assessing litigation
exposure or a particular complaint.
ADA website accessibility and WCAG
The Web Content Accessibility Guidelines provide testable criteria for making web
content more accessible to people with disabilities.
WCAG is organised around four principles.
Perceivable
Information must be available in forms that users can perceive, such as text
alternatives, captions and adaptable page structures.
Operable
Users must be able to navigate and operate interfaces with keyboards, assistive
technologies and supported input methods.
Understandable
Content, navigation, instructions and errors should be clear and predictable.
Robust
Content and controls should be compatible with browsers, platforms and assistive
technologies.
Learn more about the
Web Content Accessibility Guidelines.
Common website accessibility barriers
- Images without meaningful alternative text.
- Buttons without accessible names.
- Forms without persistent labels.
- Error messages that are not announced to screen readers.
- Menus and dialogs that cannot be operated with a keyboard.
- Missing or hidden keyboard-focus indicators.
- Insufficient text and component contrast.
- Videos without captions.
- Documents without accessible structure or reading order.
- Text that cannot be enlarged without content loss.
- Touch targets that are difficult to activate.
- Authentication processes that create disability-related barriers.
- Dynamic content changes that are not communicated to assistive technologies.
Accessible online forms
Forms are frequently involved in important ADA-related user journeys, including
purchasing, registration, applications and requests for services.
Accessible forms should provide:
- Visible, programmatically associated labels.
- Clear instructions.
- Identification of required fields.
- Accessible error messages.
- Suggestions for correcting invalid information.
- Logical keyboard navigation.
- Review and correction opportunities for important transactions.
- Accessible confirmation of successful submission.
A form should be tested from beginning to end rather than reviewed only as a
collection of separate input fields.
Keyboard accessibility
Users who cannot operate a mouse must still be able to reach and use every important
interactive feature.
Keyboard testing should confirm that:
- All interactive elements receive focus.
- Focus moves in a logical order.
- Focus is clearly visible.
- Buttons and links respond to expected keys.
- Menus, tabs and dialogs support appropriate interaction.
- Focus does not become trapped.
- Hidden content is not left in the tab sequence.
Read the practical guide to
ARIA and keyboard accessibility
.
Images and alternative text
Informative images require text alternatives that communicate their purpose or
meaning.
Alternative text should:
- Describe the relevant information, not every visual detail.
- Reflect the image’s purpose in context.
- Avoid repeating nearby text unnecessarily.
- Leave decorative images hidden from assistive technologies.
- Provide longer explanations for complex charts when needed.
Automatically generated alternative text should be reviewed by a person who
understands the image and its context.
Video, audio and multimedia
Multimedia accessibility can include:
- Accurate captions for spoken content.
- Identification of speakers.
- Communication of important sounds.
- Audio description for essential visual information.
- Transcripts where appropriate.
- Keyboard-accessible media controls.
- Clearly labelled play, pause, volume and caption controls.
Automatically produced captions may contain significant errors and should be
reviewed before publication.
Mobile-app accessibility
ADA-related digital access is not limited to desktop websites. Mobile applications
may be the primary way users access a service.
Mobile testing should consider:
- Screen-reader navigation.
- Accessible names, roles and states.
- Logical swipe order.
- External-keyboard support.
- Text enlargement.
- Colour contrast.
- Orientation.
- Touch-target size.
- Accessible gestures.
- Error handling.
- Platform accessibility settings.
Electronic documents
Important information is often delivered through PDF, Word, spreadsheet and
presentation files.
Document accessibility may require:
- A meaningful document title.
- Correct document language.
- Logical headings.
- Correct reading order.
- Alternative text for images.
- Accessible tables.
- Descriptive links.
- Accessible form fields.
- Sufficient colour contrast.
Publishing an inaccessible PDF alongside an accessible webpage can still prevent
users from obtaining essential information.
Third-party content and services
Websites frequently depend on third-party components such as:
- Payment systems.
- Booking engines.
- Customer-support chat.
- Authentication services.
- Maps.
- Video players.
- Recruitment platforms.
- Document viewers.
An organisation should not assume that responsibility disappears because a barrier
is created by a vendor.
Vendor contracts should define:
- Required accessibility standards.
- Testing responsibilities.
- Known limitations.
- Remediation timelines.
- Verification requirements.
- Responsibilities after updates.
Is telephone access an adequate alternative?
Telephone assistance may be useful as an additional support channel, but it is not
automatically equivalent to an accessible website or application.
An alternative may be inferior when it:
- Is available for fewer hours.
- Requires a longer waiting period.
- Prevents independent use.
- Provides fewer products or services.
- Requires disclosure of private information to an employee.
- Charges an additional fee.
The stronger approach is to make the primary digital service accessible while also
maintaining accessible support options.
Automated testing is not enough
Automated scanners can identify many technical issues quickly, but they cannot
determine complete accessibility or ADA compliance.
Automated testing may detect:
- Missing attributes.
- Some contrast failures.
- Duplicate identifiers.
- Invalid ARIA.
- Some missing form labels.
- Structural problems.
Manual review is required to assess:
- Whether alternative text is meaningful.
- Whether keyboard interaction works logically.
- Whether screen-reader announcements are understandable.
- Whether form errors support successful correction.
- Whether a complete transaction can be finished.
- Whether an alternative method provides equivalent access.
How to perform an ADA website audit
-
Define the scope:
identify websites, applications, documents, third-party services and critical
journeys. -
Identify the applicable ADA title:
distinguish state and local government services from private public accommodations
and employment systems. -
Choose the technical baseline:
apply WCAG 2.1 AA where required and an appropriate current WCAG framework for
broader testing. -
Run automated testing:
identify repeatable technical issues across representative pages. -
Perform keyboard testing:
verify all important interactions without a mouse. -
Test with assistive technologies:
review critical journeys with screen readers and other relevant tools. -
Review content and documents:
assess images, headings, multimedia, forms and downloadable files. -
Document findings:
record user impact, evidence, affected components and relevant success criteria. -
Assign remediation:
route work to design, development, content, product or vendors. -
Verify corrections:
retest fixes before closing findings.
Prioritising remediation
Not every finding has the same impact. Organisations should prioritise barriers
affecting essential tasks and large numbers of users.
High-priority journeys commonly include:
- Account registration.
- Authentication and password recovery.
- Purchasing and checkout.
- Medical scheduling.
- Applications for public benefits.
- Job applications.
- School registration.
- Emergency information.
- Payments and financial transactions.
- Submitting complaints or requesting help.
Shared components such as navigation, forms, dialogs and design-system controls
should often be corrected before isolated page-level issues because one correction
can remove barriers across many pages.
Accessibility policies and governance
Sustainable accessibility requires more than a one-time audit.
An accessibility programme should define:
- Executive accountability.
- Product and engineering responsibilities.
- Design-system requirements.
- Content-publishing procedures.
- Quality-assurance testing.
- Procurement requirements.
- User-feedback handling.
- Remediation priorities.
- Verification standards.
- Recurring monitoring.
Accessibility statements and feedback
A public accessibility statement can help users understand the organisation’s
accessibility commitment and request assistance.
A useful statement may include:
- The accessibility standard used.
- Known limitations.
- Available accessible alternatives.
- A method for reporting barriers.
- A method for requesting accessible information.
- The date of the most recent assessment.
The statement should be accurate and updated as the service changes. It should not
claim complete compliance without supporting evidence.
Documenting accessibility work
Organisations should preserve evidence of the accessibility process.
Useful records include:
- Audit dates and scope.
- Pages and workflows tested.
- Browsers and assistive technologies used.
- Automated and manual findings.
- User-impact descriptions.
- Assigned owners.
- Remediation decisions.
- Completed corrections.
- Verification results.
- Known limitations.
- User complaints and responses.
- Vendor accessibility records.
Documentation does not guarantee legal compliance, but it helps demonstrate that
accessibility is being managed through a deliberate and ongoing process.
ADA, Section 508 and state laws
The ADA should not be confused with Section 508.
Section 508 applies to information and communication technology developed, procured,
maintained or used by United States federal agencies.
The ADA applies through separate titles to employment, state and local governments
and businesses open to the public.
Organisations may also be affected by:
- State civil-rights laws.
- State consumer-protection laws.
- Education accessibility requirements.
- Healthcare regulations.
- Federal procurement requirements.
- Contractual accessibility commitments.
Read more about
Section 508 compliance.
How Pluro supports ADA accessibility work
Pluro is an accessibility workflow platform that helps organisations manage digital
accessibility findings from detection through verified remediation.
Teams can use Pluro to:
- Centralise automated and manual findings.
- Capture keyboard and behavioural evidence.
- Assign findings to responsible teams.
- Provide remediation guidance.
- Track issue status.
- Verify corrections.
- Maintain a history of accessibility work.
- Monitor websites after future changes.
Pluro is not an overlay, a one-click compliance product or a substitute for legal
advice. It provides workflow infrastructure for identifying barriers, coordinating
remediation and preserving evidence of verification.
ADA website accessibility checklist
- Determine which ADA title applies.
- Identify critical websites, applications and user journeys.
- Apply WCAG 2.1 AA where required by the Title II rule.
- Use an appropriate WCAG baseline for broader accessibility testing.
- Test keyboard navigation and focus.
- Test forms and error handling.
- Review images, media and documents.
- Test with relevant assistive technologies.
- Review third-party platforms and vendors.
- Assign and prioritise remediation.
- Verify corrections before closing findings.
- Provide an accessible feedback channel.
- Maintain evidence and monitoring after releases.
Important notice
This page provides general information and does not constitute legal advice.
ADA applicability and legal risk depend on the organisation, jurisdiction, service,
relevant title, user experience and current court decisions.
Review the official
Department of Justice web accessibility guidance
.
Review the official
ADA Title II web and mobile-app rule guidance
.
See how Pluro manages accessibility workflows
or
start a 14-day free trial
with no credit card required.