In meinem jüngsten Artikel „Der nächste große Sprung in der digitalen Barrierefreiheit: Warum die Community für digitale Barrierefreiheit die Norm EN 17161 ‚Design for All‘ begrüßen sollte“ habe ich die Unterschiede zwischen Ausgabestandards und Managementstandards erörtert und insbesondere dargelegt, inwiefern die WCAG (ein Ausgabestandard) Einschränkungen aufweist, die durch die Kombination mit der Norm EN 17161 (einem Managementstandard) ausgeglichen werden können.
In diesem Artikel werde ich mich mit einer weiteren Herausforderung im Zusammenhang mit der Umsetzung der WCAG befassen – nämlich ihrem Konformitätsmodell, das auf einer einzelnen Seite, einem bestimmten Zeitpunkt und dem Prinzip „alles oder nichts“ basiert. Und ich werde erneut die Norm EN 17161 als Lösung vorstellen.
Die unrealistische Konformität mit den WCAG
Die WCAG sind so konzipiert, dass sie auf einzelne Webseiten Anwendung finden, wobei eine einzelne Webseite als „Konformitätseinheit“ gilt. Man kann bei der Konformitätserklärung keine Abschnitte einer Seite ausklammern, ebenso wenig wie man behaupten kann, dass eine gesamte Website den WCAG entspricht. Man kann höchstens sagen, dass jede einzelne Seite einer Website den WCAG entspricht. Genau das verlangen auch die Gesetze zur Barrierefreiheit im Internet an vielen Orten – dass alle Seiten den WCAG (oder einem auf den WCAG aufbauenden Standard) entsprechen.
Für viele Websites ist eine vollständige Einhaltung der WCAG praktisch unmöglich.
Hier geht es nicht um Aufwand, Achtsamkeit oder bessere Sicherheitsvorkehrungen. Tatsache ist, dass sowohl Menschen als auch KI-Systeme Fehler machen und jede größere Website zwangsläufig Fehler enthält. Hinzu kommt, dass viele Websites Inhalte von Drittanbietern enthalten, auf die sie keinen Einfluss haben.
Es stellt sich also die Frage: Wie nah sind Sie an der vollständigen Konformität? Leider helfen uns die WCAG nicht bei der Beantwortung dieser Frage. Die WCAG sehen zwar Konformitätsstufen vor, aber es ist nicht so, dass alle Websites zunächst Stufe A, dann Stufe AA und schließlich Stufe AAA erfüllen. Fehler können auf jeder Stufe auftreten. Sie fallen nicht auf eine niedrigere Stufe zurück, wenn sich die Situation verschlechtert. Sie erfüllen dann einfach nicht die Anforderungen.
Die Anzahl der erfüllten WCAG-Kriterien zu zählen, ist auch nicht viel besser. Die Verteilung der Kriterien ist sehr ungleichmäßig. Aus Sicht der Benutzererfahrung und der Barrierefreiheit kann eine Website, die drei Kriterien nicht erfüllt, in einem hervorragenden oder in einem katastrophalen Zustand sein – je nachdem, um welche drei Kriterien es sich handelt und wie sich diese Mängel auf die Nutzer auswirken.
Das soll übrigens keineswegs bedeuten, dass das Konformitätsmodell der WCAG schlecht ist. Im Gegenteil, ich finde es wirklich gut. Es erfüllt seinen Zweck hervorragend. Es ist jedoch nicht in der Lage, die Herausforderungen zu bewältigen, denen moderne Websites gegenüberstehen, und Bemühungen, diese Situation zu verbessern, waren bislang wenig erfolgreich. Die WCAG sind ein fantastisches Werkzeug für die Barrierefreiheit einzelner Seiten. Wenn es jedoch darum geht, Millionen dynamischer Seiten zu verwalten, ist ein Integriertes Managementsystem (IMS) die weitaus bessere Wahl.
EN 17161 „Design for All“ ist eine Managementnorm, die beschreibt, wie Organisationen barrierefreie Produkte, Waren und Dienstleistungen entwickeln und bereitstellen können. Sie zielt darauf ab, Organisationen dabei zu unterstützen, Prozesse zu etablieren, die sicherstellen, dass die Bedürfnisse der Nutzer während der gesamten Planung, Konzeption, Entwicklung und Bereitstellung berücksichtigt werden. Sie ist als Ergänzung zur ISO 9001 (dem wohl bekanntesten integrierten Managementsystem) konzipiert, die sogenannte „Problemregister“ vorschreibt.
Problemregister
Um die oben beschriebenen Herausforderungen zu bewältigen, müssen Ziele für die Barrierefreiheit festgelegt werden. Sie müssen ermitteln, wo in Ihrer Organisation Schwachstellen bestehen, damit Sie Ihre Bemühungen auf diese Bereiche konzentrieren können. Anschließend müssen Sie die entsprechenden Maßnahmen umsetzen und Leistungsindikatoren einführen, um den Erfolg zu messen. Dies wird als „Plan-Do-Check-Act“-Zyklus bezeichnet, der in vielen Managementstandards zum Einsatz kommt.
Ein Problemregister ist eine Liste identifizierter Barrierefreiheitsprobleme, die Informationen darüber enthält, wodurch die einzelnen Probleme verursacht wurden und welche Maßnahmen zu ihrer Behebung ergriffen werden. Viele Organisationen verfügen bereits über eine Liste solcher Probleme – ein Problemregister geht noch einen Schritt weiter.
Ihr Problemregister sollte einen system- oder organisationsweiten Überblick über die Barrierefreiheit bieten. Es sollte Probleme aus der automatisierten Überwachung und aus Expertenprüfungen sowie Kundenfeedback, Ergebnisse zur Benutzerfreundlichkeit und Probleme aus dem Kundensupport umfassen. Darauf aufbauend sollte eine Ursachenanalyse (RCA) erfolgen, die Einblicke in häufige Ursachen liefert und Ihnen hilft zu verstehen, was Probleme verursacht und an welchen Stellen Ihre Teststrategie möglicherweise zu langsam ist, um diese zu erkennen. Das Problemregister kann auch Korrektur- und Vorbeugungsmaßnahmen (CAPA) enthalten, sodass Sie nachverfolgen können, wie erfolgreich Sie bei der Behebung von Problemen innerhalb des erwarteten Zeitrahmens sind.
Ziele zur Barrierefreiheit
Sobald ein Register für Barrierefreiheitsprobleme eingerichtet ist, können Organisationen entsprechende Ziele festlegen. Dazu gehört die Definition der Auswirkungen; so kann eine Organisation beispielsweise zwischen Hindernissen und Beeinträchtigungen unterscheiden und Kernfunktionen von sekundären Funktionen trennen.
Sie können sich beispielsweise folgende Ziele setzen:
- Beheben Sie Probleme, die den Betrieb der Kernsysteme beeinträchtigen, innerhalb von zwei Wochen nach ihrer Feststellung.
- Andere Probleme im Zusammenhang mit der Barrierefreiheit sind innerhalb von drei Monaten nach ihrer Feststellung zu beheben.
- Stellen Sie sicher, dass 90 % der erkannten Probleme weniger als sechs Monate alt sind.
- Die Zahl der neu festgestellten Probleme soll alle sechs Monate um 20 % gesenkt werden.
Sie sollten sich Ziele setzen, die eine Spannung zwischen der Erstellung von Inhalten, der Erkennung von Problemen und deren Behebung erzeugen. Um Probleme schnell zu erkennen, müssen Sie regelmäßig Tests mit verschiedenen Methoden durchführen (automatisiert, manuell, Usability). Bei regelmäßigen Tests lässt sich eine Verringerung der Anzahl erkannter Probleme nur durch eine Verbesserung des Prozesses zur Erstellung von Inhalten erreichen. Regelmäßige Tests füllen zudem die Pipeline für die Behebung von Problemen, was erfordert, dass ausreichende Ressourcen bereitgestellt werden, um die Probleme rechtzeitig zu beheben.
Um diese Ziele kontinuierlich zu erreichen, muss man herausfinden, welche Teile des Prozesses die größten Schwachstellen aufweisen, und Wege finden, diese zu verbessern. Nur so kann man auf Kurs bleiben, um diese Ziele zu erreichen.
Verabschiedung der Norm EN 17161
Ich stelle mir die Beziehung zwischen den WCAG und der Norm EN 17161 so vor, dass die WCAG den Horizont darstellen. Sie geben die Richtung vor, in die man sich bewegt, und auch wenn man den Horizont nicht wirklich „erreichen“ kann, ist er doch das Ziel, auf das man zusteuert. Die EN 17161 ist die Straße, auf der man fährt, und sie verfügt über alle Markierungen, Leitlinien und Schilder, die einen auf Kurs halten und verhindern, dass man in den Gegenverkehr oder in den Graben gerät.
Die Norm EN 17161 wurde erstmals im Jahr 2019 veröffentlicht; eine neue Fassung wird im Laufe dieses Jahres erwartet. Bislang hat sie bei weitem nicht das Maß an Akzeptanz erreicht, das die WCAG in ihren ersten fünf Jahren verzeichnen konnte. Dafür gibt es einige nachvollziehbare Gründe, wobei der enorme Erfolg der WCAG der offensichtlichste ist – da die WCAG bereits etabliert sind, haben sich im Bereich der digitalen Barrierefreiheit nur wenige ernsthaft mit anderen Optionen auseinandergesetzt. Erschwerend kommt hinzu, dass die EN 17161 (wie viele CEN/CENELEC-Normen) kein freier und offener Standard ist. Dennoch glaube ich, dass sie uns helfen kann, viele der größten Probleme im Bereich der digitalen Barrierefreiheit anzugehen.
In meinem letzten Beitrag habe ich erwähnt, dass sich das W3C ebenfalls auf die Problemlösung konzentriert und hofft, viele der bestehenden Lücken zu schließen, auf die ich im Zusammenhang mit WCAG 3.0 hingewiesen habe. Vielleicht fragen Sie sich nun: Sollten wir nicht einfach auf WCAG 3.0 warten?
Das Warten auf WCAG 3.0
WCAG 3.0 wird eine vollständige Neufassung von WCAG 2.2 sein und zahlreiche neue Anforderungen enthalten. Es wird weiterhin für das Web konzipiert sein, könnte jedoch Bestimmungen enthalten, die auch bei Nicht-Web-Technologien angewendet werden können. Das W3C strebt zudem die Entwicklung eines Konformitätsmodells an, das besser auf das dynamische Web von heute zugeschnitten ist. Es könnte beispielsweise ein Bewertungsmodell umfassen und Anforderungen an Autorentools für Drittanbieter von Inhalten enthalten.
Die Realität sieht jedoch so aus, dass die Fertigstellung der WCAG 3.0 noch mindestens vier Jahre auf sich warten lässt. Dies ist einer von vielen Gründen, warum ich der Meinung bin, dass wir die Norm EN 17161 schon heute brauchen.
Zwar wurden bereits große Fortschritte erzielt, doch die am wenigsten klar definierten Teile der WCAG 3.0 sind gerade diejenigen, die sich mit den schwierigsten Themen befassen – was nicht weiter verwunderlich ist. Wie ich bereits zuvor erläutert habe, sind die WCAG – als Ausgabestandard – für die Behandlung dieser Art von Problemen einfach nicht gut geeignet.
Umsetzung der Norm EN 17161
Glücklicherweise muss WCAG 3.0 nicht jedes Problem im Bereich der digitalen Barrierefreiheit lösen. Die EU hat hervorragende Arbeit geleistet und ihre Standards auf der Grundlage von WCAG entwickelt. EN 301 549 (die derzeit auf WCAG 2.1 verweist, wobei die Übernahme von WCAG 2.2 für diesen Herbst erwartet wird) nutzt diese für das Web und erweitert sie für Dokumente, Apps, Kiosksysteme und mehr. Mit EN 17161 verfügt die EU über eine Norm, die Barrierefreiheit über digitale und bauliche Vorschriften hinaus ausweitet, um organisatorische Hindernisse zu beseitigen.
Meiner Meinung nach besteht die beste Möglichkeit für das W3C, eine robuste WCAG 3.0 zu entwickeln, die all diesen Herausforderungen gewachsen ist, darin, sich auf die Norm EN 17161 zu stützen und diese zu übernehmen. Die Anforderungen dieser Norm sollten nicht doppelt geregelt werden oder ihr widersprechen, und ihre Übernahme sollte ein einfacher, selbstverständlicher Bestandteil der Einführung von WCAG 3.0 sein.
Ein weiterer Grund, die Norm EN 17161 schon jetzt umzusetzen, ist, dass sie bereits in das Europäische Gesetz zur Barrierefreiheit integriert wird. Unternehmen, die in Europa tätig sind, benötigen die Norm EN 17161 möglicherweise bereits jetzt, um einige der darin festgelegten Anforderungen zu erfüllen.
Erfüllung der EAA-Anforderungen gemäß EN 17161 „Design for All“
Das Europäische Gesetz zur Barrierefreiheit (EAA) schreibt vor, dass digitale Produkte und Dienste barrierefrei sein müssen. Ein weit verbreiteter Irrtum ist, dass dies bedeute, dass das EAA die Einhaltung der WCAG vorschreibe. Die Realität ist jedoch etwas komplizierter.
Die Norm EN 301 549, die EU-Norm für digitale Barrierefreiheit, berücksichtigt zwar die WCAG. Die EAA stellt jedoch noch eine ganze Reihe weiterer Anforderungen, für die derzeit andere Normen erarbeitet oder aktualisiert werden. Die nächste Version der Norm EN 17161 konzentriert sich, wie zu erwarten, auf die Einhaltung der Prozessanforderungen der EAA.
Und ja, Sie haben richtig gelesen. Die EAA enthält Prozessanforderungen! Bei der Barrierefreiheit im Sinne der EAA geht es nicht nur um digital barrierefreie Inhalte. Es gibt auch Anforderungen in Bezug auf Beschaffung, Support, Barrierefreiheitserklärungen und vieles mehr. Hier kommt die Norm EN 17161 ins Spiel.
Die Norm EN 17161 wird derzeit im Hinblick auf ihre Anerkennung als harmonisierte EU-Norm geprüft. Sollte sie anerkannt werden, wird die EN 17161 zur anerkannten Norm für die Erfüllung dieser EAA-Prozessanforderungen. Auch wenn die EAA die EN 17161 nicht zwingend vorschreibt, ist ihre frühzeitige Übernahme bereits jetzt der beste Weg, um einige der EAA-Anforderungen zu erfüllen.
Nächste Schritte
Wenn Sie in der Lage sind, die Einführung dieser Norm in Ihrem Unternehmen voranzutreiben, würde ich Ihnen dringend empfehlen, sich bereits jetzt mit der EN 17161 zu befassen. Konzentrieren Sie sich zu Beginn vor allem darauf, die Führungsebene für das Vorhaben zu gewinnen. Falls Ihr Unternehmen die ISO 9001 für Qualitätsmanagement, die ISO 27001 für Informationssicherheit oder ähnliche Normen anwendet, können Sie sich auch an die Verantwortlichen dieser Programme wenden. Wenn Sie im Beschaffungswesen tätig sind, können Sie auch in Erwägung ziehen, von Organisationen den Nachweis der Umsetzung der EN 17161 zu verlangen (zusätzlich zur Forderung nach einem Audit gemäß EN 301 549). Und wenn Sie in den USA ansässig sind und in einen ADA-Rechtsstreit verwickelt sind, könnten Sie die Umsetzung der EN 17161 als Teil des Vergleichs in Betracht ziehen.
Kombination von EN 17161 und WCAG
Hier und in meinem vorherigen Artikel zu diesem Thema habe ich mich für zwei Standards anstelle von einem ausgesprochen. Anhand der WCAG lässt sich feststellen, ob Ihre Inhalte derzeit barrierefrei sind. Die Norm EN 17161 kann Ihnen dabei helfen, eine Organisation aufzubauen, die diese Barrierefreiheit aufrechterhält – und gleichzeitig die Bedürfnisse von Menschen mit Behinderungen berücksichtigt, die von den WCAG nicht abgedeckt werden. Keine der beiden Normen erfüllt die Aufgabe allein, aber zusammen ermöglichen sie es Ihnen, die gesamte Komplexität der digitalen Barrierefreiheit wirklich zu bewältigen. Die Kombination von EN 17161 und WCAG ist ein großer Schritt nach vorne gegenüber dem aktuellen Stand. Alles, was wir brauchen, ist bereits vorhanden; wir müssen es nur nutzen.
