Leitfaden Barrierefreie Software am Arbeitsplatz
- Anspruch:
- Aufwand:
- Zielgruppe: Entwicklung
Dieser Leitfaden bietet einen Einstieg in die Entwicklung barrierefreier Software.
Der Schwerpunkt liegt dabei auf dem grundsätzlichen Vorgehen. Um welchen Typ von Software handelt es sich? Gibt es eine webbasierte Oberfläche, wird die Software überwiegend am PC genutzt oder eher mobil in Form einer App?
Wie sollte Barrierefreiheit im Prozess der Softwareentwicklung berücksichtigt werden? Wie vermeidet man möglichst Mehraufwand und stellt sicher, dass die Software später optimal von Menschen mit unterschiedlichen Einschränkungen genutzt werden kann. Dabei können die Einschränkungen sowohl aufgrund einer Behinderung bestehen, als auch situationsbedingt sein, zum Beispiel, wenn Licht beim Lesen blendet.
Standardsoftware wie Office-Pakete und darin enthaltene Textverarbeitungsprogramme werden in der Regel fertig eingekauft. Meist kommen hier nur wenige große Anbieter infrage, wenn man eine Kompatibilität der mit der Software erstellten Dokumente mit Kunden, Geschäfts- und Kooperationspartnern sicherstellen möchte. Insbesondere amerikanische Produkte bieten aufgrund der dort geltenden gesetzlichen Regelungen und Beschaffungsstandards bereits einen guten Stand der Barrierefreiheit, sodass solche Software bereits gut mit Hilfsmitteln kompatibel ist.
Da viele Anwenderinnen und Anwender gewöhnt sind mit diesen Produkten zu arbeiten, kann es hilfreich sein, sich mit der Umsetzung der Barrierefreiheit und der Art, wie Unterstützung für Hilfsmittel in den Produkten angeboten wird, vertraut zu machen. Soll eine eigene Software entwickelt werden, ist es sinnvoll sich an diesen Bedienkonzepten bezüglich der Unterstützung von Hilfsmitteln zu orientieren.
In vielen Branchen oder Bereichen öffentlicher Verwaltung ist Spezialsoftware im Einsatz. Die Software wird möglicherweise nicht direkt für einzelne Kunden und auch nicht nur für die hausinterne Nutzung entwickelt. Sie orientiert sich aber eng an den Bedürfnissen der Unternehmen einer Branche beziehungsweise Behörden eines Handlungsfelds.
Entwickler haben hier die Möglichkeit schrittweise Einfluss auf die Barrierefreiheit zu nehmen, auch wenn die Kunden dies möglicherweise noch nicht explizit fordern. Der mögliche Kundenkreis kann so erweitert werden und frühzeitig eine umfassende Expertise aufgebaut werden. Viele Anforderungen, zum Beispiel die Möglichkeit der Individualisierbarkeit der Benutzeroberfläche, verbessern gleichzeitig auch die Ergonomie der Software. Dies ist für die häufig sehr komplexen und mit vielen Funktionen ausgestatteten branchenspezifischen Softwarelösungen häufig ein Gewinn und kann so gleichzeitig die Zufriedenheit der Kunden mit der Software erhöhen.
Die Unternehmen haben so die Möglichkeit dem Fachkräftemangel aktiv zu begegnen, indem sie Menschen mit Behinderung beschäftigen. Dabei entgehen sie der Notwendigkeit aufwändiger nachträglicher Anpassungen der Software in Einzelfällen bei jedem Update.
Während die Spezialsoftware sich an Anwendergruppen richtet, ist die Individualsoftware speziell auf die Bedürfnisse der Kunden zugeschnitten. Die Entwicklungskosten liegen dadurch sehr hoch. Der Kunde hat dafür in diesem Fall aber auch alle Möglichkeiten die Anforderungen an die Software zum Beispiel über ein Lastenheft vorzugeben. Neben den funktionalen Anforderungen sollte Barrierefreiheit und Ergonomie hier von Anfang an eine gleichwertige Rolle spielen.
Die Möglichkeiten beziehungsweise Wege, auf denen am Arbeitsplatz Einfluss auf die Barrierefreiheit der Software-Lösungen genommen werden kann, hängen nicht nur von den drei genannten Software-Kategorien ab. Auch die Art der Bereitstellung der Software innerhalb der Unternehmens-IT hat Einfluss auf die Barrierefreiheit.
Unternehmen nutzen immer häufiger cloudbasierte Software-Lösungen, unter anderem in Form von „IaaS” (Infrastructure as a Service), „PaaS” (Platform as a Service) und „SaaS” (Software as a Service). Die drei Modelle bieten unterschiedliche Möglichkeiten der Einflussnahme für die Unternehmen. Je mehr Kontrolle die IT-Administratorinnen und IT-Administratoren des Unternehmens haben, desto so mehr Möglichkeiten bestehen zum Beispiel auch Hilfsmittel zu unterstützen oder Anpassungen vornehmen zu können. Dabei hat das Unternehmen die größte Kontrolle bei IaaS und die geringste beim SaaS-Modell. Gerade Standardsoftware wird häufig als SaaS angeboten, wie beispielsweise Microsoft 365.
Die Berücksichtigung von Standards in der Software-Entwicklung sollte selbstverständlich sein. Normen zur Softwareergonomie, wie beispielsweise die Normenreihe zur DIN EN ISO 9241, definieren Qualitätskriterien für Software, die den meisten Entwickler*innen gut bekannt sind.
In der DIN EN ISO 9241 ist das Thema unter anderem in Teil 20 „Leitlinien für die Zugänglichkeit der Geräte und Dienste in der Informations- und Kommunikationstechnologie“ berücksichtigt. Zukünftig soll dieser Teil unter dem Titel „Ein ergonomischer Ansatz für die Barrierefreiheit innerhalb der ISO 9241-Reihe“ das Qualitätskriterium Barrierefreiheit mit der Software-Ergonomie noch enger verknüpfen.
Themen wie die Menschzentrierte Gestaltung interaktiver Systeme und Gebrauchstauglichkeit beziehungsweise Usability sind eng mit der Barrierefreiheit dieser Systeme verknüpft. Die Themengebiete haben Anforderungen, die sich bei Themen wie der Individualisierbarkeit überlappen, aber auch jeweils darüber hinausgehende Anforderungen. Teil 171 der DIN EN ISO 9241 beinhaltet daher die „Leitlinien für die Zugänglichkeit von Software“.
Die Berücksichtigung der Anforderungen der Barrierefreiheit führt dazu, dass damit auch viele Anforderungen älterer Nutzender berücksichtigt werden und die Entwicklung insgesamt stärker user-zentriert stattfindet.
Überblick über Standards und Publikationen im Zusammenhang mit digitaler Barrierefreiheit von Software:
-
Grundlagen
- Normenreihe DIN EN ISO 9241 Ergonomie der Mensch-System-Interaktion
- DIN EN 301 549 Barrierefreiheitsanforderungen für IKT-Produkte und -Dienstleistungen
- DGUV Information 215-450 Softwareergonomie
- BMAS-Leifaden „Zusammenarbeiten. Inklusion in Unternehmen und Institutionen. Ein Leitfaden für die Praxis. Erweiterung Informationstechnologie am Arbeitsplatz.
- DIN Fachbericht 124 Gestaltung barrierefreier Produkte
- Inclusive Design Principles
-
Benutzungsschnittstellen und Anforderungen der Nutzenden
- Dreiteilige Norm ISO/IEC 29138 Informationstechnik – Barrierefreie Benutzungsschnittstellen
(Auf Englisch verfügbar: frei über ISOInformation technology – Accessibility considerations for people with disabilities) - Anforderungen von Menschen mit Lernschwierigkeiten:
DIN EN 21801 Kognitive Zugänglichkeit - Projekt des : DIN-Normenausschuss Ergonomie (NAErg)
ISO/DIS 24553 Ergonomie – Barrierefreie Gestaltung – Einfachheit der Handhabung
(Englischer Titel: ) ISO/DIS 24553 Ergonomics – Accessible design – Ease of operation
- Dreiteilige Norm ISO/IEC 29138 Informationstechnik – Barrierefreie Benutzungsschnittstellen
-
Prozessorientierte Ansätze
- Prozesse innerhalb eines Unternehmens für die Entwicklung barrierefreier IKT-Produkte optimieren:
- in deutsch: ISO/IEC 30071-1:2019-05 Informationstechnik - Entwicklung barrierefreier Nutzerschnittstellen - Teil 1: Eine Anleitung für die Praxis zur Erstellung barrierefreier IKT-Produkte und -Dienste
- in englisch: ISO/IEC 30071-1:2019 - Information technology -- Development of user interface accessibility -- Part 1: Code of practice for creating accessible ICT products and services
- (Englischer Titel: DIN EN 17161 Design für alle - Barrierefreiheit von Produkten, Waren und Dienstleistungen nach einem „Design für alle“-Ansatz - Erweitern des BenutzerkreisesDesign for All - Accessibility following a Design for All approach in products, goods and services - Extending the range of users)
- Berücksichtigung der konkreten Standards der digitalen Barrierefreiheit in Inklusionsvereinbarungen
- Berücksichtigung der Barrierefreiheit bei der Produktentwicklung aus der Perspektive verschiedener typischer Rollen (Product Owner, User Research, Interaction Design, Visual Design, Development, Content Design, Testing) in einem Guide der Schweizerischen Bundesbahnen SBB.
- Prozesse innerhalb eines Unternehmens für die Entwicklung barrierefreier IKT-Produkte optimieren:
-
Individuelle Einstellungen
- Norm ISO/IEC 24786 Informationstechnik - Zugänglichkeit - zugängliche Benutzungsschnittstellen für Zugänglichkeitseinstellungen
(Englischer Titel: ) ISO/IEC 24786 Information technology - User interfaces - Accessible user interface for accessibility settings - Mit einem Schwerpunkt auf den Prozessen im Unternehmen: Informationstechnologie – Barrierefreiheit von Benutzungsschnittstellen-Komponenten – Teil 5: Barrierefreie Benutzungsschnittstelle für Barrierefreiheitseinstellungen auf Informationsgeräten ISO/IEC DIS 20071-5 (Entwurf)
(Englischer Titel: ) Information technology - User interface component accessibility - Part 5: Accessible user interface for accessibility settings on information devices
- Norm ISO/IEC 24786 Informationstechnik - Zugänglichkeit - zugängliche Benutzungsschnittstellen für Zugänglichkeitseinstellungen
-
Spezielle Software
- Abschnitt „A.2.5 Accessible web conferencing software“ in ISO 17069 Barrierefreie Gestaltung - Hinweise und Hilfsmittel für barrierefreie Veranstaltungen
(Englischer Titel: ISO 17069 Accessible design — Consideration and assistive products for accessible meeting - Software für geschlossene Systeme wie Bürogeräte:
ISO/IEC 10779 Informationstechnik - Bürogeräte - Leitfaden für die Zugänglichkeit für Ältere und Personen mit Einschränkungen
(Englischer Titel: ) ISO/IEC 10779 Information technology — Office equipment — Accessibility guidelines for older persons and persons with disabilities - Vorausschauende Betrachtung der Interaktionstechnologien in zukünftigen Geräten und Angeboten auf Basis der Anforderungen der Nutzenden (Stand: 2011):
ETSI EG 202848 Human Factors; Inclusive eServices for all: Optimizing the accessibility and the use of upcoming user-interaction technologies.
- Abschnitt „A.2.5 Accessible web conferencing software“ in ISO 17069 Barrierefreie Gestaltung - Hinweise und Hilfsmittel für barrierefreie Veranstaltungen
-
Kompatibilität zu Hilfsmitteln bzw. assistiven Technologien auf verschiedenen Plattformen
- ISO/IEC 13066 Informationstechnik - Interoperabilität mit Assistenztechnologie bzw. unterstützender Technologie (AT) (Englischer Titel: Information technology - Interoperability with assistive technology (AT) )
- Norm: Teil 1: Erfordernisse und Empfehlungen für die Interoperabilität
(Englischer Titel: Part 1: Requirements and recommendations for interoperability - Technische Regel: Teil 2: Windows Anwendungsprogrammierschnittstelle (API) für Barrierefreiheit
(Englischer Titel: Part 2: Windows accessibility application programming interface (API) - Technische Regel: Teil 3: Anwendungssschittstelle für barrierfreien Zugang IAccessible2
(Englischer Titel: Part 3: IAccessible2 accessibility application programming interface (API) - Technische Regel: Teil 4: Linux/UNIX Barrierefreiheit grafische Umgebungen APIs
(Englischer Titel: ) Part 4: Linux/UNIX graphical environments accessibility API - Technische Regel: Teil 6: Zugänglichkeit der Java Anwendungsprogrammierschnittstelle (API)
(Englischer Titel: Part 6: Java accessibility application programming interface (API)
- Norm: Teil 1: Erfordernisse und Empfehlungen für die Interoperabilität
- ISO/IEC 13066 Informationstechnik - Interoperabilität mit Assistenztechnologie bzw. unterstützender Technologie (AT) (Englischer Titel: Information technology - Interoperability with assistive technology (AT) )
Die Grundsätze für die Gestaltung barrierefreier Software sind in der DIN EN 301 549 zu finden.
Die Norm steht dabei nicht alleine, sondern ist eingebettet in die bereits erwähnten Standards zur Softwareergonomie und baut auf internationalen Richtlinien für barrierefreie Web-Inhalte auf.
Die Barrierefreiheitsanforderungen für IKT-Produkte und Dienstleistungen gliedern sich im Standard in mehrere Teile:
- funktionale Leistungsfähigkeit
- allgemeine Anforderungen
- spezielle Formen der IKT (neben Software unter anderem Web, Hardware, IKT mit Videofähigkeit sowie Zweiwege-Sprachkommunikation)
Im Folgenden wird auf die grundlegenden Anforderungen an Software näher eingegangen. Diese sollten bei der Entwicklung von Software berücksichtigt werden, können aber auch bei der Beschaffung von Software genutzt werden. Für die öffentliche Beschaffung (Public Procurement) wurden die Anforderungen ursprünglich entwickelt.
Auf die Anforderungen spezieller IKT in Form von webbasierten Anwendungen und mobilen Anwendungen wird in den folgenden Abschnitten noch einmal gesondert eingegangen.
Arbeitsumgebung
Wenn eine Software auf einem „geschlossenen System“ ausgeführt wird, muss die Software zusätzliche Anforderungen erfüllen, um barrierefrei nutzbar zu sein. Ein geschlossenes System ist nicht unbedingt ein spezielles Kioskterminal, an das keine Hilfsmittel anschließbar sind. Darunter werden auch Computer verstanden, die „Endbenutzer daran hindern, Einstellungen zu ändern oder Software zu installieren“. In diesem Fall heißt es im Standard „funktional geschlossen“, in Teilen oder vollständig.
Dieser Fall kann eintreten, wenn die Mitarbeitenden am Arbeitsplatz nur eingeschränkte Rechte besitzen Einstellungen im Betriebssystem vorzunehmen und dadurch zum Beispiel die Bedienungshilfen oder andere Schrift- beziehungsweise Farbeinstellungen nicht genutzt werden können.
Wenn so etwas bereits bei der Entwicklung einer Software beziehungsweise bei der Beschaffung einer Software bekannt ist, sollte dies an dieser Stelle bereits entsprechend berücksichtigt werden.
Anforderungen an die Software
Bei der Gestaltung barrierefreier Software sind die Grundsätze der in der Norm DIN EN 301 549 in Abschnitt 4 „Funktionale Leistungsfähigkeit“ beschriebenen Aussagen zu berücksichtigen. Die beschriebene funktionale Leistungsfähigkeit der Software soll es den Benutzern ermöglichen alle Funktionen der Software:
- zu lokalisieren,
- zu identifizieren und
- auszuführen.
Dies muss unabhängig von:
- physischen,
- kognitiven oder
- sensorischen Fähigkeiten
möglich sein.
Die Anforderungen an die zu entwickelnde beziehungsweise zu beschaffende Software entsprechen den bereits aus dem barrierefreien Webdesign bekannten Bereichen. Nach Einhaltung dieser Anforderungen ist die Anwendung:
- wahrnehmbar (Anforderungen unter 11.1 der Norm),
- bedienbar (Anforderungen unter 11.2 der Norm),
- verständlich (Anforderungen unter 11.3 der Norm) und
- robust (Anforderungen unter 11.4 der Norm).
Der Zusammenhang zwischen der funktionalen Leistungsfähigkeit und den Anforderungen dieser vier Grundprinzipien sind in Tabelle B.2 in Anhang B der Norm dargestellt. Beispielsweise ist die Umsetzung der Anforderung 11.1.4.4.1/2 aus dem Bereich der „Unterscheidbarkeit“ zum Ändern der Textgröße innerhalb der Software erforderlich, um die funktionale Leistungsfähigkeit der Software für die Nutzung mit eingeschränkter Sehfähigkeit sicherzustellen.
Darüber hinaus gibt es für Software weitere Anforderungen, die unter anderem die Dokumentation der Software betrifft, die ebenfalls barrierefrei verfügbar sein muss. Auch soll die Unterstützung der dokumentierten Barrierefreiheitsdienste der jeweiligen Plattform barrierefrei sein, um die Kompatibilität zu Hilfsmitteln sicherzustellen. Werden mit der Software in irgendeiner Form Inhalte durch die Nutzenden erstellt (Texte, Videoinhalte und so weiter), sind zusätzlich die Anforderungen zur Erstellung barrierefreier Inhalte durch Autorenwerkzeuge zu berücksichtigen.
Für die Umsetzung einzelner Anforderungen aus der DIN EN 301 549 kann es hilfreich sein, weitere bereits in Abschnitt „Barrierefreiheit als Qualitätskriterium“ erwähnte Standards hinzuzunehmen. Ein Beispiel hierfür wäre aus der Normenreihe DIN EN ISO 9241 der Teil 171: Leitlinien für die Zugänglichkeit von Software. Beispielsweise ist hier die barrierefreie Interaktion über Dialoge detaillierter behandelt.
Die Richtlinie 2016/2102 über die Barrierefreiheit von Webseiten und mobilen Anwendungen öffentlicher Stellen, kurz Web-Richtlinie legt die Anforderungen der Barrierefreiheit fest.
Im deutschen Recht wurde die Web-Richtlinie für die Verwaltung durch die Barrierefreie-Informationstechnik-Verordnung (BITV) umgesetzt. Diese Anforderungen können durch Konformität mit der harmonisierten Norm DIN EN 301 549 erfüllt und nachgewiesen werden.
Aus der Norm 301 549 ist für webbasierte Anwendungen insbesondere zusätzlich der Abschnitte 9 „Web“ relevant.
In Anhang A der Norm ist in Tabelle A.1 der Zusammenhang zwischen der Norm und der EU-Web-Richtlinie dargestellt. Dabei wird für jede Anforderung aus der Norm der Bezug zu den vier in der EU-Webrichtlinie geforderten Grundprinzipien der digitalen Barrierefreiheit Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und technologische Robustheit hergestellt.
Die Anforderungen in Abschnitt 9 der Richtlinie geben dabei den Inhalt der W3C-Empfehlung WCAG 2.1 wieder.
Hier finden Sie zusätzliche Informationen in Publikationen, Leitfäden und Schulungen zur Entwicklung barrierefreier webbasierter Anwendungen:
-
Sieben einfache Richtlinien zur Umsetzung von Barrierefreiheit:
Designing for accessibility is not that hard -
Online-Anleitungen zur zugänglichen Umsetzung dynamischer Komponenten im Web:
Access & Use -
WAI Tutorials für einzelne Web-Elemente bzw. Navigationskonzepte wie Carousel Concepts:
Web Accessibility Tutorials - Guidance on how to create websites that meet WCAG -
Einführungskurs in Web-Accessibility:
W3C Introduction to Web Accessibility -
Vierteilige Video-Reihe von Stifter-helfen (IT-Portal für Non-Profits und Vereine):
Barrierefreies Internet -
Richtlinien für Designer in Bezug auf Farbe, Lesereihenfolge und Schriften:
Inklusives Design – Barrierefreiheit Richtlinien für Designer -
Barrierefreie Webinhalte und Web-Applikationen mit Accessible Rich Internet Applications (ARIA):
W3C-Empfehlung ARIA in HTML -
Umsetzungshilfen für öffentliche Stellen und Interessierte des „Informationstechnik Zentrums Bund“:
- Informationen zur Komponenten-Bibliothek für die Barrierefreiheit, die zum Ziel hat wiederverwendbare Web Components barrierefrei anzubieten.
- Komponenten-Bibliothek für die Barrierefreiheit bei GitHub: KoliBri
Apps können entweder für spezielle Plattformen, wie Android und iOS als native App, entwickelt werden oder zum Beispiel als Web-App oder hybride App, die auf mehreren Plattformen funktioniert. In allen Fällen ist es möglich Barrierefreiheit zu berücksichtigen.
Mobile Geräte wie Smartphones und Tablets bieten Menschen mit Behinderungen bereits gute Voraussetzungen zur Nutzung. Die Spracheingabe und die Sprachausgabe ist auf den Plattformen der Mobilgeräte bereits integriert und muss nicht, wie bei Windows-PCs üblich, erst als zusätzliches Hilfsmittel teuer beschafft werden.
Grundsätzliche Anforderungen
Das wichtigste ist bei der barrierefreien Gestaltung der Apps, einen möglichst großen Anwenderkreis bei der Entwicklung zu berücksichtigen. Das sind Menschen mit Behinderungen, die eventuell per Sprachausgabe ihr Mobilgerät bedienen, aber auch ältere Nutzende oder Personen in Situationen, die die Nutzung einschränken. Dies kann zum Beispiel in sehr hellen oder lauten Umgebungen der Fall sein oder an Arbeitsplätzen, an denen das Mobilgerät in einer Schutzhülle verpackt nicht problemlos mit Wischgesten bedient werden kann.
Neben den technischen Anforderungen an eine barrierefreie App gibt es allgemeine Gestaltungsprinzipien, die eingehalten werden müssen. Dazu zählen unter anderem gute Kontraste für die Inhalte der Apps, aber auch zum Beispiel ein verständliches Bedienkonzept. Diese entsprechen den bereits zuvor genannten grundsätzlichen Richtlinien für die barrierefreie Software-Entwicklung.
Damit zum Beispiel die Sprachausgabe der jeweiligen Plattform auf die Inhalte zugreifen kann, müssen bestimmte technische Standards eingehalten werden. Diese sind in den Anleitungen der entsprechenden Plattform beschrieben.
Voraussetzung für die Nutzung der Apps mit diesen integrierten Hilfsmitteln ist jedoch eine barrierefreie Gestaltung der App von Anfang an.
Die Barrierefreiheit der Software sollte bereits während der Entwicklung auf Einhaltung der Barrierefreiheitsstandards geprüft werden. Existieren bereits (agile) Prozesse zur Qualitätssicherung der Software, sollte Barrierefreiheit hier integriert werden.
Bei den Methoden, die beim Testen angewendet werden können, ist zum Beispiel eine Orientierung an der ISO/TR 16982 aus dem Bereich der Gebrauchstauglichkeit möglich. Grundsätzlich ist eine Kombination aus verschiedenen Methoden, beispielsweise automatischen Tests, Tests durch Experten („Expertentests“) und Tests durch Anwender („Anwender-Tests“) empfehlenswert. Eine Beschränkung auf automatische Tests wäre nicht ausreichend, da die Überprüfung der Einhaltung der Kriterien der Barrierefreiheit an vielen Stellen eine Art der Beurteilung erfordert, die bisher nicht automatisierbar ist.
Hinweise zum Testen mobiler Anwendungen sind im jeweiligen Abschnitt unter Tipps für die App-Entwicklung bereits erwähnt worden.
Hinweise zum Überprüfen der Barrierefreiheit von Software:
-
Methoden und Prozesse:
-
Testen mit der Sprachausgabe:
- Tool - Lesen mit den Ohren - Testen mit dem Screenreader
- How to use NVDA and Firefox to test your web pages for accessibility
-
Prüfanleitungen für Expertentests:
- Wiki aus dem Projekt „BIT inklusiv“:
Prüfverfahren Anwendungssoftware - BIK BITV-Test zur Prüfung der Barrierefreiheit von Websites und Webanwendungen:
BITV-Test für webbasierte Softwareoberflächen - Prüfverfahren für Videokonferenztool aus dem Teilhabe 4.0-Projekt:
Testverfahren Videokonferenz-Tools – Schritt für Schritt
- Wiki aus dem Projekt „BIT inklusiv“:
Das Ergebnis eines aktuellen Tests der Barrierefreiheit der eingesetzten Web-Anwendung oder mobilen App sollte in Form einer Barrierefreiheitserklärung für die Nutzenden verfügbar sein. Auch wenn man als Anbieter aktuell noch nicht zur Barrierefreiheit verpflichtet ist, enthält diese für Menschen mit Behinderungen wichtige Informationen zur Barrierefreiheit des Produkts. Die Verpflichtung eine Erklärung bereitzustellen beziehungsweise bereitstellen zu können ergibt sich für Behörden aus der EU-Webrichtlinie beziehungsweise der Barrierefreien-Informationstechnik-Verordnung (BITV 2.0) und für private Anbieter aus dem European Accessibility Act (EAA) beziehungsweise dem Barrierefreiheitsstärkungsgesetz.