As a result of the Barrierefreiheitsstärkungsgesetz (BFSG), companies will increasingly have to deal with the issue of accessibility in the coming months and years. Even though compliance with the accessibility requirements of the BFSG is an important first step towards digital accessibility, it is not enough to uncover all accessibility problems. UX research is a great tool to identify exactly those issues that are not covered by mere WCAG compliance.
The Barrierefreiheitsstärkungsgesetz (BFSG) is coming!
Digital accessibility has been a topic for quite some time. At least since the 1990s: Windows95 was the first operating system to include accessibility features as a default. The first version of the Web Content Accessibility Guidelines was published by the World Wide Web Consortium (W3C) in 1999[1]. For people with disabilities, digital accessibility (or the lack thereof) is an everyday issue. Nevertheless, it is often neglected by companies that offer digital products and services.
For many German companies, however, it will become relevant next year at the latest, as the Barrierefreiheitstärkungsgesetz (BFSG), which roughly translates to ‘accessibility enhancement act’, will come into force on June 28th, 2025. The BFSG adopted the European Accessibility Act (EAA) into national law in July 2021. The BFSG aims to improve the accessibility of products and services for people with disabilities or impairments and for older people[2].
In order to understand the implications of the BFSG for companies, we need to take a brief legal leap. Please note: I am not a lawyer, so the following information is not necessarily accurate ?
The BFSG defines accessibility requirements for certain products and services that are placed on the market or provided to consumers after the deadline (you can find out exactly which products and companies are affected in this overview). In the event of violations of the BFSG, the market surveillance office can order the product or service to be recalled or discontinued and may impose fines of up to €100,000[3].
The accessibility requirements are regulated in the Ordinance to the BFSG (BFSGV). In many articles, reference is made to the European standard EN 301 549 in the context of the BFSGV. This standard refers to the AA standards of the Web Content Accessibility Guidelines 2.1 (WCAG 2.1)[4].
In summary, this means that certain products and services must comply with conformance level AA of WCAG 2.1 by June 28th, 2025. But what are the WCAGs anyway? And what does conformance level AA mean?
The Web Content Accessibility Guidelines (WCAG)
The Web Content Accessibility Guidelines (WCAG) are an international standard for the accessible design of web content from the World Wide Web Consortium (W3C)[5]. Although version 2.2, which was updated in October 2023, is already available, EN 301 549 currently still refers to the previous version 2.1 (as of November 2024).
The WCAG are divided into the four principles: Perceivable, operable, understandable and robust. How exactly these principles can be adhered to is determined by a series of success criteria that are assigned to the individual principles[6].
The success criteria are divided into different priority levels – level A (highest priority), AA and AAA (lowest priority). In order to achieve conformance level AA, all success criteria of priority levels A and AA must be fulfilled. A detailed explanation of the individual success criteria and their compliance can be found on the W3C website[7]. If you would like to read more about the basics of accessibility in UX design, I recommend my colleague Catharina’s blog post: UX Accessibility 101
WCAG conformity is not enough
Now you might think: “All right, we’ll create a checklist of all the A and AA success criteria of WCAG 2.1, tick everything off and then our product will be accessible!”
This is definitely a good start and an important first step towards accessibility. It will also be sufficient to meet the requirements of the BFSG. Nevertheless, this approach does not guarantee the complete accessibility of a product.
The WCAG criteria are general guidelines for ensuring web accessibility. A sole focus on the WCAG criteria does not take into account the characteristics of the user group and the context of use.
UX research can uncover accessibility issues that are not considered by the WCAG. For example, it is possible that certain accessibility problems occur more frequently or less frequently in certain user groups than in the overall population. In addition to adhering to the WCAG success criteria, the W3C itself also recommends conducting UX research with people with disabilities.[8]
An example of how UX research can uncover additional accessibility issues comes from James Buller, who works as a UX researcher for the British Home Office. He and his team carried out usability tests to find out how users proceed when applying for a passport[9]. In a session with a deaf participant, a problem was identified with the contact form: The participant had to enter a telephone number in the contact form. She wanted to indicate that she did not want to be called as she was deaf. However, the input field for the telephone number only allowed the entry of numbers, so that she could not add her comment. Although the form was WCAG-compliant, it was not accessible as it did not include this option.
UX Research for everyone! – Ideas for more inclusion and accessibility
In order to design products and services in a user-friendly way, we apply the process of human-centered design. The aim of human-centered design is to make products and services usable and functional[10]. In the process, we focus on the user needs and user requirements, among other things.
This also includes access needs. In the context of human-centered design, access needs refer to all the requirements that must be met for a user to be able to use a product successfully. Access needs are user needs!
The topic of accessibility should therefore be taken into account in every step of the human-centered design process, i.e. also in UX research. The following section presents some ideas for establishing accessibility practices into UX research.
Ideally, a percentage of the sessions in each research project should be conducted with participants who correspond to the user group, have a disability and may also use assistive technologies. If UX research is carried out regularly in a project and it is ensured that a certain proportion of participants with different disabilities are always included, the probability of uncovering all relevant accessibility problems increases over time.
When we conduct UX research with people with disabilities, it is important to make the research process accessible. Generally speaking, UX research should of course always be user-centered and focused on the needs of the user. For participants with disabilities, however, special attention must be paid to accessibility. Because if our research is not accessible, participants with disabilities will not be able to participate as effectively as participants without disabilities. For this reason, we need to identify in advance what access needs our participants in UX research have.
Depending on the target group and disability, we have to ask ourselves different questions, e.g.: Should the test be carried out in the office, at the participants’ homes or remotely? Is the prototype used to carry out the usability test accessible to everyone? Can the questionnaire be completed with keyboard-only navigation or with a screen reader?
A case study for accessible UX research is the BMBF-funded MightyU project. The aim of the project was to develop a serious game with which children with infantile cerebral palsy (ICP) can carry out their therapy exercises at home in a playful and self-effective way. In this project, a number of research challenges had to be taken into account: The children and parents are often under a great deal of time and mental strain due to the illness. In addition, the severity of the illness varies greatly from person to person. The tests were carried out at the children’s homes in order to get to know the context of use and to take up as little of the children’s and parents’ time as possible. In addition, the father of an affected child was part of the consortium when planning the UX research in order to contribute and evaluate ideas.
It is therefore important to ask the right questions, gather information and, if necessary, get creative before the research. This allows participants with and without disabilities to get involved and enables us to obtain exciting and reliable findings.
Inclusive personas
A persona is a fictitious description of a typical user. Personas help the team to feel more empathy towards the various user groups and thus make user-centered decisions throughout the course of the project[11].
To all readers who have been involved in the development of personas, I would like to ask the following question: How many of these personas had a disability that affected the way they were able to use the product or service? From my experience, I would guess that the vast majority of personas did not have a disability.
In order to consider accessibility as early as possible, you should develop different personas with different disabilities that use different types of assistive technologies.
When developing personas with disabilities, various aspects are important: Firstly, the personas should be tailored to the context of use of the product or service. This means taking into account the characteristics of the users, their goals and tasks and their resources and environment.
One should also be aware that the persona can and should never represent an entire social group (e.g. all people with motor disabilities). This carries the risk of overgeneralization.
Last, but certainly not least: personas should be continuously validated, corrected and supplemented by conducting UX research. Personas that are only based on the team’s assumptions are also called proto personas[12] and harbor the risk that decisions in the design process are made on the basis of (possibly) incorrect assumptions.
It is also important that the participants in UX research really fit the user group. When recruiting, the only screening criterion should not be that the participants have a certain disability. Many factors can influence user needs and the way they interact with the product – e.g. age, level of education, gender, technology experience and personality. You can use the developed proto persona to define the right screening criteria for recruiting participants.
Léonie Watson has summarized this well with the following example[13]:
“If you’re building an app for teenage girls, there’s no point in asking a forty year old [sic] man to test it just because he happens to use a screen reader. In the same way his attitude and skills will be different in general, his ability to use his assistive technology will also be different from someone twenty-five years his junior.”
Léonie Watson, member of the W3C Board of Directors
A great resource to use as a guide when developing personas with disabilities for the first time are the accessibility personas from the British Central Digital and Data Office. These personas represent hypothetical users with a range of different access needs. As these personas are quite general, they should only be used as a basis for developing your own personas. You can also consider using AI tools to develop your personas. If you would like to learn more about this exciting topic, please read Thomas’ blog article on AI personas.
Conclusion
„Accessibility is essential for some, and useful for all.“
Shawn Lawton Henry, W3C Web Accessibility Initiative (WAI) Program Lead[14]
Finally, an argument for why all UX professionals should have an interest in accessibility. The primary goal of digital accessibility is to make digital content and technologies accessible to people with disabilities. Of course, it is not only people with disabilities who benefit from good accessibility, but all users. A study from the International Journal of Human-Computer Studies shows that a high level of accessibility is linked to a good user experience[15]. We all benefit from digital accessibility if we are temporarily (e.g. due to a broken arm) or situationally impaired (e.g. because we are in a noisy environment). Furthermore, it is not unlikely that you yourself will acquire a disability in the course of your life, e.g. as a result of an accident, illness or ageing.
When implementing digital accessibility, WCAG compliance is not the only important factor. In addition to WCAG compliance, it is worth conducting UX research with a focus on accessibility. You should make sure that the UX research is accessible to all participants. In this way, you can gradually remove barriers in your digital products – and increase your potential user base at the same time.
If you want to learn more about this topic: Our new podcast 2025: Odysee Accessibility will soon be released, focusing on accessibility and AI.
Would you like to improve the accessibility of your product?
Do you need support for more digital accessibility?
Quellen
[1] Tasyürek, D. (2022, Oktober 25). The History of Digital Accessibility. Storyly. https://www.storyly.io/post/the-history-of-digital-accessibility
[2] Der Beauftragte der Bundesregierung für Informationstechnik. (2023, Dezember 19). Barrierefreiheitsstärkungsgesetz (BFSG). Portal Barrierefreiheit der Dienstkonsolidierung des Bundes. https://www.barrierefreiheit-dienstekonsolidierung.bund.de/Webs/PB/DE/gesetze-und-richtlinien/barrierefreiheitsstaerkungsgesetz/barrierefreiheitsstaerkungsgesetz-node.html
[3] Barrierefreiheitsstärkungsgesetz: Barrierefreiheit wird für Privatunternehmen Pflicht. (o. J.). Industrie- und Handelskammer für München und Oberbayern. https://www.ihk-muenchen.de/de/Service/Recht-und-Steuern/Werbung-Fairer-Wettbewerb/barrierefreiheitsstaerkungsgesetz/
[4] Der Beauftragte der Bundesregierung für Informationstechnik. (2024). Harmonisierte Europäische Norm (EN) 301 549. Portal Barrierefreiheit der Dienstkonsolidierung des Bundes. https://www.barrierefreiheit-dienstekonsolidierung.bund.de/Webs/PB/DE/gesetze-und-richtlinien/barrierefreiheitsstaerkungsgesetz/barrierefreiheitsstaerkungsgesetz-node.html
[5] Lawton Henry, S. (2024, März 7). WCAG 2 Overview. World Wide Web Consortium (W3C). https://www.w3.org/WAI/standards-guidelines/wcag/
[6] Hellbusch, J. (2024). Die vier Prinzipien der Web Content Accessibility Guidelines (WCAG) 2.2. Barrierefreies Webdesign. https://www.barrierefreies-webdesign.de/richtlinien/wcag-2.2/
[7] Eggert, E., & Abou-Zahra, S. (2023, November 12). How To Meet WCAG (Quick Reference). World Wide Web Consortium (W3C). https://www.w3.org/WAI/WCAG22/quickref/
[8] Lawton Henry, S. (2021, Juni 1). Involving Users in Evaluating Web Accessibility. W3C Web Accessibility Initiative (WAI). https://www.w3.org/WAI/test-evaluate/involving-users/
[9] Firth, A. (2020). Practical web inclusion and accessibility: A comprehensive guide to access needs. Apress.
[10] German UPA e.V. (o. J.). Menschzentrierte Gestaltung nach DIN EN ISO 9241-210. German UPA. Abgerufen 17. April 2024, von https://germanupa.de/wissen/berufsbild-usability-ux-professional/grundlegend/menschzentrierte-gestaltung
[11] Harley, A. (2015, Februar 16). Personas Make Users Memorable for Product Team Members. Nielsen Norman Group. https://www.nngroup.com/articles/persona/
[12] Laubheimer, P. (2020, Juni 21). 3 Persona Types: Lightweight, Qualitative, and Statistical. Nielsen Norman Group. https://www.nngroup.com/articles/persona-types/
[13] Kalbag, L. (2017). Accessibility for everyone. A Book Apart.
[14] Dobbs, S. (2024, Mai 31). Web Accessibility: Removing barriers, designing a web for everyone. World Wide Web Consortium (W3C). https://www.w3.org/blog/2024/web-accessibility-removing-barriers-designing-a-web-for-everyone/
[15] Aizpurua, A., Harper, S., & Vigo, M. (2016). Exploring the relationship between web accessibility and user experience. International Journal of Human-Computer Studies, 91, 13–23. https://doi.org/10.1016/j.ijhcs.2016.03.008