Accessibility in Identity Verification: the European Accessibility Act, WCAG 2.2 and EN 301 549

A person who is blind, who cannot hold a phone steady, who has a tremor, or who finds timed tasks hard may reach the identity check of an online account opening and simply not be able to finish it. From the point of view of the bank this looks like an abandoned session; from the point of view of the person it is a closed door. In the European Union the door is now a legal matter as well, because the identification method used in consumer banking is named in an accessibility directive. This article reads that directive, the two technical standards that sit under it, and the identity proofing guidance of the United States and the monitoring data of the United Kingdom, and then walks through a typical verification session asking where each step can fail.

For information; not legal advice.

The article does not claim that any flow, including ours, conforms to any of the texts it describes. Conformance is established by testing a specific flow with specific users, and none of that testing is reported here. For background see the liveness vendor buyer guide, SP 800-63A-4 and the EBA onboarding guide.

Layer one: the Directive

The text is Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services, usually called the European Accessibility Act. It is a directive, so what binds a bank is the national law of the Member State that transposed it, and the differences between those laws are for counsel to map. Member States had to adopt and publish their measures by 28 June 2022 and had to apply them from 28 June 2025.

Which services are covered

Article 2(2) lists the services covered and, among them, consumer banking services; the Directive applies to those services when they are provided to consumers after 28 June 2025. Article 3 defines consumer banking services by listing what is provided to consumers: credit agreements of the consumer-credit and mortgage-credit directives, certain investment services, payment services, services linked to the payment account, and electronic money. An account opening that leads to any of these is, on the face of the text, inside the scope. Article 3 also defines a service provider as any natural or legal person who provides a service on the Union market or offers to provide it to consumers in the Union.

Two limits matter for planning. Article 4(5) exempts microenterprises providing services from the service accessibility requirements, and Article 3 defines a microenterprise as an enterprise that employs fewer than 10 persons and has an annual turnover or balance sheet total not exceeding EUR 2 million. Article 32 lets a service provider continue, until 28 June 2030, to provide services using products it lawfully used for similar services before that date, and lets service contracts agreed before 28 June 2025 continue without alteration until they expire, for no longer than five years from that date. Whether either of these helps a particular identity check depends on the facts and on the national law, and a flow built or replaced after that date would need to be checked against the exact wording of the national transitional rule.

What the Directive asks of the identification method

Article 4 says the services must comply with the accessibility requirements set out in Annex I. Annex I has a general section for all services and a specific one for banking.

The general section, Section III, asks that services be provided in a way that maximises their foreseeable use by persons with disabilities. For a verification flow, four of its points are the ones to hold in mind. The products used in providing the service, such as the app or the page that opens the camera, must themselves be accessible. Information about how the service works must be given in a way that can be perceived through more than one sensory channel, in understandable form, with text that can be turned into other formats, in adequate fonts and contrast, and with an alternative for non-text content. Websites and mobile applications must be made perceivable, operable, understandable and robust in a consistent and adequate way. Where support services exist, such as help desks, they must give information on the accessibility of the service in accessible modes of communication.

The banking section, Section IV, point (e), is the one that names our subject. It requires consumer banking services to provide identification methods, electronic signatures, security and payment services that are perceivable, operable, understandable and robust. It also requires that information be understandable, without exceeding level B2, upper intermediate, of the Council of Europe's Common European Framework of Reference for Languages. A recital explains the reasoning: identification methods, electronic signature and payment services are necessary for concluding consumer banking transactions. Our reading is that the words "identification methods" are broad enough to include a document-and-selfie check in the account opening, because it is the method by which the customer is identified. The text does not say so in terms, and a national regulator may read it differently.

The fallback criteria

Annex I, Section VII, sets out functional performance criteria that apply when the specific requirements do not address a function. They may be used as an alternative to a specific technical requirement only if they give equivalent or increased accessibility for foreseeable use by persons with disabilities. They read as a list of modes of operation that must exist. Where a service provides visual modes of operation, it must provide at least one mode that does not require vision, and at least one for users with limited vision, and at least one that does not require perception of colour. Where it provides auditory modes, it must provide at least one that does not require hearing and one with enhanced audio for limited hearing. Where it requires vocal input, it must provide a mode that does not. Where it requires manual actions, it must provide at least one mode that does not need fine motor control, hand strength or operating more than one control at the same time. It must also provide at least one mode of operation with features that make it simpler and easier to use, for limited cognition. And where accessibility features are provided, it must offer at least one mode that maintains privacy while using them. The first of these is the hard question for a camera-based check, and the last is a reminder that an assisted route, such as a person helping with the capture, must not expose the customer's data to the helper by default.

Burden, documentation and presumption

Article 14 applies the requirements only to the extent that compliance does not require a fundamental alteration of the nature of the service and does not impose a disproportionate burden on the economic operator. An operator that relies on it must assess the point, using the criteria in Annex VI, and document the assessment. The operator must keep the results for five years from the last time the service was provided, must renew the burden assessment when the service is altered and in any event at least every five years, and must notify the authorities of the Member State where the service is provided. An operator that receives funding from other sources, public or private, provided for the purpose of improving accessibility cannot rely on the disproportionate-burden exception.

Article 15 provides that products and services that conform to harmonised standards, whose references have been published in the Official Journal of the European Union, are presumed to meet the accessibility requirements to the extent the standards cover them. This is the hook that connects the Directive to EN 301 549, and it is why the current citation status of that standard matters.

An example of national transposition

Germany transposed the Directive in the Barrierefreiheitsstärkungsgesetz. Section 1(3), point 3, of that law applies it to banking services for consumers provided after 28 June 2025. Section 3(1) makes products and services accessible when persons with disabilities can find, reach and use them in the generally usual way, without particular difficulty and in principle without outside help. Section 3(2) leaves the concrete requirements to a regulation that follows Annex I of the Directive, and Section 3(3) exempts microenterprises that provide services. We cite the German law only as an example of how a Member State put the same date and the same category into national text; we have not compared the other Member States.

Layer two: WCAG 2.2 and EN 301 549

The Directive names no test method. The technical content comes from the Web Content Accessibility Guidelines, published by the World Wide Web Consortium, and from a European standard that imports them.

WCAG 2.2

WCAG 2.2 was first published as a W3C Recommendation on 5 October 2023, and the text cited here is the republication of 12 December 2024. Its conformance model has three levels, A, AA and AAA, and Level AA requires that all Level A and Level AA success criteria are met. Two of its conformance requirements are worth stating for a multi-step process. Conformance is for full pages and cannot be achieved if part of a page is excluded. And when a page is one of a series that presents a process, a sequence of steps completed in order to accomplish an activity, all pages in the process must conform at the specified level or better, and conformance is not possible at a level if any page in the process does not conform. An onboarding session is such a process, so a vendor screen that fails inside an otherwise accessible bank flow fails the whole. WCAG 2.2 states that content that conforms to it also conforms to WCAG 2.0 and WCAG 2.1.

EN 301 549

EN 301 549 is the European standard of accessibility requirements for ICT products and services, developed jointly by the three European standardisation organisations. A standard has the legal force of a harmonised European standard only if it was developed under a mandate from the Commission and a reference to the specific version has been published in the Official Journal of the European Union. The Commission's page on standards and harmonisation concerns the Web Accessibility Directive, which covers public sector websites and apps, and not the Act. On that directive it says that only two versions of EN 301 549 have been harmonised, and that the latest, version 3.2.1, was harmonised on 18 August 2021. It says version 3.2.1 draws heavily on WCAG 2.1 but includes requirements that are not part of WCAG 2.1, and that meeting all the success criteria of WCAG 2.1 does not ensure a presumption of conformity with that directive. It adds that later versions of WCAG become legally relevant to that directive only if they are included in a harmonised version of the standard that is referenced in the Official Journal.

For the Act the mechanism is Article 15, described above, and the question of which version of EN 301 549, if any, is referenced in the Official Journal for the services in scope is a question to put to counsel, because we have not established it from an Official Journal instrument and do not state it here. AccessibleEU, an accessibility resource published on a European Commission site, reported on 7 September 2026 that version 4.1.1 of the standard was published in September 2026, adopts WCAG 2.2 as the benchmark for websites, software and digital documents in place of WCAG 2.1, and is the first version developed with the Act in mind, with an annex linking its requirements to the Act. The practical reading is that WCAG 2.2 Level AA is a strong basis for the web screens of a flow, but it is not the same as conformance to EN 301 549, which asks for more. We have not opened the text of EN 301 549 itself, because the ETSI download refused our request and we did not work around it, so this article does not list its clauses.

A verification session, step by step

The table below takes the steps of a typical remote session and attaches the WCAG 2.2 success criteria most likely to be engaged, with the question to ask of the flow. The criteria are quoted in substance from the Recommendation, each with its conformance level in brackets; the choice of which criterion belongs to which step is ours.

A test script

A team can turn the table into a script that a tester follows from the first screen to the outcome, on the real device types the customers use. First, complete the whole session with the keyboard only, and note any step where focus is lost, trapped or hidden. Second, repeat it with a screen reader and note every control without a name and every message that is not announced. Third, let the time limits run out once and note whether the person is warned and can extend. Fourth, trigger each error on purpose, such as a blurred document, and note whether the message is in text and says what to do. Fifth, take the alternative route that is offered to a person who cannot use the camera step, and note how long it takes and what the person is told at the start. Sixth, write down for each failure which criterion or which functional performance criterion it breaks.

Camera and document capture

Success criterion 1.1.1 requires that non-text content that is a control or accepts input has a name that describes its purpose. A camera viewfinder is a control that accepts input, so it needs a name, and the guidance that tells a sighted user to move the document into a frame needs a spoken equivalent. Criterion 2.5.8 sets the minimum size of pointer targets at 24 by 24 CSS pixels, with exceptions that include sufficient spacing between undersized targets and an equivalent control elsewhere on the page. Criterion 2.5.7 requires that functionality using a dragging movement can be achieved by a single pointer without dragging, unless dragging is essential. A document-framing screen that asks the user to drag a corner handle fails that criterion unless a tap-based alternative exists.

Face capture and the limit of the criteria

Criterion 2.5.4 requires that functionality operated by device motion or user motion can also be operated through interface components, and that the motion response can be disabled, except where the motion is essential and doing otherwise would invalidate the activity. The exception is a drafting point for liveness: a prompt such as "turn your head" is a user motion, and the question is whether it is essential to the activity or only a convenience of the design. We do not answer that question here, because it depends on the method and its security case, and the buyer guide linked above covers how to test it. What the criteria cannot do is say how a person who cannot see the preview should frame their own face. That is the case where the Directive's functional performance criteria apply, since a service with visual modes of operation must provide at least one that does not require vision. In practice this means either an assisted capture mode, such as spoken guidance, or a different route to the same result.

Criterion 2.2.1 on timing requires that, for each time limit set by the content, the user can turn it off, adjust it over a wide range of at least ten times the default, or extend it after a warning of at least 20 seconds, at least ten times, with exceptions for live events, essential limits that would be invalidated by extension, and limits longer than 20 hours. Session expiry in identity checks is often justified by security, so a team needs to decide which of the exceptions it relies on and write it down.

Authentication steps

Criterion 3.3.8 says a cognitive function test, such as remembering a password or solving a puzzle, is not required for any step in an authentication process unless that step provides an alternative method that does not rely on a cognitive function test, a mechanism to assist the user, object recognition, or recognition of personal content. The Recommendation lists password-manager support and copy and paste as mechanisms that satisfy it. A code-entry field that blocks pasting and password-manager entry, with no other mechanism and no alternative method that avoids the cognitive function test, can fail the criterion, whereas a field that accepts a pasted or autofilled code uses the mechanism route that the Recommendation names.

What identity proofing guidance adds

WCAG describes the interface; it does not say what to do when the automated route does not work for a person. The US Digital Identity Guidelines, in the fourth revision of the identity proofing volume, SP 800-63A-4, do say this. We cite the text as it appears on the publication site of the National Institute of Standards and Technology.

The volume's usability section notes that Section 508 of the Rehabilitation Act of 1973 was enacted to eliminate barriers in information technology, that the guidelines do not directly assert requirements from it, and that identity service providers are nevertheless expected to comply with its provisions. It also expects services to be designed with the experiences of people with disabilities in mind throughout the life cycle of the identity system. For the written materials of a flow, it recommends plain language, attention to font, size and contrast, a minimum font size of 12 points for electronic materials where the text fits, and a usability evaluation of each step with representative users.

On alternatives, the volume lists reasons for offering more than one type of proofing. Among them are users who cannot complete automated or technology-heavy processes, for example because of physical or cognitive disabilities, and users for whom certain processes, such as automated biometric recognition, may be less effective. For exceptions, it states that credential service providers should document their handling processes and should include trusted referees for applicants who are otherwise unable to meet the requirements of the first two identity assurance levels. It lists persons with disabilities among the examples of individuals who may need a trusted referee, and it says the provider should offer trusted referee services for failures of automated verification processes such as biometric comparisons. It further says the provider must notify the public that such services exist and how to obtain them.

The wording is a US federal guideline and is not binding on a European bank. Its use here is as a worked example of what a documented exception route looks like: who is eligible, what they are told, and what record is kept.

What the market evidence shows

The public measurement we found is the United Kingdom's annual inclusion monitoring of the digital verification services market. We read it as a snapshot of one national scheme, answered by the providers themselves, and not as a measurement of how users fare.

On 15 October 2026 the Office for Digital Identities and Attributes announced that it had published its third annual report on inclusion in the scheme. Services that take part in the UK trust framework scheme must complete an annual inclusion survey, and in the 2026 round 44 organisations completed it. The responses are anonymous and individual organisations are not assessed.

The reported figures are these. In 2026, 75% of surveyed organisations reported meeting WCAG 2.0 AA or a higher standard, up from 54% in 2024. Sixteen organisations reported meeting WCAG 2.2 AA in 2026, against four in 2024. Seventy-seven percent reported offering at least one accessibility tool, such as text magnification or compatibility with assistive technologies. Of the 44 organisations, 39 reported using biometric technology, and around half of those offer another route for people who cannot or do not wish to provide biometric information. Three organisations reported offering vouching, in which a person formally confirms someone else's identity, and none had a vouching route within the scope of their participation in the scheme. Sixty-one percent named the cost of implementing inclusive features as a key challenge.

Three cautions apply when reading these numbers. They are self-reported by 44 providers in one country, so they say nothing about providers elsewhere. The measure is whether an organisation says it meets a standard, not whether people with disabilities complete the check, and the report itself says inclusion cannot be understood through a single measure. And the headline for a buyer is the biometric figure: about half of the providers that use biometrics told the monitor they have another route, which leaves about half of them without a reported alternative.

A checklist for a buyer or product owner

The list below is organised as questions a team can put to itself or to a supplier, in the order of a session.

• Which national law applies, and has counsel confirmed whether the verification step is covered as an identification method under Annex I, Section IV(e), and whether a microenterprise exemption or a transitional rule is relied on?
• Has the burden assessment of Article 14 been written, with the criteria of Annex VI, and does the file show who will renew it and when?
• Which version of WCAG and which version of EN 301 549 is the flow tested against, who tested it, and does the test cover the whole sequence of screens, including the vendor's, as a complete process?
• Was the test done with assistive technology and with users who have disabilities, not only with an automated scanner?
• Does every camera step have a non-visual mode or an alternative route, and is it described to the user before the step starts?
• Is there a route to a human reviewer for a person who fails the automated step, who is eligible, and what record is kept of the decision?
• Are time limits adjustable or extendable, and which exception is relied on where they are not?
• Is the text of notices, consents and error messages at or below level B2, and has it been tested on readers?
• Does the help route sit in the same place on each screen?
• Does an assisted capture keep the customer's data private from the helper by default, and is that written in the process description?
• Does the supplier's contract require notice of changes to the interface that could affect accessibility, so that the burden assessment and the test can be repeated?

What a supplier can and cannot show

A supplier can show the artefacts that support a buyer's file: an accessibility conformance report against a named version of WCAG or EN 301 549, the date and method of the test, the list of assistive technologies used, the alternative routes that exist and how they are reached, and the contact for accessibility issues. A supplier cannot show that the buyer's whole flow conforms, because the flow is the buyer's sequence of screens, texts and support, and conformance is for the complete process. We make no statement here about the conformance of any NeuroVision interface. If you are assembling the facts for your own accessibility file and want to discuss what we can provide, contact the team.

Sources

All sources were fetched on 28 October 2026.

• Directive (EU) 2019/882 on the accessibility requirements for products and services (European Accessibility Act), Official Journal text, Publications Office of the European Union.
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, first published 5 October 2023, republished 12 December 2024, World Wide Web Consortium.
• The European accessibility standard EN 301 549 has been updated, AccessibleEU, European Commission, 7 September 2026.
• Special Publication 800-63A-4, Digital Identity Guidelines: Identity Proofing and Enrollment, National Institute of Standards and Technology, United States, page dated 26 August 2025.
• Publishing the third year of digital verification inclusion data, Office for Digital Identities and Attributes, GOV.UK, 15 October 2026.
• Barrierefreiheitsstärkungsgesetz, section 1, Federal Ministry of Justice, Germany.
• Barrierefreiheitsstärkungsgesetz, section 3, Federal Ministry of Justice, Germany.
• Web Accessibility Directive: Standards and harmonisation, Shaping Europe's digital future, European Commission.