European Accessibility Act in 2026: EN 301 549 V4.1.1 and the banking test scope

What changed in September 2026, and what did not

ETSI, CEN, and CENELEC published EN 301 549 V4.1.1 on 2 September 2026 (the ETSI file's publication date). Its foreword gives 24 August 2026 as the date of adoption and lists the changes from V3.2.1: clauses 9, 10, and 11 "have all been updated to align with the WCAG 2.2 recommendation", a new Annex ZB maps the standard to the essential requirements of Directive (EU) 2019/882, and a new clause A.2 lets a specific product or service be evaluated against that Directive.

The presumption of conformity is conditional. The foreword grants it to the clauses in the clause A.2 tables "Once the present document is cited in the Official Journal of the European Union under that Directive". Article 15(1) of the Directive sets the same condition: services that conform to harmonised standards "the references of which have been published in the Official Journal of the European Union, shall be presumed to be in conformity with the accessibility requirements of this Directive in so far as those standards or parts thereof cover those requirements."

Status verified on 2026-09-22:

• The Commission's AccessibleEU centre reported on 7 September 2026 that V4.1.1 "is not yet the legal reference standard" until the Commission cites it in the Official Journal.
• A search of the Publications Office metadata (Cellar) on 22 September 2026 returned no implementing decision that publishes a harmonised standard reference under Directive (EU) 2019/882.
• V3.2.1 (2021-03) is cited under the public sector Web Accessibility Directive, Directive (EU) 2016/2102, by Implementing Decision (EU) 2021/1339 of 11 August 2021. That citation gives no presumption under the EAA.

For a bank or payment app, conformity with Annex I is therefore assessed directly today, with EN 301 549 as the best available technical reading. Enforcement rests on national law: on 19 March 2026 the Court of Justice ruled in Case C-646/24 that Bulgaria had failed to transpose the Directive under Article 31(1) and ordered a lump sum of EUR 1 500 000. Scope, exemptions, and auditor artifacts are on our EAA and WCAG testing requirements page.

The Annex I clauses that set banking and e-commerce test scope

Four points of Annex I decide what a financial service has to prove:

• Section III(c), all services: "making websites, including the related online applications, and mobile device-based services, including mobile applications, accessible in a consistent and adequate way by making them perceivable, operable, understandable and robust".
• Section IV(e)(i), consumer banking services: "providing identification methods, electronic signatures, security, and payment services which are perceivable, operable, understandable and robust".
• Section IV(e)(ii), consumer banking services: "ensuring that the information is understandable, without exceeding a level of complexity superior to level B2 (upper intermediate) of the Council of Europe's Common European Framework of Reference for Languages."
• Section IV(g)(ii) and (iii), e-commerce services: accessible "functionality for identification, security and payment when delivered as part of a service instead of a product", and "identification methods, electronic signatures, and payment services which are perceivable, operable, understandable and robust."

Table ZB.5 of V4.1.1 maps row 9 (consumer banking, Section IV(e)(i)) to clauses 4.2 "especially 4.2.12", 5 "especially 5.1, 5.2", 9, 10, and 11. Row 12 (e-commerce, Section IV(g)(iii)) carries the same mapping. Two consequences for test plans:

• The login and payment steps are named scope. Clause 5.3 applies to them: "the ICT shall not rely on the use of a biological characteristic as the only means of user identification or for control of the ICT." A payment approval that offers only a fingerprint or face match fails it.
• The table cites a clause the text does not contain. In the V4.1.1 file we read on 2026-09-22, clause 4.2 ends at 4.2.11 Privacy, and no clause 4.2.12 exists. Our practice is to test 4.2.10 (limited cognition) and 4.2.11 (privacy), and to log the reference as open in the audit report.

Annex ZB is informative. Clause ZB.0 states that "The tables in clause A.2 offer the most appropriate way to assess the conformance of a specific ICT to the essential requirements of Directive (EU) 2019/882", so we structure reports by Tables A.1 (web) and A.3 (non-web software).

WCAG 2.1 AA to WCAG 2.2 AA: the six clauses that move

Clause 9.0 of V4.1.1 states that WCAG 2.1 Level AA equals clauses 9.1 to 9.4 "except 9.2.4.11, 9.2.5.7, 9.2.5.8, 9.3.2.6, 9.3.3.7, 9.3.3.8", plus the conformance requirements in clause 9.6. WCAG 2.2 Level AA equals all of clauses 9.1 to 9.4 plus 9.6. Clause 9.4.1.1, formerly Parsing, is now void. A report built on WCAG 2.1 AA therefore misses exactly these six clauses, with matching clauses 11.x for native apps:

For native apps, clause 11.3.3.8 adds banking-specific notes. Note 2 names "support for password entry by password managers" and "copy and paste" as mechanisms that satisfy the criterion. Note 5 addresses masked PINs: "If the screen shows dots then what is read should be "dot, dot, dot"." A screen reader that speaks each PIN digit aloud fails the privacy intent of that note and clause 4.2.11.

What to test before the Official Journal citation

This is our test sequence for a consumer banking or checkout service in the period before citation. It is our practice; the Directive and the standard do not prescribe it.

1. Test against V4.1.1 now and tag the six clauses. Report every finding with its V4.1.1 clause, and mark findings from the six new clauses as WCAG 2.2 only. The report then stays usable whether an authority reads it against V3.2.1 or V4.1.1, and it gives the evidence for Article 13(3), under which "changes in the harmonised standards or in technical specifications by reference to which a service is declared to meet the accessibility requirements shall be adequately taken into account by the service providers."
2. Inventory every identification step. List login, device binding, step-up, PSD2 strong customer authentication challenges, credit agreement e-signatures, and card payment challenges. For each step, record the non-biometric path (clause 5.3), autofill and paste results (clause 9.3.3.8 or 11.3.3.8), and the screen reader output for masked fields. The 3-D Secure challenge flow testing guide covers the issuer challenge screens that sit inside a merchant checkout.
3. Split web and native results. Map in-app web views to clause 11; clause 11.0 Note 3 states that the clause 11 requirements "are the appropriate requirements to be applied to these web views". Then record the VoiceOver and TalkBack versions per build. Our mobile app testing runs these checks on each release.
4. Review Section IV(e)(ii) texts. List fee disclosures, credit agreement summaries, and payment error messages for a plain-language review against the B2 level. The Directive names no measurement method, so the review record states the method used.
5. Re-baseline on citation. When an implementing decision cites V4.1.1, re-run the six clauses and update the Annex V accessibility information that Article 13(2) requires.

Our accessibility testing service delivers the WCAG 2.2 AA audit report mapped to EN 301 549 clauses, screen reader test results for payment and onboarding flows, a remediation list, and a retest report.