EN 301 549 V4.1.0: WCAG 2.2 kommt in Europa an – und PDF/UA bekommt seinen Platz

WCAG 2.2 kommt mit fast drei Jahren Verspätung in der EN 301 549 an

Die Web Content Accessibility Guidelines 2.2 wurden bereits am 5. Oktober 2023 vom World Wide Web Consortium (W3C) als Webstandard veröffentlicht. Fast drei Jahre später finden sie nun Eingang in die EN 301 549. Was zunächst nach einer ungewöhnlich langen Verzögerung klingt, hat seinen Grund, denn aus einem W3C-Standard wird halt nicht einfach automatisch eine europäische Norm. 

Die EN 301 549 durchläuft, wie jede andere Norm auch, ein eigenes europäisches Normungsverfahren. Entwürfe werden in den zuständigen Arbeitsgruppen erarbeitet und abgestimmt. Bei europäischen Normen sind anschließend die nationalen Normungsorganisationen beziehungsweise – bei Normen aufgrund eines Standardisierungsauftrags der EU – die nationalen Normungsstellen beteiligt. Je nach Verfahren gehören dazu nationale Konsultationen, die Behandlung eingegangener Kommentare und eine gewichtete nationale Abstimmung. Erst nach erfolgreichem Abschluss dieses Verfahrens kann ETSI (European Telecommunications Standards Institute) die neue EN veröffentlichen. Und selbst dann ist noch ein weiterer Schritt erforderlich, wenn eine Norm als harmonisierte Norm eine Konformitätsvermutung im europäischen Recht auslösen soll: Die Europäische Kommission muss die Fundstelle im Amtsblatt der Europäischen Union veröffentlichen.

Die Verzögerung zeigt damit auch einen grundsätzlichen Unterschied: Technische Standards entwickeln sich schneller als der europäische Normungs- und Rechtsrahmen, in den sie anschließend eingebettet werden müssen. Das war schon immer so und wird auch so bleiben.

WCAG 2.2 erweitert WCAG 2.1 

Bei der Aufregung um die aktualisierte EN 301 549 und die WCAG 2.2 könnte man den Eindruck gewinnen, das man jetzt ein vollständig neues Regelwerk berücksichtigen müsste. Das ist nicht der Fall. WCAG 2.2 baut auf WCAG 2.1 auf und ist rückwärtskompatibel. Die bisherigen Erfolgskriterien bleiben grundsätzlich erhalten – es kommen nur neue Anforderungen dazu. Abgesehen vom Erfolgskriterium 4.1.1 Parsing, das in WCAG 2.2 endlich entfällt. Für die Praxis bedeutet der Wechsel auf WCAG 2.2 deshalb vor allem: der vorhandene Prüfkatalog wird erweitert. Für Webseiten sind insbesondere sechs neue Erfolgskriterien der Konformitätsstufen A und AA relevant, die ich nachfolgend kurz vorstelle, bzw. erläutere:

2.4.11 Focus Not Obscured (Minimum) (AA) bedeutet: ein Element, das den Tastaturfokus erhält, darf nicht vollständig durch andere Inhalte wie sticky Header, Cookie-Banner oder eingeblendete Dialogbereiche verdeckt werden. Eine wichtige Neuerung, weil das tatsächlich ein häufig auftretendes Problem darstellt.

2.5.7 Dragging Movements (AA): Funktionen, die eine Ziehbewegung voraussetzen, müssen grundsätzlich auch ohne Drag-and-Drop beziehungsweise eine vergleichbare Ziehbewegung bedienbar sein. Interessant: auch ein horizontaler Swipe auf einem Touchscreen fällt grundsätzlich unter WCAG 2.2, Erfolgskriterium 2.5.7 „Dragging Movements“, wenn damit eine Funktion ausgelöst wird – etwa das Wechseln zum nächsten Element eines Karussells.

2.5.8 Target Size (Minimum) (AA): Interaktive Bedienelemente müssen grundsätzlich eine ausreichend große oder ausreichend weit von anderen Zielen entfernte anklickbare Fläche besitzen; das Erfolgskriterium sieht hierfür eine Mindestgröße von 24 × 24 CSS-Pixeln beziehungsweise entsprechende Ausnahmen vor.

3.2.6 Consistent Help (A): Werden wiederkehrende Hilfefunktionen wie Kontaktmöglichkeiten, Chat oder FAQ auf mehreren Seiten angeboten, sollen sie innerhalb eines Angebots in einer konsistenten relativen Reihenfolge erscheinen. Diese Anforderung ist aus meiner Erfahrung vergleichsweise spezielles und in normalen Audits ein eher selten verletztes Kriterium.

3.3.7 Redundant Entry (A): Informationen, die Nutzende innerhalb eines Prozesses bereits eingegeben haben, sollen nicht ohne Not erneut eingegeben werden müssen, sondern beispielsweise automatisch übernommen oder auswählbar gemacht werden. Auch das ist ein eher situatives Kriterium, weil mehrere Voraussetzungen zusammenkommen müssen, bevor es überhaupt anwendbar wird. Im Kontext von E-Commerce wäre „Lieferadresse entspricht Rechnungsadresse“ ein typisches Beispiel. 

3.3.8 Accessible Authentication (Minimum) (AA): Bei der Authentifizierung dürfen grundsätzlich keine kognitiven Funktionstests wie das Erinnern eines Passworts oder das Lösen einer Aufgabe verlangt werden, sofern keine zugängliche Alternative oder unterstützende Möglichkeit wie Passwortmanager oder Copy-and-paste zur Verfügung steht.

Die Änderungen adressieren zum Teil alltägliche, zum Teil aber aus meiner Erfahrung auch eher spezielle Nutzungssituationen: von verdecktem Tastaturfokus, zu kleinen Touch-Zielen und unnötigen motorischen Anforderungen bis hin zu wiederholten Eingaben in Prozessen, inkonsistenten Hilfefunktionen oder kognitiven Hürden bei der Anmeldung.

EN 301 549 und European Accessibility Act rücken zusammen

Die EN 301 549 ist bereits eng mit der Web Accessibility Directive (EU) 2016/2102 verbunden. Diese regelt die Barrierefreiheit von Websites und mobilen Anwendungen öffentlicher Stellen (Öffentliche Hand) . Mit V4.1.0 kommt nun ausdrücklich der European Accessibility Act hinzu. Das ist deshalb relevant, weil der EAA über seine Umsetzung in nationales Recht – in Deutschland insbesondere durch das Barrierefreiheitsstärkungsgesetz – zahlreiche Produkte und Dienstleistungen des privaten Sektors betrifft. Der neue Annex ZB stellt eine Zuordnung zwischen den Anforderungen der EN 301 549 und den Barrierefreiheitsanforderungen des EAA her. Vereinfacht gesagt beantwortet er die Frage: Welche Anforderungen der Norm können herangezogen werden, um bestimmte gesetzliche Anforderungen des EAA technisch umzusetzen? Die EN 301 549 wird damit noch stärker zur technischen Brücke zwischen abstrakten gesetzlichen Anforderungen und ihrer konkreten Umsetzung.

PDF/UA: wichtiger Standard, aber nicht der Maßstab der EN 301 549

Die EN 301 549 gilt bekanntlich nicht nur für Websites und Apps, sondern auch für Dokumente. Besonders interessant: Kapitel 10 der EN 301 549 wurde ebenfalls auf WCAG 2.2 aktualisiert. Gleichzeitig erwähnt die Norm nun ausdrücklich sowohl PDF/UA-1 als auch den 2024 veröffentlichten Standard PDF/UA-2. In einer informativen Anmerkung heißt es dazu:

„ISO 14289-1:2014 […] and ISO 14289-2:2024 […] are the technical standards for accessible PDFs and would be useful in meeting EN 301 549.“

Der zweite Teil des Satzes ist entscheidend: would be useful in meeting EN 301 549. PDF/UA wird damit ausdrücklich als technischer Standard für barrierefreie PDF-Dokumente anerkannt. Die EN 301 549 macht PDF/UA-Konformität aber nicht zur Voraussetzung für ihre eigene Konformität. Die verbindlichen Anforderungen für nicht-webbasierte Dokumente stehen also weiterhin in Kapitel 10 der EN 301 549 und der PDF/UA Standard kann ein sehr guter technischer Weg sein, diese Anforderungen bei PDF-Dokumenten umzusetzen – es ist aber nicht der einzig vorgeschriebene Weg.

Das hat eine wichtige Konsequenz: Ein PDF kann die auf das Dokument anwendbaren Anforderungen aus Kapitel 10 der EN 301 549 erfüllen, ohne vollständig PDF/UA-konform zu sein. Umgekehrt beweist PDF/UA-Konformität allein noch nicht, dass sämtliche anwendbaren Anforderungen der EN 301 549 erfüllt sind. PDF/UA-Konformität und EN-301-549-Konformität sind deshalb zwei unterschiedliche Aussagen.

PAC bestanden ist nicht gleich barrierefrei

Diese Unterscheidung ist auch für die zunehmende Automatisierung von Barrierefreiheitsprüfungen relevant. Gerade bei PDF-Dokumenten wird Barrierefreiheit in der Praxis häufig stark mit PDF/UA und den Ergebnissen entsprechender Prüfwerkzeuge verbunden. Das ist zwar nachvollziehbar, denn der PDF/UA Standard definiert zahlreiche technisch überprüfbare Eigenschaften eines zugänglichen PDF-Dokuments und Werkzeuge können einen Teil dieser Anforderungen halt sehr effizient kontrollieren, aber problematisch wird es dort, wo aus einem erfolgreichen automatisierten Prüfergebnis die Aussage „Dieses PDF ist barrierefrei“ abgeleitet wird.

Schon PDF/UA selbst enthält Anforderungen, deren tatsächliche Erfüllung nicht allein maschinell beurteilt werden kann. Ob beispielsweise ein Alternativtext den Inhalt einer Abbildung angemessen vermittelt, lässt sich nicht dadurch feststellen, dass ein Prüfprogramm lediglich die Existenz eines Alt-Attributs erkennt. 

Das wirft aus meiner Sicht auch Fragen für automatisierte oder stark automatisierte Prüfverfahren im Rahmen der Überwachung digitaler Barrierefreiheit auf. Die europäische Durchführungsentscheidung zum Monitoring verlangt ausdrücklich eine technologieneutrale Methodik. Sie schreibt keine bestimmten Tests oder Prüfwerkzeuge vor. Bei der eingehenden Überwachung muss geprüft werden, ob alle Anforderungen der maßgeblichen Standards erfüllt sind. Die Methodik ist ausdrücklich unabhängig von bestimmten Accessibility-Tools. Automatisierte Tests sind zwar ein wertvoller Bestandteil einer Prüfung, sie sind aber nicht mit der Prüfung selbst gleichzusetzen.

Gerade die neue Formulierung der EN 301 549 liefert deshalb aus meiner Sicht zusätzlichen Stoff für die Diskussion, wie aussagekräftig Monitoringverfahren sind, wenn sie sich bei PDF-Dokumenten weitgehend auf automatisierbare PDF/UA-Kriterien konzentrieren.

Auch WCAG 2.2 deckt nicht alle Barrieren ab

Bei all der Bedeutung von WCAG und EN 301 549 sollte ein weiterer Punkt nicht aus dem Blick geraten: Normkonformität (und Konformität) und tatsächliche Zugänglichkeit sind nicht zwangsläufig dasselbe. Das W3C weist darauf in den WCAG 2.2 selbst ausdrücklich hin:

„Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability.“

Die WCAG decken also bewusst nicht jede denkbare Nutzeranforderung und jede mögliche Barriere ab. Auch die deutsche BITV 2.0 trägt diesem Umstand Rechnung. § 3 Absatz 3 bestimmt, dass Nutzeranforderungen oder Teile von Angeboten, Diensten oder Anwendungen, die nicht von harmonisierten Normen abgedeckt sind, nach dem Stand der Technik barrierefrei zu gestalten sind. Das ist ein wichtiger Punkt, der meist übersehen oder vergessen wird: Eine Norm definiert prüfbare Anforderungen und schafft einen gemeinsamen Maßstab. Sie kann aber nicht jede Nutzungssituation und jede individuelle Barriere vollständig abbilden.

Was sich jetzt in der Prüfpraxis ändern sollte

Wer bislang auf Grundlage von WCAG 2.1 beziehungsweise der bisherigen EN 301 549 Barrierefreiheit umsetzt oder prüft, sollte seine Prüfpraxis ab jetzt auf WCAG 2.2 erweitern.

Bei PDF-Dokumenten lohnt sich eine grundsätzlichere Betrachtung. Wer Barrierefreiheit bislang hauptsächlich mit PDF/UA-Konformität oder einem bestandenen automatisierten PDF-Test gleichgesetzt hat, sollte den Blick stärker auf die tatsächlich maßgeblichen Anforderungen richten. Für Non-Web-Dokumente sind das im Kontext der EN 301 549 die anwendbaren Anforderungen aus Kapitel 10.

PDF/UA bleibt dabei ein wichtiger und sinnvoller technischer Standard. Die neue EN 301 549 macht aber aus meiner Sicht ganz deutlich, wie das Verhältnis zu verstehen ist: PDF/UA ist ein Weg zu einem barrierefreien PDF – aber nicht der alleinige Maßstab für Barrierefreiheit nach EN 301 549 (interessant ist in diesem Kontext vielleicht auch der Artikel: “Barrierefreie PDF aus Word – ohne Zusatzsoftware kein zugängliches PDF?”. 

Die EN 301 549 V4.1.0 ist mehr als das lange erwartete Update auf WCAG 2.2. Sie schafft Klarheit, auf welcher Grundlage Barrierefreiheit im Kontext des European Accessibility Acts herzustellen ist und die Norm bietet neues Futter, um darüber zu diskutieren, was wir eigentlich messen, wenn wir Barrierefreiheit prüfen – Normkonformität, technische PDF-Konformität oder die tatsächliche Zugänglichkeit für Menschen mit Behinderungen.