Chapter 12 of EN 301549: Documentation for digital Accessibility

Today we would like to address the documentation requirements arising from accessibility standards. Specifically, we will focus on Chapter 12 of EN 301 549.

Context of Chapter 12 EN 301 549

To briefly explain: EN 301 549 is the leading standard for digital accessibility in the European Union. It defines essentially all relevant requirements. However, one chapter is often overlooked – not least because it has played little role for many traditional websites: Chapter 12.

This chapter focuses less on technical requirements and more on documentation. This is precisely why it has not been particularly relevant for many websites, as most websites lack additional product or user documentation.

Declaration of Conformity aka Accessibility Statement Required

What is generally required—regardless of whether it is a public or private institution—is a declaration of conformity, often also referred to as an accessibility statement. The name is ultimately secondary—what matters is that it exists.

For public bodies, this declaration must be publicly accessible, and this is the case for most websites today. The term "accessibility statement" has also become established in the context of the German Federal Act on the Strengthening of Accessibility (BFSG). However, its precise form is still completely open.

Further documentation is usually not available for traditional websites. The situation is different for applications: for example, browser-based web applications, desktop applications, some apps—and, of course, hardware.

This is where the topic becomes particularly interesting. Since the Accessibility Strengthening Act (BFSG) came into force on June 28, 2025, certain hardware products must be at least partially accessible. This includes computers, smartphones, internet access services, and peripheral devices such as internet or DSL modems and e-book readers.

These devices often lack a traditional graphical user interface. Instead, they typically have a display for showing information and physical controls like buttons or switches. A graphical interface—if it exists at all—is often an afterthought.

This is precisely where the question of accessibility becomes particularly relevant:

What functionalities are provided?

And how are they provided so that they are accessible to everyone?

Let's now take a closer look at Chapter 12.

Section 12.1 deals with the general documentation requirements. It specifies what information must be included in the documentation with regard to accessibility.

Information on Accessibility and Special Functions

Specifically, this begins with Chapter 12.1.1: Documentation on Compatibility and Accessibility. When we talk about documentation in the context of accessibility, it's primarily about listing all the functionalities that the company or the application itself provides.

This means that if an application provides its own accessibility features—for example, a screen magnifier, a screen reader, voice control, or keyboard navigation—then all of this must be documented. Users typically cannot identify this information themselves. They need to know which features are available and how to activate them.

This is less critical for traditional websites, as the interaction patterns are largely known, and they use their own settings and assistive technologies. Users generally know how to use the keyboard or a screen reader. However, this is different for hardware or more complex applications: If, for example, keyboard navigation is provided, it must be clear how it works, what accessories are needed, and which special functions are activated.

A concrete example: Some ATMs have a voice output feature that is activated as soon as headphones are plugged in. Users need to know that this jack exists, that the voice output starts, and what functionalities it offers. The same applies to web applications: If special text-to-speech or accessibility features are provided, this must be documented. Even things like high-contrast designs or dark mode don't necessarily count as accessibility features, but can still be listed in the documentation.

Furthermore, it must be explained how to use the functions. For example, there are differences in keyboard controls between Windows, Linux, and Mac. For dedicated screen reader functions or keyboard shortcuts, their use must be clearly documented – otherwise, users won't know how to use them.

Another important point: the information must be easy to find. This could be, for example, a separate chapter in the technical documentation or – in the case of web applications – a footer item titled "Accessibility Information."

Accessible Documentation

VChapter 12.1.2 deals with the accessible provision of documentation. Here, the following applies: Regardless of whether it is dedicated accessibility documentation or the documentation for the entire product, it must be digitally and accessible.

• Browser-based documentation must meet the requirements of Chapter 9.

• PDFs must meet the requirements of Chapter 10.

Effective Communication via Assistive Technologies

The second part of Chapter 12 deals with technical support. Here, too, the principle applies: support must be provided in an accessible manner, as described in Section 12.2.2.

This isn't so complicated either: support must be accessible through various channels to cover different sensory needs.

• Blind people, for example, often prefer telephone support.