ADA Web Compliance Framework

This Framework validates ADA (Americans with Disabilities) compliance (Title III, Title II) and provides evidence for litigation defense. It aligns with ObservePoint's automated WCAG 2.1 AA scanning and recommended processes for a defensible accessibility program. Each Check includes ObservePoint reports and remediation steps provided in the linked guides.

This Framework is organized into the following Policies:

For each Check, we will include links to pre-built reports (when possible) in the ObservePoint Platform and an implementation & remediation guide.

Each check will be accompanied by an icon:

The ✅ icon represents a Check that is out-of-the-box available by just running an Audit.

The 🛠️ ✅ icon represents a Check that requires additional configuration.

Before diving into the specifics of each policy, we want to provide our recommendation around the scope and frequency of validating your ADA compliance posture.

Each check in this framework includes a remediation guide. These guides are based on official WCAG 2.2 documentation.

Each check points to the corresponding W3C remediation guide, so your organization has access to authoritative technical and legal resources to achieve compliance.

All accessibility data referenced in this framework is collected by default in ObservePoint Audits, regardless of configuration settings. For guidance on creating and configuring your first Accessibility Audit, see Create an Audit.

This policy represents checks that pertain to text alternatives for images and non-text content, ensuring that users relying on screen readers or other assistive technologies can access image-based information.

Images without text alternatives are inaccessible to screen-reader users and search engines. Users receive only "image" or a filename instead of understanding the image's purpose. This is one of the highest-volume, highest-impact violations detected by automated scanning.

WCAG Success Criterion: 1.1.1 Non-text Content (Level A)

Report in ObservePoint: Pages with images missing meaningful alt text

Remediation Guide: Link

Source citation: 29 U.S.C. § 794(d); ADA Title II, April 2024 DOJ Final Rule Web Content Accessibility

Images that are purely decorative (borders, spacing, visual elements that convey no meaning) must be hidden from screen readers by using an empty alt attribute (alt=""). This prevents unnecessary noise in the assistive-technology experience.

WCAG Success Criterion: 1.1.1 Non-text Content (Level A)

Report in ObservePoint: Pages with decorative images not properly marked (manual review required to confirm decorative intent)

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criterion 1.1.1 Non-text Content (Level A)

This policy represents checks ensuring that form fields, buttons, and interactive controls are properly labeled and identifiable to assistive-technology users, especially for transactional flows (checkout, account creation, loan applications).

Form fields without associated labels are inaccessible to screen-reader users. This is the "what is this field?" failure — especially critical on checkout and sign-in forms where usability breakdown translates directly to revenue loss.

WCAG Success Criteria: 1.3.1 Info and Relationships (Level A); 4.1.2 Name, Role, Value (Level A)

Report in ObservePoint: Pages with form inputs missing programmatic labels

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criteria 1.3.1 Info and Relationships (Level A) & 4.1.2 Name, Role, Value (Level A); Section 508, 29 U.S.C. § 794(d); ADA Title II, April 2024 DOJ Final Rule Web Content Accessibility

Buttons without visible or programmatic text (such as icon-only buttons) cannot be identified by screen-reader users. This blocks access to critical actions — "Place Order," "Submit," "Download," etc.

WCAG Success Criterion: 4.1.2 Name, Role, Value (Level A)

Report in ObservePoint: Pages with buttons missing accessible names

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criterion 4.1.2 Name, Role, Value (Level A); ADA Title III enforced via federal case law (e.g., *Domino's Pizza v. Robles*, 2021)

Keyboard and switch-access users navigate pages using Tab/Shift+Tab. They must see a visible focus indicator at all times, and the focus order must follow the visual/logical flow of the page. Pages with no visible focus, or with tab order that jumps around chaotically, are unusable.

WCAG Success Criterion: 2.4.3 Focus Order (Level A); 2.4.7 Focus Visible (Level AA)

Report in ObservePoint: Pages with keyboard focus not visible and logical

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criteria 2.4.3 Focus Order (Level A) & 2.4.7 Focus Visible (Level AA), 29 U.S.C. § 794(d)

This policy represents checks ensuring that page structure (headings, language, link text) is semantically correct, enabling screen-reader users to navigate and understand page content.

Screen-reader users navigate pages by headings. A broken heading hierarchy (skipping from h1 to h4, or using headings for visual size) produces a maze — users cannot skim the page structure or jump to relevant sections.

WCAG Success Criteria: 1.3.1 Info and Relationships (Level A); 2.4.6 Headings and Labels (Level AA)

Report in ObservePoint: Pages with heading hierarchy not correct and logical

Remediation Guide: Link 1.3.1, Link 2.4.6.

Source Citation: WCAG 2.1 Success Criteria 1.3.1 Info and Relationships (Level A) & 2.4.6 Headings and Labels (Level AA)

The <html> element's lang attribute must be set. Without it, screen readers may pronounce content in the wrong language, producing unintelligible output.

WCAG Success Criterion: 3.1.1 Language of Page (Level A)

Report in ObservePoint: Pages with language not declared

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criterion 3.1.1 Language of Page (Level A); ADA Title II, April 2024 DOJ Final Rule Web Content Accessibility

Links reading "click here," "read more," or showing raw URLs are non-descriptive. Screen-reader users tabbing through a page hear only "read more, read more, read more" without knowing the destination.

WCAG Success Criterion: 2.4.4 Link Purpose (In Context) (Level A)

Report in ObservePoint: Pages with link text not descriptive

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criterion 2.4.4 Link Purpose (In Context) (Level A); Section 508, 29 U.S.C. § 794(d)

This policy represents checks ensuring that text and interactive elements have sufficient contrast against their backgrounds, and that color is never the sole means of conveying information.

Low-contrast text is unreadable to low-vision users and anyone in bright lighting. WCAG 2.1 AA requires 4.5:1 contrast for normal text and 3:1 for large text (18pt+).

WCAG Success Criterion: 1.4.3 Contrast (Minimum) (Level AA)

Report in ObservePoint: Pages with text missing sufficient color contrast

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criterion 1.4.3 Contrast (Minimum) (Level AA); 29 U.S.C. § 794(d); ADA Title II, April 2024 DOJ Final Rule Web Content Accessibility

When differentiating UI elements (required vs. optional fields, errors, success states), color must be paired with text, icons, or other non-color cues. Color-blind users cannot distinguish information conveyed by color alone.

WCAG Success Criterion: 1.4.1 Use of Color (Level A)

Report in ObservePoint: Manual review required.

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criterion 1.4.1 Use of Color (Level A); ADA Title III

This policy represents checks ensuring that video and audio content is accessible to deaf, hard-of-hearing, and deafblind users.

Prerecorded video without captions is inaccessible to deaf and hard-of-hearing users. Note: ObservePoint automation detects the absence of a caption track; it cannot judge caption accuracy, which requires manual review.

WCAG Success Criterion: 1.2.2 Captions (Prerecorded) (Level A)

Report in ObservePoint: Pages with videos missing captions (manual inventory of video elements required)

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criterion 1.2.2 Captions (Prerecorded) (Level A); Section 508, 29 U.S.C. § 794(d)

Prerecorded audio (podcasts, interviews, webinars) without transcripts is inaccessible to deaf and deafblind users. Transcripts also improve SEO and provide alternative access for users in quiet/loud environments.

WCAG Success Criterion: 1.2.1 Audio-only and Video-only (Prerecorded) (Level A)

Report in ObservePoint: Manual review required.

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded) (Level A); ADA Title II, April 2024 DOJ Final Rule Web Content Accessibility

This policy represents checks ensuring that custom interactive components (tabs, modals, accordions, dropdowns) are properly implemented and that ARIA (Accessible Rich Internet Applications) attributes are used correctly.

ARIA is often misused: wrong roles, invalid attributes, or ARIA layered onto native elements that didn't need it. Incorrect ARIA is worse than no ARIA — it lies to assistive technology about what an element is.

WCAG Success Criterion: 4.1.2 Name, Role, Value (Level A)

Report in ObservePoint: Pages with incorrect and invalid ARIA attributes

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criterion 4.1.2 Name, Role, Value (Level A); Section 508, 29 U.S.C. § 794(d)

Custom interactive components (date pickers, autocomplete, tabs, carousels) must be navigable via keyboard and must maintain visible focus indicators. Keyboard users cannot use mouse-only interactions.

WCAG Success Criterion: 2.1.1 Keyboard (Level A); 2.4.3 Focus Order (Level A); 2.4.7 Focus Visible (Level AA)

Report in ObservePoint: Pages with custom widgets not keyboard-accessible (manual assistive-technology testing required)

Remediation Guide: Link

Source citation: WCAG 2.1 Success Criterion 2.1.1 Keyboard (Level A); ADA Title III

Automated scanning detects 30-40% of WCAG criteria. Manual testing verifies meaning, functionality, and compatibility with assistive technologies.

This policy represents recommended documentation and governance safeguards to establish a defensible accessibility program and mitigate litigation risk.

A documented schedule showing that your organization runs regular accessibility audits (daily, per-deployment, quarterly). Include audit scope (which pages), frequencies, and responsible teams. This demonstrates a good-faith, systematic compliance program — critical evidence in litigation.

A centralized log of accessibility findings, detection dates, and remediation dates. This document proves that your organization detects violations, prioritizes them, and remedies them within defined windows — not a reactive after-the-fact scramble.

A written statement of how your organization prioritizes accessibility work: severity × page exposure × affected population. Document which findings trigger a release gate (critical/serious on tier-1 templates) and which become a managed backlog. This framework is defensible and shows reasoned prioritization, not neglect.

Block deployments if new critical or serious accessibility violations are detected on tier-1 templates (checkout, login, forms, primary navigation). This enforcement architecture proves that accessibility is a mandatory, integrated part of your development process.

A recurring technical review (quarterly minimum) led by development and accessibility leads to assess trends, triage findings, and plan remediation. Document the attendees, the discussions, and the decisions made. This governance process becomes part of your defense evidence.

Automated scanning catches ~30-40% of WCAG violations. Supplement it with manual testing by people (ideally including people with disabilities) using screen readers, voice control, and other assistive technologies. Document test results, who performed them, and when. This evidence pairs with ObservePoint's automated scan to demonstrate a comprehensive accessibility program.

If your organization sells into federal agencies or is subject to procurement requirements, prepare an Accessibility Conformance Report (ACR), commonly delivered as a VPAT (Voluntary Product Accessibility Template). ObservePoint's scan history feeds the machine-testable portions; pair it with your manual-testing record. This document is both a compliance artifact and litigation evidence.

This framework is designed to establish and defend a systematic accessibility program under ADA Title III, ADA Title II, Section 508, and the European Accessibility Act. By automating high-volume scanning, prioritizing by impact, and documenting a continuous remediation process, you transform your website from a high-litigation-risk target into a defensible digital property.

ObservePoint will continue to expand its automated accessibility testing capabilities and provide integration with your development workflow. Expect this framework to evolve as WCAG standards advance and as new judicial precedents emerge. Reach out to your Customer Success Manager to set up your accessibility audit schedule