Was gibt es Neues in den WCAG 2.2 Richtlinien für barrierefreie Webinhalte

Warum sollte man sich also darüber Gedanken machen? Die WCAG 2.2 sind rückwirkend mit den vorherigen Versionen kompatibel. Es ist also vollkommen sicher und empfehlenswert, die neuen Richtlinien nach deren Veröffentlichung bei der Entwicklung und im Test zu befolgen, obwohl diese die Gesetzgebung noch nicht voraussetzt. Vor allem bei der Entwicklung von neuen Diensten lohnt es sich, die neuen Kriterien zu beachten.

Ziele

Ziel bei der Entwicklung der Version 2.2 der WCAG-Richtlinien war es, die Richtlinien für barrierefreie Webinhalte besonders für drei wichtige Gruppen zu verbessern:

• Benutzer, die kognitive oder lernbezogene Einschränkungen haben,
• sehbehinderte Personen und
• Menschen mit Einschränkungen, die mobile Endgeräte benutzen.

Neue Kriterien

Obwohl die neuen Richtlinien fast fertig sind, muss man daran denken, dass vor der endgültigen Veröffentlichung noch daran gefeilt oder etwas weggelassen werden kann. Aus diesem Grund können die hier vorgestellten Übersetzungen der Kriterien von der endgültigen offiziellen Übersetzung abweichen.

Bei den WCAG 2.2 gibt es im Vergleich zu der Version 2.1 neun oder zehn völlig neue Erfolgskriterien. Außerdem wurde das Kriterium 2.4.7 Sichtbare Fokussierung, das zuvor als AA eingestuft wurde, nun zu einem Kriterium der A-Stufe. Dies ist für zahlreiche Benutzer/innen von Tastaturen oder Tastaturschnittstellen eine ausgezeichnete Nachricht.

Verschärfung für die Stile der sichtbaren Fokussierung

Eine der wichtigsten Änderungen bei den WCAG 2.2 sind die Verschärfungen bei der sichtbaren Fokussierung. Zuvor war es ausreichend, dass der standard Cursor des Browsers nicht versteckt war, und bei der A-Stufe war selbst das nicht gefordert. In die Richtlinien WCAG 2.1 war die Anforderung eines Kontrasts von nicht-textförmigem Inhalt (1.4.11) aufgenommen worden, aber es wurden nur Anforderungen an den Kontrast des fokussierten Elements gegenüber dem Hintergrund gestellt. Die frühere, einfache Anforderung der AA-Stufe an die sichtbare Fokussierung (Kriterium 2.4.7) wurde bei den WCAG 2.2 zu einem Kriterium der A-Stufe. Für die AA- und die AAA-Stufen gibt es neue, präzise Anforderungen dafür, wie sich ein fokussiertes Element unterscheiden sollte.

Das neue Kriterium 2.4.11 der AA-Stufe definiert die Mindestanforderungen für das Aussehen eines fokussierten Elements:

• Der Kontrast eines Elementteils im Verhältnis zu einem nicht fokussierten Element beträgt mindestens 3:1.
• Die Fläche des Bereichs, der sich von seinem Kontrast her abhebt, muss eine der folgenden Eigenschaften haben:
• ein Rand mit einer Breite von 1 Pixel um das nicht fokussierte Element herum
• ein Rechteck mit einer Breite von 4 Pixeln und mit einer Länge, die der kürzesten Seite des Elements entspricht, wenn die Breite des Bereichs mindestens 2 Pixeln beträgt.
• Der Kontrast des sich abhebenden Bereichs muss mindestens im Verhältnis 3:1 zu angrenzenden Farben stehen, oder die Breite des Bereichs muss mindestens 2 Pixeln betragen.
• Das fokussierte Element darf nicht vollständig von anderem Inhalt bedeckt sein.

Wenn die oben genannten Anforderungen zu Beginn eine Überforderung darstellen (zumindest war das bei mir der Fall), dann kann man diese zum Glück mit einigen Beispielen einfacher veranschaulichen. Unten werden Fokussierungsarten vorgestellt, die die Anforderungen erfüllen, wenn der Kontrast vom Rand zum Hintergrund und zum nicht-fokussiertem Element mindestens 3:1 beträgt:

Ein Rand mit einer Breite von einem Pixel rund um das betreffende Element

Eine Linie mit einer Breite von drei Pixeln unter dem betreffenden Element

Ein Rand mit einer Breite von vier Pixeln am linken oder rechten Rand des Elements.

Auf der AAA-Stufe (Kriterium 2.4.12) muss der Kontrast zwischen dem nicht-fokussierten und dem fokussierten Element mindestens 4,5:1 betragen, die Fläche des sich von seinem Kontrast her abhebenden Bereichs muss einen Rand von mindestens 2 Pixeln rund um das Element aufweisen. Das Element darf von keinerlei Teilen der Benutzeroberfläche verdeckt sein.

Obwohl die neuen Mindestanforderungen an den Stil des Cursors kompliziert wirken, muss es nicht schwierig sein, in der Praxis einen guten und barrierefreien Stil zu erstellen. Beim Design sollte ein guter und sichtbarer Cursor angestrebt und nicht versucht werden, die Kriterien nur gerade so zu erfüllen. Bei einem hellen Hintergrund zum Beispiel kann ein einheitlich dunkler Rand mit einer Breite von 2 Pixeln bei der Fokussierung sowohl die Kriterien der AA- als auch die der AAA-Stufe problemlos erfüllen.

Sichtbare Bedienelemente

Dieses neue Kriterium betrifft Fälle, bei denen die Komponenten der Benutzeroberfläche erst dann sichtbar werden, wenn Mauszeiger oder Tastatur darauf positioniert werden. Das neue Kriterium „3.2.7 Sichtbare Bedienelemente“ setzt voraus, dass ausreichend Informationen sichtbar sein müssen, um diese Komponente zu erkennen und zu finden. In der Praxis kann dies beispielsweise Hilfstexte oder Menü-Schaltflächen bedeuten, die über die versteckten Funktionen informieren. In den meisten Fällen ist es jedoch das Einfachste, dieses Kriterium so zu erfüllen, dass gar keine wesentlichen Bedienelemente versteckt werden.

Bei diesem Kriterium ist es zumindest für den Verfasser etwas unklar, was als ausreichende Information zu verstehen ist. Es wird zum Beispiel hinsichtlich von Videoelementen und Inhaltskarussells festgestellt, dass die Existenz der Komponente ausreicht, um auszudrücken, dass sie auch andere Bedienelemente beinhalten kann als jene, die stets sichtbar sind. Es ist also erlaubt, ein Video einzubinden, bei dem ein Teil der Bedienelemente nur sichtbar ist, wenn sich der Fokus auf diesem Element befindet.

Mindestgröße des Objekts

Bei den WCAG gab es auf der AAA-Stufe auch vorher schon die Anforderung an die Mindestgröße. Jetzt gibt es eine dementsprechende, aber leichtere Anforderung auch auf der AA-Stufe. 2.5.8 Die Zielgröße (Minimum) setzt voraus, dass die Größe der Objekte der Benutzeroberfläche mindestens 24 mal 24 Pixel beträgt, außer wenn es zwischen den Objekten mindestens 24 Pixel Abstand gibt, das Objekt zu einem Absatz gehört (wie ein Link) oder, wenn es für die Präsentation des Objekts unerlässlich ist, dass es kleiner ist (zum Beispiel beim Anzeigen von Punkten auf einer Karte).

Denken Sie daran, dass alle Benutzer davon profitieren, wenn diese Anforderung erfüllt wird, vor allem bei mobilen Endgeräten. Die Anforderung der AAA-Stufe an die Größe der Objekte von 44 Pixeln ist eine allgemeine Empfehlung in den Normen für Benutzeroberflächen.

Unnötige Wiederholungen von Eingaben vermeiden

Manchmal werden bei Formularen die gleichen Informationen mehrmals abgefragt. Beispielsweise bei Bestellformularen, bei denen es separate Felder für die Rechnungs- und Lieferadresse gibt, obwohl diese oft identisch sind. Die neue Anforderung „3.3.8 Überflüssige Eingabe“ setzt voraus, dass die Informationen in solchen Fällen entweder schon vorausgefüllt sind, oder so auswählbar sein müssen, dass man sie nicht erneut eingeben muss. Eine Ausnahme bilden bei dieser Anforderung Situationen, bei denen es unerlässlich ist, die Informationen erneut abzufragen, zum Beispiel aus Datenschutzgründen oder, wenn die zuvor erfragten Informationen nicht mehr zutreffen. Die Anforderung betrifft auch nur Eingaben, die während derselben Sitzung getätigt wurden. Es ist also kein längerfristiges Speichern der Informationen notwendig.

Barrierefreie Authentifizierung

Die neue Anforderung zur barrierefreien Authentifizierung (3.3.7 Barrierefreie Authentifizierung) sieht vor, dass eine Authentifizierung auch ohne eine Voraussetzung möglich ist, zum Beispiel, ohne dass man sich an ein Passwort erinnern, oder es von Hand kopieren muss. Zum Erfüllen des Kriteriums reicht es, dass das Anmeldeformular Passwortmanagementfunktionen Dritter oder in Browsern integrierter unterstützt, und das Kopieren und Einfügen von Text nicht separat blockiert wird.

In der Praxis bedarf dieses Kriterium also keiner besonderen Maßnahmen, sofern die zuvor genannten Funktionen nicht aktiv behindert werden.

Diese Anforderung wird aufgrund des aktuellsten Standardentwurfs des Verfassers möglicherweise in zwei verschiedene Kriterien geteilt, bei denen auf der AA-Stufe eine Ausnahme für Verfahren erlaubt sein wird, die auf der Identifizierung von allgemeinen Objekten basieren, vergleichbar mit Google.

Ziehbewegung

Das Kriterium 2.5.7 setzt voraus, dass alle Funktionen, die durch Ziehen erreicht werden, auch durch einfaches Klicken mit dem Mauszeiger ausgeführt werden können. Beispiele:

• Eine Karte, deren Ansicht durch Ziehen verändert werden kann, verfügt auch über Schaltflächen zum Verschieben nach oben, unten, links und rechts.
• Wird der Wert der Bedienelemente durch Ziehen eingestellt, so gibt es in dem Zusammenhang auch ein Textfeld, um den Wert einzutragen.

Einheitliche Hilfefunktion

Das Kriterium 3.2.6 erfordert nicht, dass es auf den Seiten eine Hilfefunktion gibt, aber falls eine solche Funktion vorhanden ist, so muss sie sich auf jeder Seite an einer einheitlichen Stelle befinden. Zu solchen Anweisungen zählen beispielsweise:

• Kontaktdaten
• Kontaktformular
• Zusatzfunktion, häufige gestellte Fragen oder Ähnliches
• vollständig automatisierter Bot.

Die Position kann natürlich je nach Bildschirmgröße oder der Vergrößerung des Bildschirms variieren, aber bei einem gleich großen Bildschirm oder mit der gleichen Vergrößerung sollte die Position der Zusatzfunktion einheitlich sein. Verfügt der Dienst über unterschiedliche Wege, Anweisungen oder Hilfe zu erhalten, reicht es zum Erfüllen des Kriteriums, dass eine davon auf die oben beschriebene Art verfügbar ist. Beispielsweise befindet sich der Link zu den Kontaktdaten immer am gleichen Ort im Hauptmenü auf der Seite.

Bildtext: ein einfacher Weg, das neue Kriterium 3.2.6 zu erfüllen, ist ein Kontaktlink wie auf der Seite von Eficode, der sich immer am gleichen Ort befindet.

Kennzeichnung des Seitenwechsels

Dies mag sich nach einer ganz besonderen Anforderung der Richtlinie für barrierefreien Webinhalt anhören, aber im Grunde betrifft das neue 2.4.13-Kriterium Inhalte, für die es eine entsprechende Druck- oder PDF-Version gibt. Das Kriterium setzt voraus, dass die Benutzer, die Hilfsmittel verwenden, die Stelle, auf die im Inhalt verwiesen wird, zum Beispiel anhand der Seitennummer der Printversion finden können. Eine akzeptable Lösung wäre zum Beispiel eine Liste mit Seitenzahlen am Anfang des Artikels, die mit Anker-Links mit den entsprechenden Stellen im Inhalt verlinkt sind.

Checkliste

• Planen Sie klare Cursor Style.
• Verbergen Sie keine Bedienelemente, oder falls doch, dann hinterlassen Sie einen sichtbaren Hinweis über deren Existenz
• Gestalten Sie die Objekte mindestens in einer Größe von 24 x 24 CSS-Pixeln, oder lassen Sie einen Abstand von mindestens 24 Pixeln
• Zwingen Sie den Benutzer nicht, die gleichen Informationen während einer Sitzung mehrmals einzugeben
• Unterstützen Sie Passwortmanager: Verhindern Sie nicht das Kopieren und Einfügen von Text bei der Authentifizierung
• Lässt sich etwas durch Ziehen bewegen, so sollte das gleiche auch durch einfaches Klicken möglich sein
• Platzieren Sie die Hilfefunktionen auf der Benutzeroberfläche am gleichen Ort
• Existiert der Inhalt als Druckversion, dann unterstützen Sie das Finden der Seitenzahlen im digitalen Inhalt

Umfangreichere Änderungen sind in der Version WCAG 3.0 zu erwarten

Gleichzeitig mit der WCAG 2.2 wird eine umfangreichere Aktualisierung der WCAG-Richtlinie entwickelt, bei der Struktur und Bewertung der Kriterien völlig neu gestaltet werden sollen. Deren Entwicklung wird wahrscheinlich noch Jahre dauern, und die WCAG-2.x-Richtlinien werden vermutlich noch lange zeitgleich mit der neuen Norm existieren.