Accessibility Statements Under the EAA: What an AI Design Agent Can Verify and What It Cannot
For design-system maintainers, an accessibility statement is usually treated as prose: a page you write once, publish, and forget. This post argues for a different model. The statement is better understood as a structured, partially machine-checkable claim set. That reframing answers two questions directly: what criteria can an AI design agent compute, and what tools does it need to do so? The claim here is not that an agent can certify compliance. It is that an agent can verify structure, detect drift, and flag what must stay human.
1. The statement as a claim object, not a document
Article 13(2) of Directive (EU) 2019/882 requires service providers to “prepare the necessary information in accordance with Annex V and shall explain how the services meet the applicable accessibility requirements” (getaccessguard.com). That sentence is a bundle of assertions: a standard is named, a conformance status is implied, a process is described, a feedback route is offered. An agent that can parse those assertions into a schema can run checks against them.
The primary EUR-Lex text at EUR-Lex was not reachable during research. Every Directive quotation in this post comes from secondary sources and is unverified against the Official Journal. That caveat applies throughout; it is not repeated in every sentence.
The practical opportunity for design agents is not legal interpretation. It is consistency maintenance: when a design system changes, does the statement’s named standard, dates, and limitations stay coherent?
2. What Annex V actually asks for (and what it doesn’t)
Annex V specifies content, not a form. Per secondary sources, the information must appear “in the general terms and conditions, or equivalent document” (getaccessguard.com; includora.com). Where applicable, it includes a general description of the service in accessible formats, descriptions and explanations needed to understand how the service operates, and a description of how the relevant Annex I accessibility requirements are met (getaccessguard.com).
Annex V point 3 states: “The service provider shall provide information demonstrating that the service delivery process and its monitoring ensure compliance” (getaccessguard.com; includora.com). Article 13(2) adds three conditions: the information must be available in written and oral format, accessible to persons with disabilities, and kept for as long as the service is in operation (getaccessguard.com). Article 13(3) requires procedures so the service “remains in conformity” as it changes (getaccessguard.com).
A clarification: the five-section model statement often cited in this context comes from Commission Implementing Decision (EU) 2018/1523, a Web Accessibility Directive (2016/2102) template for public-sector bodies. It is not an EAA requirement (wcagc.com). The EAA does not prescribe a fixed template. An agent must not treat the 2018/1523 sections as a legal checklist for EAA statements.
3. The machine-check table
Rating scale: COMPUTABLE means a deterministic check over text or structured data. PARTIAL means the agent can check presence, format, or internal consistency but not truth. NOT COMPUTABLE means the claim asserts something outside the document artifact.
| Statement element | Agent-computable check | Verdict | Reason |
|---|---|---|---|
| Standard named | Statement names a standard + version (e.g., “WCAG 2.2 Level AA”, “EN 301 549”); version matches current EN 301 549 web clauses per W3C | COMPUTABLE | String/schema extraction; version cross-reference against w3.org and ETSI listings |
| Conformance status | Status word present (fully/partially/not — pattern from the 2018/1523 model, per wcagc.com); overclaim phrases (“100% accessible”, “fully compliant with the European Accessibility Act”) flagged | PARTIAL | Agent can detect the claim and flag overclaims; it cannot verify the claim’s truth — conformance is decided by national market surveillance authorities (getaccessguard.com) |
| Known limitations | Limitations section exists, is dated, lists specific content | PARTIAL | Presence, dating, and specificity are checkable; whether a limitation is honest and complete is not |
| Feedback route | Contact channels present (email + phone per getaccessguard synthesis); response time stated | COMPUTABLE | Structural presence check |
| Dates | Preparation/review dates present and parseable; not stale relative to service changes | COMPUTABLE | Date parsing and freshness heuristics; WCAG 2.2’s own publication/update dates (W3C) show why version+date pairing matters |
| Monitoring/process | Statement describes testing and monitoring process (Annex V point 3 language) | NOT COMPUTABLE | The claim asserts a process, not a document artifact; no machine-readable evidence exists |
4. Why the boundary sits where it does
The automation-coverage evidence is often misread. Deque’s 2021 study (2,000+ audits, ~300,000 issues) found that automated testing completely covered 57% of issues (Deque). That is an issue-volume share, not a share of criteria. The ~30% figure is the different metric Deque is arguing against: the share of WCAG success criteria a tool can evaluate, which Deque says understates issue coverage (Deque). The two figures must never be conflated.
WCAG 2.2 was published 5 October 2023 and updated 12 December 2024; it adds 9 success criteria over 2.1 and removes 4.1.1 Parsing as obsolete (w3.org). W3C states: “Content that meets WCAG 2.2 also meets WCAG 2.1 and WCAG 2.0” (w3.org).
The boundary for agents is therefore not arbitrary. Structural checks live in the computable half. Truth-bearing claims about actual conformance live in the human half. An agent that respects that boundary is useful; one that crosses it produces false assurance.
5. The EN 301 549 version conflict, handled in the open
The version conflict is real and must be stated plainly.
One secondary source, dated 2026-07-07, says EN 301 549 “currently incorporates WCAG 2.1 Level AA” (wcagc.com). Another says ETSI published EN 301 549 v4.1.1 in September 2026, with web clauses pointing at WCAG 2.2, and that no version has been cited in the Official Journal under the EAA yet (getaccessguard.com). W3C, fetched directly, states: “The 2026 version of EN 301 549 uses WCAG 2.2” (w3.org).
The 2026 EN 301 549 uses WCAG 2.2 per W3C and getaccessguard. wcagc’s 2026-07-07 post predates the September 2026 V4.1.1 release that getaccessguard reports, so it most likely reflects the earlier version. Deque independently confirms v4.1.1 was published on 2 September 2026. Whether V4.1.1 exists as described rests on secondary claims only; the Commission’s M/587 page is the primary place to check standard changes. The safest phrasing is “current version per W3C; check ETSI for the version number”.
Agent takeaway: version drift is itself a computable check — does the statement name a standard version, and does that version match the current EN 301 549 web clauses?
6. What an agent must refuse to certify
Conformance status is decided by national market surveillance authorities, not by the provider’s page. One secondary source puts it bluntly: “Avoid writing ‘compliant with the European Accessibility Act’ at all” (getaccessguard.com).
The overclaim pattern is easy to flag: “100% accessible and fully compliant with the European Accessibility Act” (getaccessguard.com). The honest pattern is “partially conforms to WCAG 2.2 Level AA” with dated known limitations (getaccessguard.com). That example is illustrative and fictional; it is not a real claim.
The accessiBe/FTC caution belongs here, carefully. The FTC final order of April 2025 required accessiBe to pay $1,000,000 over claims a product could make any website WCAG compliant (via wcagc.com; the FTC order itself was not fetched and is not linked). This is a US FTC matter about product claims, not an EAA case. It supports the rule that no tool makes a site compliant. It must never be used as an EAA enforcement example.
7. Tools the agent needs
Machine-readable foundations exist today: WCAG JSON files are available via github.com/w3c/wcag and 11ty/json (w3.org). An agent can ingest those to resolve standard names and versions.
The missing piece is a statement schema: parse the statement into a structured claim object, run per-claim checks, and flag NOT COMPUTABLE items for human review. The agent’s honest output is a triage report, not a verdict.
Table A — Statement element → what the agent checks → what stays human:
| Statement element | Agent-verifiable signal | Human-required judgment | Typical failure mode |
|---|---|---|---|
| Standard named | Version string present; cross-reference to W3C/ETSI | Whether the named standard is the right one for the service | Stale version (WCAG 2.1 vs 2.2) |
| Conformance status | Status word present; overclaim phrases flagged | Whether the status is true | “Fully compliant” overclaim |
| Known limitations | Section exists, dated, specific | Whether limitations are honest and complete | Vague or undated limitations |
| Feedback route | Email + phone + response time present | Whether the route actually works | Missing oral channel |
| Dates | Dates parseable; freshness heuristic | Whether dates reflect real review cycles | Stale review date |
| Monitoring/process | Process description present | Whether monitoring actually happens | Process claim with no evidence |
8. FAQ
Does the EAA require a specific statement template? No. Annex V specifies content; the five-section model is the 2018/1523 public-sector template under the Web Accessibility Directive 2016/2102 (wcagc.com). The EAA does not prescribe a fixed template.
Can an AI agent tell me if my statement is compliant? No. Conformance is decided by national market surveillance authorities, not by the provider’s page (getaccessguard.com). Agents can check structure and internal consistency only. This is not legal advice.
Which WCAG version does EN 301 549 use? The 2026 version uses WCAG 2.2 per W3C (w3.org) and getaccessguard (getaccessguard.com); wcagc’s WCAG 2.1 statement describes the prior version (wcagc.com). Current version per W3C; check ETSI for the version number.
What does the 57% automation figure actually mean? It is an issue-volume share from Deque’s 2021 study, not a criteria share (wcagc.com). The criteria-share estimate is ~30% (wcagc.com).
Do microenterprises have to do this? Per one secondary source, microenterprises providing services are exempt under Article 4(5) (getaccessguard.com). That is secondary and unverified; it is not legal advice.
When did this take effect? Measures applied since 28 June 2025 per Article 31(2), via getaccessguard (getaccessguard.com). Secondary and unverified.
9. The Bottom Line
The EAA accessibility statement is partially computable. Roughly the structural half of the claim set is agent-checkable: standard named, feedback route, dates, and the presence and specificity of limitations. The truth-bearing half — does the service actually meet Annex I requirements, does monitoring actually happen — is not. An AI design agent’s correct role is structured verification and drift detection, with an explicit refusal boundary at conformance claims. Agents that cross that boundary produce the false assurance the FTC order targeted.
10. How This Guide Was Built
This post is based on fetched sources and secondary reading. The primary EUR-Lex text at EUR-Lex was unreachable, so every Directive quotation is secondary and unverified against the Official Journal. The W3C WAI page and Deque’s study page were fetched directly. getaccessguard, includora, and wcagc are secondary quoting sources; the FTC order is cited via wcagc and was not fetched. No hands-on testing, audits, or tool runs were performed for this post. WCAG 2.2 facts come from the W3C overview page. A post about verifiable claims must label which of its own claims are unverified; this section does that.