Consumer banking

What the EAA covers here

Annex I names banking services for consumers directly: the online and mobile banking a retail customer uses day to day, including the authentication and identification steps that sit in front of it. That’s a narrower target than “everything a bank does” — it’s the consumer-facing digital banking relationship, not the bank’s internal systems or its business-banking products.

Statements, transfer forms, card management, and the login flow that gates all of them are the surfaces this sector page is about.

Statements and authentication

Two parts of consumer banking tend to raise accessibility questions that a plain web audit doesn’t fully answer. Statements are frequently shipped as PDFs rather than web pages, which puts them under a different part of the EN 301 549 catalog — one concerned with whether a document carries a real reading order and structure, not just visible text. And authentication — one-time passcodes, security questions, biometric prompts — combines a tight time constraint with a channel (SMS, an authenticator app, a phone call) that isn’t always the customer’s primary one, which is where usability and accessibility overlap most directly for this sector.

Products vs services

Consumer banking is treated by the EAA as a service, which is the main reason the microenterprise exemption — fewer than 10 people and either turnover or balance-sheet total no more than €2 million — is relevant here in a way it isn’t for every Annex I category. A bank’s own banking app or portal is the service; a statement document or an authenticator app it ships alongside that service inherits its own separate document or software requirements. Whether a specific institution or product line falls inside this area is a legal call for that institution, not something this page decides.

What auditors look at first

A review of consumer banking typically starts with the forms that move money or change account settings — transfer, payment, and profile forms — checking that every field keeps a real label rather than a placeholder that disappears on input, and that a submission error is announced and tied to the field it came from. From there it moves to transaction and balance tables, checking whether row and column headers are exposed to assistive technology rather than only laid out visually, and to statement PDFs, checking whether the document has an actual tagged structure a screen reader can navigate rather than a flat image of text.