Accessibility

If your service falls under the European Accessibility Act (Directive (EU) 2019/882) — consumer banking is the typical case — and no exemption applies to you (microenterprises providing services are exempt, Art. 4(5)), the Act asks you to publish how your service meets its accessibility requirements, in your general terms and conditions or an equivalent document (Art. 13(2) and Annex V). The Act lists the services it covers in Art. 2(2); serving consumers is not enough on its own. Your queue is part of that service: the pages your clients open on their phone, the kiosk at your entrance and the TV in your waiting area. This page describes each of them, including what they do not do yet, so you can build your own accessibility information from it. Nothing has to be shown on the kiosk itself.

The description is current as of 16 October 2026. When a change affects any of these surfaces, this page changes with it — see Keeping your information current.

Which standard applies

• Pages on the client's own device — the live ticket page, appointment booking and your public homepage — are built to WCAG 2.1 level AA. That is the level referenced by EN 301 549 V3.2.1, the version of the harmonised standard cited in the Official Journal today, and the level we state conformance at until a newer version is cited. Features specified since 2 October 2026 are also designed to WCAG 2.2 AA, the level referenced by EN 301 549 V4.1.1 (published September 2026, not yet cited).
• The kiosk and the TV display are closed functionality: a client cannot bring their own screen reader or zoom to them. For closed functionality, EN 301 549 clause 5.1 sets the requirements in place of the WCAG criteria that rely on the client's own assistive technology. The kiosk is also a self-service terminal under the Directive — recital 26 names bank office queuing ticket machines — so it has to meet the product requirements of Annex I, Section I, including those point 2(o)(i) sets for self-service terminals.

How we check

• Colour contrast, automatically, on every change to the screens or the design system: every pair of text and background colours the design system defines must reach 4.5:1, and every control border and focus outline 3:1, in the light and the dark theme.
• Screen-reader announcements, kiosk timeouts and the kiosk's larger-text size, by automated tests on every change to the kiosk, ticket page and TV display code.
• An audit of the shipped pages on 6 July 2026. The ticket page and booking were checked with automated tools (axe-core), a keyboard walk-through, contrast measurement and a check at 320 pixels wide; the kiosk and the TV display for contrast and button size. It found five problems: four changes that the ticket page and booking did not announce to screen readers, and a ticket page without a heading. All five are fixed. The audit used automated tools in place of a screen reader, and the kiosk has been rebuilt since; the homepage was not yet live.

The live ticket page

The page a client opens by scanning the QR code on the kiosk screen. They pick a service, get a number and follow their turn on their own phone until they are called (The live ticket page).

How it meets the requirements:

• It works with the phone's own screen reader and the browser's zoom and text size: zoom is never blocked, text is sized relative to the browser's text size, and the page fits a screen 320 pixels wide without scrolling sideways.
• The screen reader announces what changes. Being called is announced at once, with the window; other changes of the ticket's state are announced without interrupting; a lost connection is announced too. The "Your turn is approaching" notice is announced once when it appears, without interrupting. The queue position and countdowns are left for the client to read when they want, so the screen reader is not interrupted every few seconds.
• While the client waits, the page asks them to keep it on screen and offers Turn on sound: one tap turns on a chime for the call and keeps the screen from switching off. When the client is called, the phone plays the chime if the client tapped Turn on sound, the browser tab title shows the call, and on Android the phone vibrates once the client has tapped the page (iPhones do not support it). A client who left an email address can also get a "you are called" email.
• Every control works with a keyboard and shows a visible focus outline. The cancel dialog keeps the focus inside it and closes with Escape.
• The page is in the client's language — any of the languages you turned on for the branch's ticket page — and tells the screen reader which language it is in.
• Animations stop when the phone asks for reduced motion.
• On the form for joining the queue before arriving, each error is shown next to its field, and the screen reader reads it with that field.

Time limits:

• The code on the kiosk screen changes every 10 seconds, and a scanned code has to be opened within 30 seconds of appearing. A slower scan shows the "code expired" page, and the client scans the current code. These 30 seconds cannot be extended: a fresh scan is what shows the client is at the branch.
• After opening it, the client has 10 minutes to pick a service and take a number. Two minutes before that time runs out, the page says so — the screen reader announces it too — and offers I need more time, which gives another 10 minutes. The client can do this up to ten times. If the time runs out, the page says the code has expired and the client scans it again.
• A client who needs more time before their turn can delay it by 5, 10, 15 or 30 minutes, and can end the delay early or add more time.

Appointment booking

The page where a client books a visit, and the page linked from their confirmation email where they check, reschedule or cancel it and check in when they arrive (Book an appointment).

How it meets the requirements:

• Zoom is never blocked and text is sized relative to the browser's text size.
• Every field has a label, and an error in a field is announced by the screen reader. Loading the available times, how many there are, a failed booking and the confirmation are each announced once; the times themselves are not read out one by one as they load.
• The recommended time is marked in words, not by colour alone.
• Everything works with a keyboard, including the choice of operator (arrow keys) and the language switcher.
• Moving to the contact details step, or back from it, moves the screen reader to that step's heading.
• Calendar days are read out in the client's language, with the day of the week (for example "Wednesday, October 14, 2026").
• The page for managing a booking has a main heading. Its cancel and reschedule dialogs keep the focus inside them, close with Escape and return the focus to the button that opened them.
• There is no time limit while booking.

Your public homepage

Your page that lists your branches, their services and how to contact you.

How it meets the requirements:

• A "skip to content" link, headings for each section and branch, and page regions a screen reader can jump between.
• Everything works with a keyboard: the service filter, the branch cards and the expandable details.
• Zoom is never blocked, and the page fits a screen 320 pixels wide without scrolling sideways.
• The page is in the client's language and tells the screen reader which language it is in.
• Nothing on the page moves or changes by itself, and there are no time limits.

The tablet kiosk

A tablet at your entrance for clients who prefer not to use their phone — or have none. The client picks a language, a service and, where the branch asks for one, a name, then gets a number (Register at the kiosk).

How it meets the requirements:

• Every button is at least 80 × 80 CSS pixels.
• Larger text. Every screen has an AA button. It makes all text at least one and a half times larger, and every text a client needs — instructions, buttons, error messages — at least 16 CSS pixels in x-height. That is the requirement of EN 301 549 V4.1.1 clause 5.1.4, met ahead of that version's citation. The button is always on screen, so there is nothing to switch on in advance; the next client starts at the normal size.
• The client chooses the language on the first screen, and the whole registration follows it.
• Nothing on the welcome screen changes by itself except the QR code and the live queue figures.
• The screen makes room for the on-screen keyboard, so that it does not cover the name field or the button that continues. The kiosk works with the tablet upright or on its side.
• Animations stop when the tablet is set to reduce motion.
• The client can continue on their own phone, with their own screen reader: the welcome screen's QR code starts the phone flow, and the confirmation screen's QR code opens the ticket on the phone.

Time limits:

• A registration screen returns to the welcome screen after 2 minutes without a touch. In the last 20 seconds a notice on the screen counts down and says that touching the screen continues; any touch starts the 2 minutes again.
• The confirmation screen closes after 60 seconds without a touch, or when the client taps Done. Any touch other than Done keeps it open and starts the 60 seconds again, as often as the client needs. In the last 20 seconds Done counts down and a notice on the screen says that touching it keeps it open. The number stays in the queue either way.

Not yet met — the kiosk's open gaps under Annex I, point 2(o)(i):

• Read-out. The kiosk has no text-to-speech and no headphone output yet, both of which the Directive requires of self-service terminals. This is the largest open gap. The kiosk will read every screen aloud through wired headphones the client plugs into the tablet; it will make no sound in the branch and will never speak a client's name. Until then, a client who cannot see the screen needs your staff's help to register. Read-out will not read the tablet's keyboard aloud, so where the branch asks for a name, a member of staff will still need to type it for the client. What your tablet needs to provide, starting with a headphone socket the client can find without sight, will be stated here when read-out is built.
• Timeouts. The warning before a reset is shown on screen only, not also by sound; the Directive asks for an alert through more than one sense. With read-out on, every warning will also come as a tone and speech in the headphones.

The TV display

The TV in your waiting area. It shows who is called to which window and who is waiting; clients only watch and listen (The TV display).

How it meets the requirements:

• Sound. Each new call shown on the TV plays a chime; calls already on the screen when the TV starts or reloads do not chime again. The chime is on by default for every branch. A branch can add a voice that says the ticket code and the window in the language you choose — never a name. If the TV has no voice for that language, the chime plays alone. A branch that shows client names on the TV plays the chime only.
• After the TV's browser starts, sound needs one tap on the screen (a browser rule), unless the browser starts with autoplay allowed (Displays & kiosks).
• Every colour set you can choose for the TV meets 4.5:1 contrast.
• The called number and the window are shown at 7 % of the screen's height — about 76 pixels on a Full HD TV.
• A new call first appears large in the centre of a dimmed screen for about 3.5 seconds, then moves into its card, which blinks gently for about 3 seconds. Movement and blinking last at most 5 seconds per call, and nothing flashes more than three times a second. The newest call's card stays filled with the colour set's accent colour until the next call.
• When the TV is set to reduce motion, there is no dimming, moving or blinking: a new call simply appears in its card.
• The waiting list makes its text smaller when the queue is long, but never below 2 % of the screen's height. Names that no longer fit at that size are replaced by a "+N" count of how many more are waiting.
• The page tells the TV's browser which language it is in — the language set for the display.

Not yet met:

• The TV has no larger-text mode.
• Sound comes only from the TV's own speakers.

Building your own accessibility information

You can reuse the descriptions above as they stand. Add what only you know:

• which of these surfaces your branches use, and in which languages;
• the tablet you use for the kiosk;
• how your staff help a client who cannot use the kiosk or a phone;
• how clients can contact you about accessibility.

Keeping your information current

When we change how any of these surfaces meets the requirements — a new feature, a fix from the lists above, or a newly cited version of the standard — we update this page and add the change to the list below. Check the list when you review your own accessibility information.

Date	Change
9 October 2026	First version.
13 October 2026	Tablet kiosk: the planned read-out and timeout fixes are updated — speech and tones only through wired headphones, no sound in the branch, no name spoken, a member of staff still types a name for a client who cannot see, and a touch keeps the confirmation screen open.
15 October 2026	Live ticket page: a warning two minutes before the 10 minutes run out, with an I need more time action that can be used up to ten times; the kiosk code changes every 10 seconds (the page said 24); the join-the-queue form shows each error next to its field. Appointment booking: focus moves to each new step, calendar days are read in the client's language, and the page for managing a booking has a main heading and dialogs that close with Escape and keep the focus. TV display: the page language follows the display, and the waiting list never goes below 2 % of the screen height, with a "+N" count for names that do not fit.
15 October 2026	Tablet kiosk: a touch keeps the confirmation screen open and starts its 60 seconds again, and the screen warns for its final 20 seconds with a notice and a countdown on Done; the open timeout gap is now only the warning by sound.
16 October 2026	Live ticket page: a notice asks the client to keep the page on screen, and Turn on sound plays a chime on the call and keeps the screen on while they wait; the "Your turn is approaching" notice is announced by the screen reader; the page refreshes at once when the client comes back to it.