Accessibility Standards

Digital accessibility standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

Applies when you have to decide whether something conforms and prove it: which standard and which level is required, which specific conformance criterion is being failed, how it is tested, who signs the statement and what legal obligation sits behind it. Covers web content, web applications, documents and email. The conformance criterion is what belongs to this skill.

Triggers: WCAG 2.1 / 2.2, levels A / AA / AAA, a success criterion number (1.4.3, 2.4.7, 2.5.8, 4.1.2…), EN 301 549, Directive (EU) 2019/882 (European Accessibility Act), Directive (EU) 2016/2102, Ley 11/2023, Real Decreto 1112/2018, ADA Title II, Section 508, VPAT / ACR, accessibility statement, axe-core, @axe-core/playwright, @axe-core/react, jest-axe, pa11y / pa11y-ci / .pa11yci, Lighthouse's accessibility category, WAVE, ARC Toolkit, NVDA, JAWS, VoiceOver, TalkBack, Orca, accessible name, aria-*, role, aria-hidden, aria-live, tabindex, :focus-visible, outline, prefers-reduced-motion, prefers-contrast, alt, <label>/aria-labelledby, <caption>/<th scope>, captions, transcript, audio description, PDF/UA, accessibility overlay.

Thesis of this skill: accessibility is a requirement, not an enhancement. It is not prioritised against features: it is a feature. And in the EU it is, on top of that, a legal obligation whose deadline has already passed — Directive (EU) 2019/882, art. 31.2, verbatim: "They shall apply those measures from 28 June 2025." Operational corollary: an accessibility failure in production is a defect, with its bug and its regression test, not a backlog task tagged a11y. Second corollary, an uncomfortable one: automation cannot close it (§4.1) — whoever signs conformance is a person who has tested with a keyboard and with a screen reader.

Not applicable: see frontend-web-platform-standards (semantic HTML, CSS, browser APIs, the loading model and build tooling are theirs — which native element exists, how it is styled, which Baseline supports :focus-visible or prefers-contrast. Here, only the conformance criterion: what WCAG requires, at which level, how it is tested and who declares it. Choosing <button> instead of <div role="button"> is their decision; requiring it as conformance is this skill's), frontend-frameworks-standards (the framework and its rendering and routing model are theirs; here the measurable consequences: focus on route change in an SPA §3.5, the dialog component that traps focus, the status announcement after a mutation), design-systems-standards (the right place to solve accessibility once is a design-system component: the accessible button, field, dialog and menu are built there and audited there — not on every screen. Its governance, versioning and documentation are theirs; here the criterion that component must satisfy), web-performance-standards (sister skill: they meet at prefers-reduced-motion — here as a conformance criterion, there as a rendering cost — and at perceived speed; the budget and Core Web Vitals are theirs), grc-compliance-standards (the regulatory framework, audit evidence, the legal risk register and the relationship with the regulator; here the technical conformance criterion and its proof), mobile-standards (native app accessibility: UIAccessibility, AccessibilityNodeInfo, TalkBack/VoiceOver as platform APIs and each store's guidelines are theirs; here the web and the WebView), privacy-engineering-standards (personal data processing; here only the warning that a third-party overlay is a third party with access to the DOM, §5.2), api-design-standards (service contracts; the human-readable error messages the API returns are theirs, their accessible presentation is this skill's) and cicd-standards (the pipeline; here which gate to put on it, §4.2), technical-hiring-standards (the design of the selection process is theirs; the conformance of its tooling and reasonable adjustments — alternative format, extra time, an accessible screen-reader-testable exercise — are governed by the criterion here. Shared warning: an inaccessible selection process discards candidates before evaluating them, and that is not a user-experience failure but a validity failure of the measuring instrument), webgl-webgpu-standards (a <canvas> is opaque to assistive technology — it has no structure, no text, no focus. The conformance criterion and the requirement of an equivalent alternative are this skill's; how the canvas content is implemented and how it performs, theirs), i18n-standards (a boundary with real, concrete overlap: the correct lang attribute and text direction are a conformance criterion here — without lang the screen reader mispronounces —, whereas the choice of languages, the message catalogue, pluralisation, regional formatting and the translation workflow are theirs. Shared warning: an interface translated into an RTL language is not the same interface mirrored, and text in other languages expands — a component that only fits in English fails in both skills).

2. Default decisions

Verify the latest version on the web before fixing it in a real project (§8).

2.1 Target standard

Why AA and not AAA: WCAG itself says so — it is not project policy but the standard's. WCAG 2.2, §5.2.1 Conformance Level, Note 2, verbatim: "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content." AA is the level that every legal standard cited below references. AAA is applied per chosen criterion, never as a global goal.

WCAG 2.2 is the Recommendation in force: published on 5 October 2023, with an update on 12 December 2024. It does not repeal the earlier ones — W3C, verbatim: "WCAG 2.2 does not deprecate or supersede WCAG 2.1, and WCAG 2.1 does not deprecate or supersede WCAG 2.0." The only substantive change relative to 2.1: 4.1.1 Parsing appears in the WCAG 2.2 index as "4.1.1 Parsing (Obsolete and removed)".

WCAG 3.0 is NOT in force and you do not plan against it. The draft is a W3C Working Draft of 03 March 2026, and its own "Status of This Document" says verbatim: "This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress." In WCAG 3.0 the acronym changes meaning (W3C Accessibility Guidelines) and the conformance model is different (bronze/silver/gold-style levels instead of A/AA/AAA). A vendor selling "WCAG 3.0 certification" in 2026 is selling smoke — there is no stable conformance model to certify against. Candidate Recommendation and Recommendation dates: gap, not verified against a primary source (§8).

2.2 Legal obligation — what decides

You do not choose the level: it is set by whichever law applies to the product. First of all, determine jurisdiction and sector.

EAA (Directive (EU) 2019/882) — verbatim quotes from EUR-Lex:

• Art. 31.1: "Member States shall adopt and publish, by 28 June 2022, the laws, regulations and administrative provisions necessary to comply with this Directive."
• Art. 31.2: "They shall apply those measures from 28 June 2025."
• Art. 31.3: "By way of derogation from paragraph 2 of this Article, Member States may decide to apply the measures regarding the obligations set out in Article 4(8) at the latest from 28 June 2027." (emergency communications).
• Art. 4.5, the exemption most often invoked wrongly: "Microenterprises providing services shall be exempt from complying with the accessibility requirements referred to in paragraph 3 of this Article and any obligations relating to the compliance with those requirements." → the exemption is for microenterprises providing SERVICES, not for microenterprises that manufacture products. Do not apply it from hearsay: check it against the text.
• Art. 32.1 (transitional): "Member States shall provide for a transitional period ending on 28 June 2030 during which service providers may continue to provide their services" using products lawfully used before the date. It is not a general extension until 2030.

Spain: the transposition is Ley 11/2023, de 8 de mayo, de trasposición de Directivas de la Unión Europea en materia de accesibilidad de determinados productos y servicios, migración de personas altamente cualificadas, tributaria y digitalización de actuaciones notariales y registrales (BOE-A-2023-11022); its Title I transposes the EAA. Verified subsequent development: Real Decreto 143/2026, de 25 de febrero, por el que se crea y regula la Unidad técnica de apoyo y coordinación de las autoridades de vigilancia en materia de requisitos de accesibilidad (BOE-A-2026-4520), which develops art. 28 of Ley 11/2023 — that is, the enforcement machinery already exists, this is not an obligation without an authority behind it. Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público remains the one governing the public sector, with its mandatory accessibility statement (§6.1). The amounts under the penalty regime of Ley 11/2023 and the exact deadlines of its transitional provisions: gap, check in the consolidated BOE text (§8).

EN 301 549: the version carrying presumption of conformity is the one cited in the OJEU, not the latest ETSI has published. Verified: V3.2.1 (2021-03) is the referenced one; there is a draft V4.1.0 (2025-11) published by ETSI that aligns clauses 9, 10 and 11 with WCAG 2.2 and adds Annex ZA (Directive 2016/2102) and a clause A.2 for Directive 2019/882. The European Commission puts it verbatim: "New versions of the WCAG or of EN 301 549 do not automatically change the legal obligations." The publication date of a V4.1.1 in the OJEU is a gap: "October 2026" circulates in secondary sources, without primary confirmation (§8). Practical consequence: build against WCAG 2.2 AA even if the cited standard is still 2.1 AA — 2.2 is a superset except for 4.1.1, and it avoids re-auditing when the citation changes.

US — important correction: the ADA Title II rule was published on 24 April 2024 with a technical standard, verbatim from ada.gov: "The Web Content Accessibility Guidelines (WCAG) Version 2.1, Level AA is the technical standard for state and local governments' web content and mobile apps." The compliance dates were extended: ada.gov, verbatim: "On April 20, 2026, the Federal Register published the Department's Interim Final Rule (IFR) extending the compliance date for State and local government entities with a total population of 50,000 or more to April 26, 2027. The compliance date for public entities with a total population of less than 50,000, or any special district government, is extended to April 26, 2028." Declared discrepancy: a good share of secondary sources (vendor blogs, "2026" guides) still cite 24/26 April 2026 as a live date. That is out of date. ada.gov wins. What did not change: the technical standard, nor the scope of covered content.

Section 508 has not been updated to WCAG 2.1/2.2: it still incorporates WCAG 2.0 levels A and AA, with the final rule in force since 18 January 2018. Consequence: meeting 2.2 AA covers 508; the reverse does not.

2.3 Tooling

pa11y is LGPL-3.0-only — not MIT, as is usually assumed. Checked in its raw LICENSE and in the npm license field. Use as a CI tool: no problem. Linking it inside a distributed product: review with whoever owns licensing.

3. Most commonly failed criteria (and what they literally require)

Empirical base, not intuition. WebAIM Million, February 2026 sample over the million most popular home pages: 95.9% of home pages had detected WCAG 2 failures, up from 94.8% in 2025 — "reversing a trend of small improvements each of the previous 6 years". And since only what is automatically detectable is counted, the report itself concludes verbatim: "this suggests that the rate of full WCAG 2 A/AA conformance was certainly lower than 4.1%."

The six failures that account for 96% of all detected errors (home pages affected, Feb-2026):

Operational criterion: if a project cannot fix everything at once, these six first — they are cheap, automatable and cover most of the real volume.

3.1 Contrast and colour (verbatim from WCAG 2.2)

• 1.4.3 Contrast (Minimum) (Level AA): "The visual presentation of text and images of text has a contrast ratio of at least 4.5:1", with exceptions: "Large-scale text and images of large-scale text have a contrast ratio of at least 3:1"; incidental, inactive or decorative text, and logotypes, with no requirement.
• 1.4.11 Non-text Contrast (Level AA): "The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s): User Interface Components […] Graphical Objects". → the field border, the checked state and the focus indicator also have a threshold, not just text.
• 1.4.1 Use of Color (Level A): "Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element." → a field in red with no error text fails; a chart series distinguished only by colour fails (see also the dataviz skill if available).

3.2 Focus

• 2.4.7 Focus Visible (Level AA): "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible."
• 2.4.11 Focus Not Obscured (Minimum) (Level AA), new in 2.2: "When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content." → a fixed bar (sticky header/cookie banner) covering the focused element fails. It is the typical failure no automated tool sees.
• 2.4.3 Focus Order (Level A): "If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability."
• 2.4.13 Focus Appearance is AAA, not AA: "an area of the focus indicator […] is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component […] and has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states." A good design target; not enforceable as AA.

3.3 Pointer target (new in 2.2)

• 2.5.8 Target Size (Minimum) (Level AA): "The size of the target for pointer inputs is at least 24 by 24 CSS pixels", except for equivalent spacing (a 24 px circle that does not intersect another target), an equivalent control on the same page, an inline target within a sentence, a user-agent control or essential presentation.
• 2.5.7 Dragging Movements (Level AA): "All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential". → every drag & drop needs a non-dragging alternative. It is the criterion that most often breaks list reorderers and kanban boards.

3.4 ARIA and accessible name

First rule of ARIA, verbatim from Using ARIA (W3C): "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so." The exceptions the document itself admits: that the feature exists in HTML but is not implemented or has no accessibility support; that visual design constraints prevent using the native element because it cannot be styled as required; or that the feature does not exist in HTML today.

Derived, enforceable rules:

• Badly applied ARIA is worse than none. role="button" on a <div> forces you to implement focus, Enter, Space and the disabled state by hand. If all four are not there, it is a defect.
• Every interactive control has an accessible name (4.1.2 Name, Role, Value, Level A). The visible name must be contained in the accessible name (2.5.3 Label in Name, Level A) — otherwise a voice-control user cannot activate it by saying what they see.
• An icon-button with no text needs a name: aria-label or visually hidden text. A title is not enough.
• aria-live for what changes without a reload: 4.1.3 Status Messages (AA), verbatim: "status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus." The live region must exist in the DOM before receiving the message, or nothing is announced.

3.5 Regions, headings and focus in an SPA

• Landmarks: <header>/<nav>/<main>/<footer> — a single <main> per view, and a "skip to content" link as the first focusable element (2.4.1 Bypass Blocks, Level A).
• Hierarchical headings with no skipped levels; a single <h1> describing the view. A heading is not a font size.
• Route change in an SPA — the classic failure: navigating without a reload does not move focus nor announce anything. The screen-reader user stays where they were, with focus on a link that no longer exists. Mandatory criterion in every SPA: on completing a route change, (a) update document.title, (b) move focus to the new view's <h1> or to its container (tabindex="-1" + .focus()), and (c) announce the change via a live region if the destination takes time to paint. Without all three, navigation is inaccessible even if each individual screen passes axe. The router belongs to frontend-frameworks-standards; the requirement is this skill's, and it is tested with keyboard and screen reader, not with an automated test.
• Modal dialog: focus moves inside the dialog on open, focus is trapped while it is open, Escape closes it, and focus returns to the element that opened it. Use <dialog> with showModal() or an already-audited design-system component; do not reimplement it per screen.

3.6 Forms and errors

• Every field has an associated <label> (for/id) or aria-labelledby. A placeholder is not a label: it disappears as you type and usually fails contrast.
• 3.3.1 Error Identification (Level A), verbatim: "If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text." → in text, not just with a red border or an icon.
• 3.3.3 Error Suggestion (Level AA): "If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content."
• 3.3.2 Labels or Instructions (Level A): "Labels or instructions are provided when content requires user input." Expected format, whether it is required and any constraints before submitting, not after.
• The error message is associated with the field (aria-describedby), aria-invalid is set, and focus goes to the first erroneous field or to a focusable error summary.
• 3.3.8 Accessible Authentication (Minimum) (AA), new in 2.2: do not require a cognitive test (remembering, transcribing, solving a puzzle) without an alternative. It directly affects CAPTCHAs and one-time codes that block pasting — if the field prevents paste, it fails.

3.7 Data tables

<table> only for data, never for layout. <caption> with the title, <th> with scope="col"/scope="row", <thead>/<tbody>. Complex tables: headers/id. A "table" made of <div>s requires full role="table"/row/cell — it is more work than using the native element (§3.4).

3.8 Motion and user preferences

• 2.3.1 Three Flashes or Below Threshold (Level A): nothing that flashes more than three times per second. It is a physical safety criterion (photosensitive epilepsy), not an aesthetic one.
• 2.2.2 Pause, Stop, Hide (Level A): any automatic motion lasting more than 5 s can be paused, stopped or hidden. Applies to carousels and logo marquees.
• prefers-reduced-motion: reduce: respect the system preference by default — transform/movement animations disabled or reduced to an opacity change. Crossover with web-performance-standards: there the same query is used to avoid burning main-thread time; here it is a conformance requirement.
• prefers-contrast: more and the OS forced-contrast mode: the interface must remain usable; do not override system colours with !important.

3.9 Multimedia, documents and email

• Unreviewed automatic captions do not conform: 1.2.2 requires captions, and captions with transcription errors do not convey the content. Human review.
• Transcript ≠ captions: a transcript does not cover 1.2.2 for video.
• The technical delivery of the track belongs to streaming-multimedia-standards (WebVTT/TTML/IMSC, CEA-608/708, declaration in the HLS/DASH manifest, audio-description rendition). Here the conformance criterion and who signs it; there, that it reaches the player. A track that is produced but not declared in the manifest fails all the same: the gate is that it shows up in the client.
• PDF: if a PDF is published, it goes out tagged (structure, reading order, alternative text, language, document title) — reference PDF/UA. Preferred criterion: publish HTML and offer the PDF as a secondary download, not the other way round. A scanned PDF with no text layer is inaccessible content, no nuance.
• Email (HTML): alternative text on images, sufficient contrast, heading hierarchy, and a plain-text version in the multipart/alternative. An email that is just a linked image is inaccessible.

4. Testing method and CI gates

4.1 What automation actually automates — the data, not intuition

No automated tool closes conformance. Verified figures, with their source and declared bias:

• Deque (maker of axe-core), over >2,000 audits, >13,000 pages and ~300,000 issues: "57.38% of total issues were identified using its automated tests". The axe-core documentation repeats it: "With axe-core, you can find on average 57% of WCAG issues automatically". It is a vendor study about its own product, and it measures issue volume, not the percentage of success criteria covered.
• UK Government Digital Service: the best tool it tested found 40% of the known barriers.
• Deque puts its Intelligent Guided Tests (semi-automated, with human intervention) at around 80%; the 57%→80% jump is not automation, it is a guided person.

Fixed criterion: treat ~40% as the conservative working figure and 57% as the optimistic vendor upper bound. Between 43% and 60% of real problems are seen by no tool. Direct consequence: a score of 100 in Lighthouse's accessibility category does not mean the site is accessible, it means it passed the rules that can be checked without understanding the content. Nothing that is a semantic judgement — whether the alt describes the image, whether the focus order makes sense, whether the error is understandable, whether the dialog returns focus — is automatable.

4.2 CI gates (in increasing order of cost)

1. Static lint (eslint-plugin-jsx-a11y or the framework's equivalent): over the diff, in the pre-commit. Cost ~0.
2. axe-core at component level (jest-axe) on design-system components: zero violations, breaks the build. It is the most profitable gate because one fixed component fixes all its instances.
3. @axe-core/playwright on the critical E2E journeys (sign-up, login, checkout, search), in every relevant state: empty form, form with errors, dialog open, menu expanded. An analysis of the page's initial state is worthless: the failures live in the states.
4. pa11y-ci with .pa11yci crawling the set of representative URLs nightly, not on every PR.
5. Lighthouse CI with an assertion on the accessibility category: an absolute threshold and, on top of that, a ban on regression relative to the main branch. Same binary and same configuration as the web-performance-standards budget.

Failure policy: axe-core serious and critical break the build without exception. moderate/minor warn and go into the register. Exclusions (disableRules, excluded selectors) are declared in the configuration file with a reason and an associated issue, never inline and never silently.

4.3 What cannot be automated (and is mandatory)

Non-substitutable requirement: before declaring conformance, every critical journey is tested

• Keyboard-only, no mouse: Tab/Shift+Tab traverse everything interactive in a logical order, focus is always visible (§3.2), there are no focus traps, Escape closes what opens and focus returns where it should.
• With at least two real screen readers, in their natural browser pairing: NVDA + Firefox or Chrome (Windows) and VoiceOver + Safari (macOS/iOS); TalkBack + Chrome if there is a mobile web; JAWS if the target audience is corporate or public administration. Screen readers do not behave the same as each other: a pattern that works in VoiceOver may stay silent in NVDA. Emulating with the DevTools accessibility tree does not replace the test; the tree says what is there, not what is heard.
• At 200% and 400% zoom (1.4.4 Resize Text, 1.4.10 Reflow) and with forced text spacing (1.4.12).
• With users with disabilities when the product is critical or mass-market. It is the only test that catches usability problems that technically "conform".

5. Stack security and risks

5.1 Accessibility overlays: FORBIDDEN as a conformance strategy

Formal position of the community, verbatim from the Overlay Fact Sheet (1,031 signatories as consulted in Aug-2026):

"1. We will never advocate, recommend, or integrate an overlay which deceptively markets itself as providing automated compliance with laws or standards 2. We will always advocate for the remediation of accessibility issues at the source of the original error 3. We will refuse to stay silent when overlay vendors use deception to market their products 4. More specifically, we hereby advocate for the removal of web accessibility overlay and encourage the site owners who've implemented these products to use more robust, independent, and permanent strategies to making their sites more accessible"

And there is a regulator's resolution, not just opinion: the FTC ordered accessiBe to pay USD 1,000,000 over deceptive claims about its accessWidget widget (announcement of 3-Jan-2025; final order approved on 24-Apr-2025). The order bars it from representing that its automated products can make any website WCAG-conformant or maintain that conformance without substantiating evidence, and also from passing off its own reviews as independent opinions. The FTC documented on sites with the overlay installed: missing or incorrect alt, missing focus indicator, keyboard traps and wrong heading levels — that is, the overlay does not even fix what it claims to fix. Note for rigour: it was a settlement without admission of the practices.

Criterion: an overlay is not installed as a conformance solution. If one is already installed, removing it is part of the remediation plan. An in-house preferences widget (contrast, text size) built and audited by the team is not an overlay and is legitimate — the difference is that it does not promise conformance nor inject itself over someone else's DOM.

5.2 Third-party risk

An overlay or a third-party accessibility widget is third-party JavaScript with full access to the DOM, which often intercepts focus and keyboard input. Implications usually overlooked: XSS and supply-chain surface, incompatibility with a strict CSP (it frequently forces unsafe-inline or unsafe-eval), and processing of data about users with disabilities — a specially sensitive category under the GDPR (see privacy-engineering-standards). If it goes in anyway, it goes in with SRI, with a CSP review and with a signed DPA.

5.3 Accessibility and security controls

• CAPTCHA: if it is the only way through, it fails 3.3.8 (§3.6). Alternatives: interaction-free detection, attestation tokens, rate limiting. If there is a CAPTCHA, a non-visual and non-cognitive alternative is mandatory.
• MFA: one-time codes must be pasteable and readable by the password manager (autocomplete="one-time-code"). Blocking paste "for security" is a failure with a negative security cost.
• Session timeouts: 2.2.1 Timing Adjustable (Level A) requires warning and allowing an extension. A silent logout after 15 minutes breaks anyone who needs more time.
• Content hidden for security: aria-hidden="true" never on anything focusable (§7). If it must be hidden from everyone, hidden/display:none/inert.

6. Operability: declare, measure and do not regress

6.1 Accessibility statement

Where the law requires it (EU public sector: Directive 2016/2102; Spain: RD 1112/2018), the statement is a deliverable with prescribed content, not a page of good intentions. It must include, as a minimum: compliance status (conformant / partially conformant / non-conformant), which parts of the content are not accessible and why, alternatives offered, a feedback and accessible-information request mechanism, a complaints and claims procedure, the date of the statement and the date of the last review. RD 1112/2018 additionally requires periodic reviews and keeping it up to date. A statement claiming full conformance without a manual audit behind it is a documented falsehood with the responsible person's name on it. Drafting it as partially conformant with an honest list of exceptions is the correct and defensible option.

For the US market the equivalent document is the VPAT / ACR, which the buyer asks for in the tender, not the regulator.

6.2 Audit and report

Scope by user journeys, not by page count. Every finding carries: the failed success criterion (number and level), severity by user impact (not by ease of fixing), reproduction steps, the assistive technology and browser used, and a remediation proposal. Findings go into the same backlog as every other bug, with the same severity SLA. A separate accessibility board is a board nobody looks at.

6.3 Non-regression

• Metric tracked: serious+critical violations per critical journey, monthly trend. Target: zero, and no regression between releases.
• Manual audit coverage: % of critical journeys tested with keyboard and screen reader in the last N months. That is the honest metric; the rest is the 40-57%.
• Design-system components are audited when a major version is published and their report is versioned with the component.

7. Sustainability and prohibitions

• Cadence: review on the web the state of WCAG, EN 301 549 and the legal dates every quarter; the tooling, at the normal dependency cadence. axe-core changes rules between minor versions: pin the version and review the changelog before bumping, because a new version can break the build with legitimate new findings (that is good: they get fixed, not silenced).
• Do not plan against WCAG 3.0 (§2.1). Plan against 2.2 AA.
• Accessibility is estimated inside the story, not as a separate story. A story without accessibility acceptance criteria does not meet the Definition of Ready.

Explicit prohibitions:

• ❌ Accessibility overlays as a conformance solution (accessiBe, UserWay, AudioEye and the like in widget mode). See §5.1: there is a formal position with 1,031 signatories and an FTC order of USD 1M.
• ❌ outline: none (or outline: 0) with no substitute focus indicator meeting 1.4.11 and 2.4.7. It is the industry's most repeated one-line failure.
• ❌ aria-hidden="true" on interactive content or content containing it. It creates an element that is focusable and invisible to assistive technology: the worst of both worlds. Use inert.
• ❌ Positive tabindex (tabindex="1" and above). It breaks document order across the whole page, not just where it is applied. Only 0 and -1.
• ❌ Text inside images for content (1.4.5 Images of Text, AA). It does not scale, is not translated, cannot be selected and usually fails contrast. Exceptions: logotypes and cases where the presentation is essential.
• ❌ placeholder as a field's only label.
• ❌ <div>/<span> with onclick without role, without tabindex="0" and without keyboard handling. Before that, <button> (§3.4).
• ❌ Announcing "WCAG AA conformant" without a manual audit with keyboard and screen reader. With a signed legal statement, it is not only false but a liability.
• ❌ Silencing axe-core rules inline or excluding selectors with no written reason and associated issue.
• ❌ user-scalable=no / maximum-scale=1 in the viewport: it blocks zoom (1.4.4).
• ❌ SPA route change with no focus management or announcement (§3.5).
• ❌ Automatic captions with no human review presented as compliance with 1.2.2.
• ❌ Untagged PDF as the only format of essential content.
• ❌ Treating accessibility as a final phase ("we'll run it through axe before shipping"). The 43-60% automation does not see is discovered then, when the redesign no longer fits.

8. Mandatory web verification

Before committing any fact from this document in a real project, verify against the primary source:

1. WCAG: w3.org/WAI/standards-guidelines/wcag/ — which version is a Recommendation today and the date of the last update. Normative text of each criterion at w3.org/TR/WCAG22/, copied verbatim: a mistranscribed nuance changes whether something conforms or not.
2. WCAG 3.0: w3.org/TR/wcag-3.0/ — check it is still a Working Draft. Declared gap: expected Candidate Recommendation and Recommendation dates, with no primary source; the figures circulating (Q4-2027, ≥2028, 2029) are third-party.
3. EAA: EUR-Lex CELEX 32019L0882 — arts. 4, 31 and 32 in their consolidated text. Do not trust summaries: art. 31.1 (28-Jun-2022, transposition) is systematically confused with 31.2 (28-Jun-2025, application), and an automatic summariser inverted them during this very verification.
4. Spain: BOE-A-2023-11022 (Ley 11/2023) — declared gaps: neither the amounts under the penalty regime nor the exact deadline of the transitional provision on self-service terminals have been verified against a primary source (a secondary source says 10 years, the EAA speaks of economic useful life with a cap; unresolved discrepancy). BOE-A-2018-12699 (RD 1112/2018) and BOE-A-2026-4520 (RD 143/2026).
5. EN 301 549: the ETSI page and the citation in the OJEU, which is what confers presumption of conformity. Declared gap: the publication of V4.1.1 in the OJEU ("October 2026" is cited in secondary sources) is not confirmed by a primary source. Remember the Commission's verbatim: "New versions of the WCAG or of EN 301 549 do not automatically change the legal obligations."
6. US: ada.gov for Title II — the dates in force are 26-Apr-2027 and 26-Apr-2028, not the 2026 ones vendor guides keep repeating (declared discrepancy, §2.2). section508.gov to confirm whether it is still on WCAG 2.0 AA.
7. Automation figures: the 57% is Deque's about its own tooling and the 40% is GDS's. Check whether there is a more recent independent study before citing either.
8. WebAIM Million: published annually (last verified: February 2026). Check the current edition before citing percentages.
9. Overlays: overlayfactsheet.com (number of signatories, verified: 1,031) and ftc.gov for the status of the order against accessiBe and any subsequent action against other vendors.
10. Tooling — version and licence, reading the raw LICENSE: axe-core (verified 4.12.1, MPL-2.0), pa11y (9.1.1, LGPL-3.0-only — not MIT), lighthouse (13.4.1, Apache-2.0), @lhci/cli (0.15.1, Apache-2.0). Also check whether any has gone into mainte

…(truncated)