EAA Compliance Framework

This Framework validates European Accessibility Act (EAA) compliance and provides evidence for litigation defense. The EAA requires all public sector and private sector websites and digital services in EU member states to meet WCAG 2.1 Level AA accessibility standards.

The EAA (Directive (EU) 2019/882) was adopted in April 2019 and phased into effect based on organization size. Public sector and large private sector organizations (250+ employees or €50M+ revenue) faced a June 28, 2025 compliance deadline. Medium enterprises must comply by June 28, 2027, and small enterprises by June 28, 2028

This Framework 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:

The framework aligns with the WCAG 2.1 POUR principles:

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:

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

If you find that you are having trouble determining how many pages exist on a domain, talk to your Success Manager or our Support Team and ask about running a Site Census scan.

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.

POUR Principle: PERCEIVABLE

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: WCAG 2.1 Success Criterion 1.1.1 Non-text Content (Level A); European Accessibility Act, Directive (EU) 2019/882

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).

POUR Principles: OPERABLE / UNDERSTANDABLE

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 and regulatory exposure.

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); European Accessibility Act, Directive (EU) 2019/882

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)

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 Criteria: 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 Criterion 2.4.3 Focus Order (Level A) & 2.4.7 Focus Visible (Level AA)

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.

POUR Principle: UNDERSTANDABLE

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)

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)

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.

POUR Principle: PERCEIVABLE

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)

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)

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

POUR Principle: PERCEIVABLE

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)

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)

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.

POUR Principles: OPERABLE / ROBUST

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)

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 Criteria 2.1.1 Keyboard (Level A)

Automated scanning detects 30–40% of WCAG criteria. Manual testing verifies meaning, functionality, and compatibility with assistive technologies. This evidence is essential for both compliance and litigation defense.

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

The EAA requires organizations to publish a clear, publicly accessible statement detailing their accessibility conformance level and any known limitations. This statement must be easy to find and must include contact information for users to report accessibility issues.

Content to Include: Conformance statement (e.g., "This website conforms to WCAG 2.1 Level AA"), Date of last review/assessment, Known limitations or exemptions (if any), Contact email or form for accessibility feedback, Escalation path if initial contact does not resolve the issue.

Document your compliance status and the date of your most recent accessibility assessment. Update this log quarterly as part of your scheduled accessibility reviews. This log becomes evidence of a systematic, ongoing compliance program and feeds your public accessibility statement.

Content to Include: Current WCAG 2.1 Level AA conformance claim, Date of last audit run, Scope of assessment (which pages/domains), Known non-conformances and remediation timeline, Manual/assistive-technology testing results.

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

A centralized log of accessibility findings, detection dates, remediation dates, and status. This document proves that your organization detects violations, prioritizes them, and remediates 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.

Users must have a simple way to report accessibility barriers (email, web form, or phone). Document your response process with a target resolution time (15 days best practice). Log all feedback, track remediation, and communicate back to users when issues are fixed. This mechanism is mandatory under EAA Article 4(3) and serves as evidence of good-faith compliance and responsiveness to accessibility issues.

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 and demonstrates EAA compliance readiness.

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 EAA compliance 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 required under the EAA.

If your organization sells into EU public sector 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.

If you claim that remediation of any accessibility violation would be disproportionate to your organization's resources, document the business case and store it with your compliance records. The EAA allows exemptions for disproportionate burden, but this exemption is interpreted narrowly and must be justified. Maintain records of cost estimates, remediation timelines, and business impact assessments.

This framework is designed to establish and defend a systematic accessibility program under 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.

The EAA's June 2025 deadline for large organizations has passed. Organizations not yet in compliance face significant liability and regulatory scrutiny. 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 EAA case law develops across EU member states.

Reach out to your Customer Success Manager to set up your accessibility audit schedule and begin building your compliance evidence today.