Mit den WCAG arbeiten: Understanding, Techniken, Fehler

„1.4.3 nicht erfüllt.“ So steht es im Prüfbericht, und dann? Das Erfolgskriterium verlangt für Text ein Kontrastverhältnis von mindestens 4,5:1 und nennt drei Ausnahmen. Was es nicht verrät: warum ausgerechnet dieser Wert, was die Ausnahmen im Einzelfall genau heißen, wie man den Wert erreicht und woran man in der Praxis typischerweise scheitert. Dafür gibt es drei Begleitdokumente der WCAG, die weniger bekannt sind, als sie es verdienen: die Understanding-Dokumente, die Techniken und die typischen Fehler (englisch Failures).

Nachdem es in den ersten Teilen um die vier Grundprinzipien, die 13 WCAG-Richtlinien und zuletzt um die Erfolgskriterien und Konformitätsstufen ging, schauen wir jetzt, wie man mit den Kriterien arbeitet. Auch dieser Teil kommt ohne Code aus und richtet sich an alle, die Inhalte erstellen, planen oder freigeben. Wir bleiben beim Kontrast, und ich löse nebenbei ein Versprechen aus dem letzten Teil ein: wie sich das Kriterium 3.3.4 zur Fehlervermeidung erfüllen lässt.

Von der Anforderung zur Umsetzung

Direkt beim Kriterium 1.4.3 Kontrast (Minimum) (öffnet in neuem Tab) stehen in den WCAG zwei Links, die leicht übersehen werden: Understanding Contrast (Minimum) (öffnet in neuem Tab) und How to Meet Contrast (Minimum) (öffnet in neuem Tab). Beide gehören zum selben Kriterium, helfen aber in unterschiedlichen Situationen. Ist der Fall klar und man will nur kurz nachsehen, welche Technik passt oder woran es typischerweise scheitert, geht das am schnellsten über „How to Meet“, die Schnellreferenz: dasselbe Kriterium, dazu Techniken und typische Fehler direkt verlinkt. Ist der Fall unklar oder strittig, etwa bei einer Ausnahme oder weil nicht eindeutig ist, ob das Kriterium greift, lohnt der Weg ins Understanding-Dokument. Dort steht, wie das Kriterium gemeint ist.

Was sich hinter den Begriffen verbirgt, schauen wir der Reihe nach an. Vorab der Überblick:

Understanding-Dokumente: das Warum hinter dem Kriterium

Wo die WCAG als Standard knapp und technikneutral bleiben, setzen die Understanding-Dokumente an. Es gibt sie für jede Richtlinie und jedes Erfolgskriterium. Sie sind informativ, gehören also nicht zum verbindlichen Teil, erklären aber, wie ein Kriterium gemeint ist. Maßgeblich bleibt der Wortlaut des Kriteriums. Das W3C sagt selbst, dass die Dokumente keine Einstiegslektüre sind, sondern für alle, die die WCAG gründlicher verstehen wollen. Sie sind auf Englisch geschrieben und teils sehr ausführlich. Umso hilfreicher ist es zu wissen, was wo steht.

Das Dokument zu einer Richtlinie ist kurz: der Wortlaut, die Absicht dahinter und die Liste der zugehörigen Kriterien mit Links, etwa bei 1.4 Unterscheidbar (öffnet in neuem Tab). Das Dokument zu einem Erfolgskriterium ist deutlich umfangreicher. Am Beispiel 1.4.3 Kontrast (Minimum) (öffnet in neuem Tab) hat es neun Abschnitte, in dieser Reihenfolge:

1. Kurzfassung (In Brief): Ziel, was zu tun ist und warum es wichtig ist, in drei Zeilen. Bei 1.4.3 sinngemäß: Text soll von mehr Menschen gesehen werden, dafür braucht es ausreichend Kontrast zum Hintergrund, denn manche Menschen können blassen Text nicht lesen.
2. Das Erfolgskriterium im Wortlaut, damit man nicht zwischen zwei Seiten springen muss.
3. Intent (Absicht): der Kern. Hier steht, was das Kriterium erreichen soll, und die Antworten auf die Fragen aus der Praxis. Dazu gleich mehr.
4. Vorteile (Benefits): wer profitiert und wie. Bei 1.4.3 sind das Menschen mit Sehbehinderung, besonders wenn zusätzlich eine Farbfehlsichtigkeit besteht.
5. Verwandte Quellen (Related Resources): Hilfsmittel wie Kontrastprüfer und Studien dazu.
6. Techniken: ausreichende und ergänzende Techniken sowie typische Fehler, jeweils verlinkt. Dazu unten mehr.
7. Begriffe (Key Terms): Definitionen der Fachwörter aus dem Kriterium, etwa Kontrastverhältnis oder großer Text. Ein Mini-Glossar pro Kriterium.
8. Referenzen (References): die Quellen hinter den Zahlen.
9. Testregeln (Test Rules): Prüfregeln für Audits und Werkzeuge, ebenfalls unten.

Bemerkenswert finde ich die Reihenfolge: Die Kurzfassung steht noch vor dem Wortlaut des Kriteriums. Für mich zeigt das, dass es hier mehr ums Anwenden geht als um den Wortlaut. Und weil viel drinsteht, was man nicht braucht, kann man nach den drei Zeilen aufhören, wenn es schnell gehen soll.

Nicht jedes Dokument hat alle neun Abschnitte. Bei 1.4.3 stecken die Beispiele als Abbildungen im Intent. Das Dokument zu 3.3.4 hat dafür einen eigenen Abschnitt „Examples“ (Beispiele), aber keine Testregeln.

Was im Intent steckt

Hier wird aus dem Standard ein Verständnis. Bei 1.4.3 klärt der Intent zum Beispiel, warum es 4,5:1 sind: Der Wert ist nicht gegriffen, sondern gleicht aus, dass Kontraste bei nachlassender Sehschärfe, im Alter oder bei Farbfehlsichtigkeit schwerer zu erkennen sind. Das Dokument rechnet das sogar vor und nennt die Quellen. Bei großem Text reicht weniger, weil größere Schrift mit dickeren Strichen sich leichter lesen lässt. Er sagt auch, was alles als Text zählt: Platzhalter in Formularfeldern, Text, der erst bei Hover oder Fokus erscheint, und Text in Bildern, etwa im Sharepic. Markenfarben sind keine Ausnahme, nur Logos sind es. Und er erklärt, was nicht unter das Kriterium fällt, etwa die Beschriftung eines deaktivierten Buttons oder ein „X“ zum Schließen, das als Symbol unter 1.4.11 Nicht-Text-Kontrast läuft.

Als Farbfehlsichtiger lese ich einen weiteren Absatz besonders gern: Der Kontrast wird über die Helligkeit berechnet, nicht über den Farbton. Laut Dokument spielt der Farbton für die Lesbarkeit kaum eine Rolle. Eine Grenze nennt es trotzdem: sehr langwellige Farben wie Rot auf Schwarz, die bei Protanopie fast schwarz erscheinen. Deshalb wird von dieser Kombination abgeraten.

Im Projektalltag hilft das, wenn Design und Anforderung aufeinandertreffen. Heißt es „Das ist unsere Markenfarbe, die ist gesetzt“, steht im Understanding-Dokument die Antwort: Ausgenommen sind Logos, alles andere nicht. Verbindlich ist die Erläuterung nicht, aber sie zeigt, wie das W3C das Kriterium meint, und damit lässt sich gut argumentieren.

Mehr als Richtlinien und Kriterien: die allgemeinen Understanding-Dokumente

Neben den Dokumenten zu einzelnen Richtlinien und Kriterien gibt es allgemeine, die erklären, wie die WCAG funktionieren:

• Introduction to Understanding WCAG 2.2 (öffnet in neuem Tab) und About WCAG Understanding Docs (öffnet in neuem Tab): wie die Dokumente aufgebaut sind und wie man sie liest.
• Understanding Conformance (öffnet in neuem Tab): was Konformität bedeutet, welche Bedingungen dafür gelten und was Barrierefreiheitsunterstützung (accessibility support) heißt.
• How to refer to WCAG 2.2 from other documents (öffnet in neuem Tab): wie man in Verträgen, Vorgaben oder Normen korrekt auf die WCAG verweist.
• Documenting Accessibility Support (öffnet in neuem Tab): wie sich dokumentieren lässt, welche Hilfsmittel eine eingesetzte Webtechnologie unterstützen.
• Understanding Techniques (öffnet in neuem Tab) und Understanding Test Rules (öffnet in neuem Tab): die Grundlage für die nächsten beiden Abschnitte.

Techniken: Wege zum Ziel

Techniken zeigen konkret, wie sich ein Kriterium erfüllen lässt, mit Beschreibung, Beispielen, Hilfsmitteln und Tests. Gesammelt sind sie in den Techniques for WCAG 2.2 (öffnet in neuem Tab), sortiert nach Anwendungsfall: allgemein oder für eine bestimmte Technologie wie HTML, CSS oder ARIA. Die Kennung verrät es: G steht für allgemein (general), H für HTML, C für CSS. Während die Kriterien stabil bleiben, wird die Sammlung der Techniken regelmäßig an neue Entwicklungen angepasst.

Eine Technik kann zu mehreren Kriterien gehören. Oben auf jeder Technikseite steht, für welche und ob sie dort ausreichend oder ergänzend ist. Die Technik G18 etwa ist für 1.4.3 und 1.4.6 ausreichend.

Ausreichend heißt nicht notwendig

Hier passiert der häufigste Denkfehler. Ausreichende Techniken sind verlässliche Wege: Wer sie richtig umsetzt und wessen Browser und Hilfsmittel sie tatsächlich unterstützen, kann sicher sein, das Kriterium erfüllt zu haben. Ausreichend heißt also: reicht aus. Nicht: wird gebraucht. Es gibt andere Wege, und das W3C sagt das ausdrücklich. Manche Techniken gelten nur im Paket, dann verknüpft das Dokument sie mit „AND“.

Ergänzende Techniken (advisory) verbessern die Barrierefreiheit zusätzlich. Für das Kriterium reichen sie nicht aus, sind nicht immer anwendbar oder lassen sich nicht zuverlässig testen. Das W3C rät trotzdem, sie anzuwenden, wo sie passen.

Beim Kontrast sind die ausreichenden Techniken nach Situation sortiert: Situation A ist Text unter 18 Punkt (fett unter 14), Situation B Text ab dieser Größe. Der Name einer Technik verrät ihr Ziel, etwa bei der Technik G18: mindestens 4,5:1 Kontrast sicherstellen (öffnet in neuem Tab). Das Gegenstück für großen Text ist die Technik G145 mit 3:1. Zwei weitere gelten in beiden Situationen und zeigen gut, dass es mehr als einen Weg gibt: Technik G148 verlangt, weder Text- noch Hintergrundfarbe festzulegen, also die Voreinstellungen der Nutzenden gar nicht erst anzufassen. Technik G174 bietet einen Schalter an, der auf eine kontrastreiche Darstellung umstellt.

Wie so eine Technikseite aussieht, zeigt die Technik G18: eine Beschreibung, die auch Hintergründe behandelt, die nicht einfarbig sind. Liegt Text über einem Foto, wird der Bereich hinter dem Text abgedunkelt oder aufgehellt, oder die Buchstaben bekommen eine Kontur. Dazu kommen Beispiele, Hilfsmittel und ein Testverfahren zum Messen. Für Social-Media-Teams, die Text auf Fotos setzen, ist das ein sehr konkreter Einstieg. Für alle, die Code übernehmen wollen: Die Codebeispiele in den Techniken zeigen nur den jeweiligen Punkt und sind nicht zum Kopieren gedacht.

Typische Fehler: wo es sicher schiefgeht

Failures sind dokumentierte Fehler, die Barrieren erzeugen und ein bestimmtes Kriterium verfehlen. Sie zeigen, was man vermeiden sollte, und geben der Prüfung belastbare Anhaltspunkte. Der Unterschied zu den Techniken: Fehlt eine ausreichende Technik, ist das Kriterium nicht automatisch verfehlt, denn es gibt ja andere Wege. Steckt dagegen ein dokumentierter Fehler im Inhalt, ist das Kriterium nicht erfüllt, es sei denn, es gibt eine konforme Alternative ohne diesen Fehler.

Zum Kontrast gehören zwei. Der Fehler F24: Textfarbe ohne Hintergrundfarbe (öffnet in neuem Tab) entsteht, wenn eine Seite nur die Textfarbe festlegt, aber keine Hintergrundfarbe, oder umgekehrt. Dann weiß man nicht, was bei den Nutzenden ankommt. Stellt jemand den Browser auf dunkel, landet der eigens gesetzte dunkle Text womöglich auf dunklem Grund. Ob der Kontrast reicht, lässt sich nicht beurteilen, also gilt es als Fehler. Beim Fehler F83: Text auf Hintergrundbild (öffnet in neuem Tab) fehlt der Kontrast zwischen Schrift und Bild, das bekannte Foto mit der zu blassen Schrift darauf.

Testregeln: wie sich ein Kriterium prüfen lässt

Zuletzt gibt es die Testregeln (englisch Test Rules), entwickelt nach dem Format Accessibility Conformance Testing, kurz ACT. Sie richten sich an alle, die Prüfwerkzeuge bauen oder manuell prüfen, damit ein Kriterium überall gleich ausgelegt wird. Für 1.4.3 gibt es zwei: eine für den Mindestkontrast, eine für den erhöhten. Auch sie sind informativ und nicht so gründlich abgestimmt wie die WCAG selbst.

Noch ein Beispiel: die Übersicht vor dem Absenden

Im letzten Teil ging es um 3.3.4 Fehlervermeidung (rechtliche, finanzielle, Daten) (öffnet in neuem Tab), und ich hatte angekündigt, dass wir uns ansehen, wie man es erfüllt. Das Kriterium verlangt bei folgenreichen Vorgängen, dass mindestens eins zutrifft: Die Eingabe lässt sich rückgängig machen, sie wird auf Fehler geprüft und lässt sich korrigieren, oder es gibt eine Übersicht zum Prüfen, Bestätigen und Korrigieren vor dem endgültigen Absenden.

Das Understanding-Dokument zu 3.3.4 (öffnet in neuem Tab) macht greifbar, worum es geht. Der Intent nennt ein Flugticket, das sich nicht umtauschen lässt: Wer sich beim Datum vertippt, hat ein Ticket für den falschen Tag. Ebenso bei einer Börsenorder mit falscher Stückzahl, die sofort ausgeführt wird. Dahinter steht der Gedanke, dass Menschen mit Behinderung eher Fehler machen oder sie nicht bemerken: Wer Leseschwierigkeiten hat, vertauscht eher Ziffern, wer motorisch eingeschränkt ist, trifft eher die falsche Taste. Auch Daten gehören dazu, etwa ein komplettes Profil, das man versehentlich löscht. Ausdrücklich nicht gemeint ist, jedes Speichern bestätigen zu lassen.

Die Beispiele zeigen, wie es aussehen kann. Im Shop ist es die Bestellübersicht, in der man Artikel, Menge, Adresse und Zahlungsart prüft, bevor man bestellt. Beim Börsenhandel weist das System darauf hin, wenn eine Order nach Handelsschluss abgegeben wird, nennt die Risiken und lässt abbrechen oder bestätigen.

Die ausreichenden Techniken sind hier nach Situation sortiert:

Die Übersicht, die ich im letzten Teil genannt habe, ist also die Technik G98. Und dass es für dasselbe Kriterium mehrere gleichwertige Wege gibt, sieht man hier genauso wie beim Kontrast.

Wer schaut wohin?

Man muss nicht alles lesen. Je nach Aufgabe lohnen sich andere Teile:

Werkzeugkasten statt Regelwerk

Ein Erfolgskriterium allein liest sich wie ein Prüfpunkt. Erst mit den Begleitdokumenten wird daraus etwas, womit man arbeiten kann: Das Understanding-Dokument sagt, wozu es da ist, die Techniken zeigen Wege, die Fehler markieren die Sackgassen, und die Testregeln helfen beim Nachprüfen. Mein Eindruck: Die Understanding-Dokumente (öffnet in neuem Tab) gehen im Alltag schnell unter, vor allem bei allen, die nicht täglich mit den WCAG arbeiten. Dabei lohnt sich ein Lesezeichen. Für den Einstieg gilt: Ist der Fall klar, reicht die Schnellreferenz mit ihren Techniken und typischen Fehlern. Bleibt etwas offen, lohnt der Weg ins Understanding-Dokument, erst die Kurzfassung, dann der Intent. Alles Weitere bei Bedarf.

Verpflichtend ist davon nichts außer dem Kriterium selbst. Hilfreich ist es trotzdem fast immer, vor allem dann, wenn aus „nicht erfüllt“ eine Lösung werden soll oder wenn unklar ist, was genau gilt und wann.