Accessibility in customer service (EAA)

A person who cannot see opens the chat on your website. A person who cannot hear wants to dispute an invoice. An older customer zooms the text to 200 percent. Whether these three can resolve their request depends on details of the interface.

Since mid-2025, in many industries this is no longer a matter of goodwill. This guide explains what the European Accessibility Act and its German implementation require of customer service, and shows how to check your contact routes. It is not legal advice.

#The legal framework in brief

Directive (EU) 2019/882, known as the European Accessibility Act (EAA), sets accessibility requirements for certain products and services. Germany implements it through the Accessibility Strengthening Act (BFSG); the specific requirements are laid down in the BFSG Ordinance (BFSGV).

Other member states have their own implementing laws; this guide follows the German version.

Under Section 1 BFSG, the act applies to the following services provided to consumers after 28 June 2025:

• electronic communications services,
• certain elements of passenger transport services, such as websites, apps, e-tickets and real-time travel information,
• consumer banking services,
• e-books and dedicated software,
• e-commerce services.

The last group is broad. Anyone offering consumers contracts online, from an online shop to a plan booking, should check whether they are covered.

Responsibility lies with whoever offers the service, not with whoever supplies the software. If your chat, booking tool or voice dialogue comes from a vendor, the duty towards your customers still rests with you. That makes clear requirements in procurement all the more important.

Public bodies are subject to separate rules, for German federal authorities for instance BITV 2.0. The requirements are similar; duties and deadlines differ.

#What this means for customer service

One provision is particularly important for contact centres. Under Section 12 BFSGV, support services such as help desks, call centres, technical support, relay services and training services, where they exist, must provide information on the accessibility of the service and its compatibility with assistive technologies.

They must do so through accessible means of communication, and that has two sides.

First, your service must be able to answer: how does the app work with a screen reader? Is there an alternative to voice control? Second, that answer must be reachable by a route the person asking can actually use.

The same provision requires websites, online applications and mobile apps to be perceivable, operable, understandable and robust. These are the four principles of the Web Content Accessibility Guidelines. Information should be provided through more than one sensory channel.

For banks, Section 17 BFSGV adds specific requirements. Identification, authentication, electronic signatures and payment functions must be accessible, and information on how the service works should not exceed language level B2.

#The benchmark: WCAG 2.1 AA and EN 301 549

The law sets principles, not test steps.

In practice, the Web Content Accessibility Guidelines 2.1 at conformance level AA and the European standard EN 301 549 serve as the benchmark. The standard adopts the WCAG criteria for web content and adds requirements for software, documents and communication.

WCAG 2.2 has been available since 2023, with additional criteria on focus visibility and target sizes among others. If you are building something new, include them from the start.

#Channel by channel: what matters

Every contact route has its own pitfalls. The overview below covers the most common ones and is meant as a starting point for your review, not a complete list.

#Web messaging and chat

Chat is the channel with the most barriers, because it is dynamic. New messages must be announced without moving the focus. The window must be reachable and closable by keyboard, and it must not cover content that cannot be dismissed.

Watch out for time limits. A chat that ends after a short pause shuts out people who type more slowly or use assistive tools.

Web messaging in Univerx is asynchronous by design: customers can pause and pick up later. The article Accessible web messaging lists ten concrete points.

#Voice dialogues, IVR and voicebots

A voice dialogue system must not rely on fast speech input alone. Offer keypad input as an alternative, repeatable prompts and generous waiting times. People with speech impairments need a route that works without speaking.

Voicebots should speak slowly and clearly, allow follow-up questions and hand over to a person at any time. People who cannot hear need an equivalent written channel, such as chat, messaging or email, with the same options.

#Forms and email

Forms are where requests fail. Every field needs a visible label that is programmatically linked, error messages must say what is wrong and how to fix it, and entered data must not be lost when an error occurs.

For email replies: clear structure, real headings instead of bold text, links with descriptive text. PDF attachments should themselves be accessible, with tags, reading order and text alternatives.

#Shared view, signature and identification

Co-browsing, shared views and online signatures make life easier for many people, provided they are accessible. The agent's highlights must be understandable to screen readers, and signing must not require drawing with a mouse.

The Univerx Channel combines guided dialogue, shared view, signature and identification. Like all Univerx customer interfaces, it targets WCAG 2.1 AA and EN 301 549.

Sign4 / 5

Online ID card✓ Identity confirmed

Shared view

SignatureSigned

#Phone

For electronic communications services, the BFSGV requires real-time text in addition to voice (Section 14 BFSGV). That does not apply directly to service hotlines in other industries. Still, people who cannot use the phone should find an equivalent route without a long search.

#Plain language as part of accessibility

Accessibility is not only about technology. An answer that a screen reader reads out correctly but is written in bureaucratic language remains a barrier for many people. That is why the BFSGV requires information to be presented in an understandable way.

This applies to every text customers see: voice prompts, chat snippets, form help, email templates. Short sentences, familiar words, one idea per paragraph and concrete next steps help everyone, not only people with reading difficulties.

If you use AI for suggested replies or self-service, the same standard applies. A well-kept knowledge base with clearly written articles is the best foundation, because AI agents and employees draw the same clear answers from it.

#One request, worked through accessibly

A blind customer wants to query an incorrect direct debit. He uses a screen reader on his smartphone. On the website, he reaches the chat icon with a swipe gesture, and the screen reader announces "Start chat, button".

In the chat he describes the problem. Every reply is announced without him losing his place. When the agent needs a receipt, she sends a link into the guided dialogue. The upload button is labelled, and the confirmation is read aloud.

Halfway through he needs a break. The chat stays open; when he comes back, the history is still there. At the end, he receives the confirmation as a clearly structured message, not an image-only PDF.

Nothing in this flow is special treatment. Every step follows a criterion that can be tested: labelled buttons, announced status messages, no fixed time limit, accessible documents.

#Testing: how to establish where you stand

An accessibility review has several layers. None of them is enough on its own.

1. Automated tests: quickly find missing text alternatives, contrast errors and structural issues. They detect only part of the problems, though.
2. Keyboard test: every function must be reachable without a mouse, in a logical order and with visible focus.
3. Screen-reader test: on desktop and on mobile, with the assistive tools common on each.
4. Zoom and reflow: content must stay readable at high magnification, without horizontal scrolling.
5. Tests with disabled users: people with disabilities find problems no test step captures.

Document the result per interface and per release. A review from a year ago says little about today's version. Accessibility is a requirement for every release, not a one-off acceptance test.

#In procurement: what to ask of vendors

Many customer interfaces come from vendors: chat windows, voice dialogues, appointment booking, signatures. The responsibility towards your customers still remains yours. So ask clear questions in procurement.

• Which standard and version is the interface designed for, and has it been tested?
• Is there a test report per interface, with date, version and open issues?
• Which parts can be customised, such as colours, texts and time limits, without breaking accessibility?
• How are new releases tested before they roll out?
• How quickly are reported barriers fixed?

For its customer interfaces, Univerx targets WCAG 2.1 AA and EN 301 549.

What that means in practice and where we stand is described on the European Accessibility Act page in the Trust Center. Ask every vendor, including us, for the test status of each interface.

#And what about employees?

The EAA protects consumers. Contact-centre workplaces are governed by other rules. In Germany, for example, employees with severe disabilities are entitled to a workplace designed for their needs and to the technical aids they require (Section 164 SGB IX).

For software, this means the agent desktop should also work with keyboard, screen reader and magnification. Ask about it in procurement. An accessible workplace widens the pool of people you can recruit for your service.

#Organisation: information, feedback, training

Accessibility does not end at the interface. Three organisational building blocks belong to it.

Accessibility information: the law requires you to describe how your service meets the requirements and to make that information accessible. Keep it up to date and link it where people will find it.

Feedback route: offer a simple way to report barriers, and respond to reports reliably. Every report is a free test result.

Training: employees should know how your channels work with assistive technologies, how to handle calls through relay services and how to explain things in plain language. That is also the basis for the information duty under Section 12 BFSGV.

The German Federal Accessibility Agency offers further information and testing aids.

#Common mistakes that are easy to avoid

The last point also concerns proactive engagement and orchestration. The guide Journey orchestration explains how to make well-timed offers accessible.

#A roadmap in four steps

If you start today, you do not have to tackle everything at once. An orderly approach quickly clarifies where you stand and where the biggest gaps are.

1. Inventory: list every contact route and customer interface, including vendor components; clarify which fall under the law.
2. Initial review: per interface, an automated test plus keyboard and screen-reader tests; rank results by severity.
3. Fix: first the barriers that block a request entirely, then those that make it harder; involve vendors with deadlines.
4. Embed: include the review in every new release, update the accessibility information, analyse feedback.

Start with the contact route that carries most requests and with the steps where requests fail: getting in touch, proving identity, submitting a form. That is where the benefit to your customers is greatest.

#Checklist for your contact routes

#Next steps

Accessibility in customer service is not a special project but a matter of quality: what works for people with disabilities usually works better for everyone. That shows most clearly in chat, forms and plain language.

The glossary explains terms such as Accessibility Act & WCAG, web messaging and IVR. If you would like to walk through your contact routes together, get in touch.