So führen Sie selbst ein erstes Barrierefreiheits-Audit durch

Kurz gesagt: Führen Sie einen automatisierten Scan durch (axe, WAVE, Lighthouse), der etwa ein Viertel bis ein Drittel aller WCAG-Probleme aufdeckt, und erledigen Sie danach das, was er nicht kann: ausschließlich mit der Tastatur navigieren, stichprobenartig mit einem Screenreader prüfen, den Kontrast bei 4,5:1 für Text und 3:1 für großen Text und UI-Elemente verifizieren, und Alt-Texte sowie Beschriftungen lesen, wie es eine fremde Person tun würde. Ein echter erster Durchgang, kein Zertifikat.

Lassen Sie mich Sie Schritt für Schritt durch den Prozess führen, so wie ich es täte, säßen wir gemeinsam vor Ihrem Bildschirm, denn ein Nachmittag, an dem Sie das richtig machen, bringt Ihnen mehr bei als jeder Bericht, den ich Ihnen in die Hand geben könnte.

Was prüft ein Barrierefreiheits-Audit im ersten Durchgang eigentlich?

Ein Audit im ersten Durchgang besteht aus zwei Hälften, und die meisten Menschen erledigen nur die erste. Hälfte eins ist automatisiert: Ein Scanner markiert, was eine Maschine mit Sicherheit feststellen kann, etwa ein fehlendes alt-Attribut. Hälfte zwei ist manuell: Ein Mensch prüft, was Urteilsvermögen erfordert, etwa ob dieser alt-Text das Bild tatsächlich beschreibt oder ob die Tab-Reihenfolge für jemanden Sinn ergibt, der die Seite nicht sehen kann.

Überspringen Sie Hälfte zwei, und Sie haben Ihre Website nicht auditiert. Sie haben eine Rechtschreibprüfung laufen lassen und das ein Lektorat genannt.

Warum erkennen automatisierte Scanner nur ein Viertel bis ein Drittel Ihrer Probleme?

Hier ist die Zahl, die neu justieren sollte, wie sehr Sie sich von einem grünen Häkchen beruhigen lassen. Deque, das Unternehmen hinter der Open-Source-Engine axe-core, die die meisten Scanner antreibt, stellt unumwunden fest, dass die Barrierefreiheitsbranche automatisierte Abdeckung seit Langem bei etwa 20 bis 30 Prozent verortet (Deque, zur erneuten Prüfung). Ein separater Blick auf die Kriterien selbst kommt zu einem fast identischen Ergebnis: Nur etwa 30 Prozent der WCAG-2.1-Erfolgskriterien der Stufe AA, ungefähr 15 bis 16 davon, lassen sich überhaupt sinnvoll maschinell testen (TestParty, zur erneuten Prüfung). Alles andere braucht einen Menschen.

Eine kurze Warnung, damit Sie Tool-Marketing wie ein Profi lesen: Eine neuere, eigene Studie von Deque zu über 2.000 Audits und knapp 300.000 Problemen ergab, dass automatisiertes Testen 57 Prozent der Probleme erfasst, wenn man nach Volumen statt nach Kriterien zählt (Deque, zur erneuten Prüfung). Beide Zahlen stimmen, sie messen nur unterschiedliche Dinge. Zählen Sie nach Regel, und Automatisierung deckt weniger als ein Drittel des Regelwerks ab. Zählen Sie danach, wie oft ein Problem auf einer Seite auftaucht, und es sieht besser aus, weil eine Handvoll häufiger Probleme, allen voran der Kontrast, die Gesamtzahl aufbläht. So oder so braucht ein bedeutender Anteil echter Probleme einen Menschen, um gefunden zu werden.

Nichts davon ist ein Seitenhieb gegen axe, WAVE oder Lighthouse. Nutzen Sie noch heute eines davon. Axe DevTools und WAVE sind kostenlose Browser-Erweiterungen, Lighthouse ist direkt in Chromes DevTools eingebaut, und jedes liefert Ihnen in Minuten behebbare Mängel: fehlende Beschriftungen, falsche Überschriftenreihenfolge, Kontrastfehler, doppelte IDs. Das sind die schnellsten zehn Minuten Fortschritt bei der Barrierefreiheit, die Sie diese Woche bekommen werden. Verwechseln Sie nur keinen sauberen Scan mit einer sauberen Website. Keines der drei Tools kann Ihnen sagen, ob Ihr Alt-Text Sinn ergibt oder ob ein Besucher, der nur die Tastatur nutzt, durch Ihren Checkout kommt (David Mello, zur erneuten Prüfung). Das ist die manuelle Hälfte, und dort lebt das eigentliche Audit.

Was sollte ich von Hand prüfen, und in welcher Reihenfolge?

Fünf Prüfungen, in der Reihenfolge, in der ich sie durchführe. Jede dauert auf einer typischen Seite fünfzehn bis dreißig Minuten, und zusammen fördern sie mehr echte Mängel zutage als jeder Scanner allein.

Erreichen und bedienen Sie alles nur mit der Tastatur?

Legen Sie die Maus beiseite. Nutzen Sie Tab, um vorwärts zu springen, Umschalt+Tab, um zurückzuspringen, Enter oder Leertaste zum Aktivieren, und die Pfeiltasten innerhalb von Menüs und benutzerdefinierten Widgets. Stellen Sie sich dabei drei Fragen. Erreichen Sie jeden Link, jede Schaltfläche und jedes Formularfeld. Gibt es immer einen sichtbaren Fokusindikator, der genau zeigt, wo Sie sich befinden. Und kommen Sie aus allem, was Sie geöffnet haben, einem Modal, einem Menü, einer Datumsauswahl, wieder heraus, ohne gefangen zu bleiben. Eine Tastaturfalle, bei der der Fokus in eine Komponente hinein-, aber nicht mehr herausspringt, ist einer der am stärksten ausschließenden Mängel, den eine Website haben kann: Sie behindert einen Tastaturnutzer nicht nur, sie stoppt ihn vollständig.

Wie klingt Ihre Seite mit einem Screenreader?

Sie müssen darin nicht flüssig werden. Sie brauchen dreißig ehrliche Minuten mit dem Tool, das Ihre Nutzer am wahrscheinlichsten verwenden. NVDA ist unter Windows kostenlos und quelloffen, und VoiceOver ist fest in jeden Mac und jedes iPhone eingebaut, sodass Sie beide kostenlos ausprobieren können. Diese Verbreitung zählt: WebAIMs jüngste Screen Reader User Survey ergab, dass NVDA und JAWS als meistgenutzte primäre Desktop-Screenreader mit 38 und 41 Prozent fast gleichauf liegen, wobei NVDA vorne liegt, sobald man alle mitzählt, die es überhaupt einsetzen (WebAIM, zur erneuten Prüfung). Schalten Sie einen ein, schließen Sie die Augen, und versuchen Sie, die wichtigste Aufgabe Ihrer Website zu erledigen: ein Formular absenden, einen Artikel von Anfang bis Ende lesen. Notieren Sie jeden Moment der Verwirrung. Diese Verwirrung ist Ihre Mängelliste.

Erreichen Ihr Text und Ihre Bedienelemente die Mindestkontraste?

Das ist die einzige Prüfung mit einer harten Zahl, keine Ermessensfrage. Das Kriterium Kontrast (Minimum) der WCAG verlangt mindestens 4,5:1 für normalen Text gegenüber seinem Hintergrund, abgesenkt auf 3:1 für großen Text, etwa 18 Punkt oder 14 Punkt fett und größer (W3C). Ein verwandtes Kriterium, der Kontrast von Nicht-Text-Inhalten, weitet dasselbe 3:1-Minimum auf die visuellen Teile von UI-Komponenten aus, die ein Nutzer erkennen und bedienen muss: Eingabefeldrahmen, Icon-Schaltflächen, Umschaltzustände (W3C). Prüfen Sie das sorgfältig, denn es ist mit Abstand der häufigste Fehler im Web. WebAIMs neueste Analyse der eine Million meistbesuchten Startseiten fand kontrastarmen Text auf 83,9 Prozent von ihnen, mit durchschnittlich 34 Fällen pro Seite (WebAIM, zur erneuten Prüfung). Jeder Farbwähler im Browser oder jede Kontrast-Erweiterung liefert Ihnen den Kontrastwert in Sekunden. Prüfen Sie Fließtext, Links, Platzhaltertext und Schaltflächenrahmen, nicht nur die Überschrift.

Würde Ihr Alt-Text Sinn ergeben, laut vorgelesen und ohne sichtbares Bild?

Decken Sie das Bild ab und lesen Sie nur den Alt-Text laut vor. Vermittelt er dieselbe Information, die ein sehender Besucher bekommt. „Foto eines Laptops“ sagt einem Screenreader-Nutzer nichts. „Dashboard zeigt Umsatz im Quartalsvergleich um 12 Prozent gestiegen“ erfüllt den Zweck. Dekorative Bilder sollten einen leeren Alt-Text (alt="") erhalten, damit Screenreader sie stillschweigend überspringen, statt einen Dateinamen vorzulesen. Das ist wichtiger, als die meisten Website-Betreiber annehmen: Fehlender oder nutzloser Alt-Text tauchte in derselben WebAIM-Analyse auf 53,1 Prozent der Startseiten auf, und fast die Hälfte davon waren verlinkte Bilder, was die Navigation für einen Screenreader-Nutzer vollständig zerstört, nicht nur das Verständnis (WebAIM, zur erneuten Prüfung).

Beschriften Ihre Formulare alles, und erklären sie Fehler in Worten?

Klicken Sie mit nichts als Tab und laufendem Screenreader in jedes Feld. Kündigt er eine echte Beschriftung an, „E-Mail-Adresse“, nicht Stille, nicht einen Platzhalter, der verschwindet, sobald Sie zu tippen beginnen. Senden Sie das Formular absichtlich mit einem Fehler ab. Sagt die Fehlermeldung, was falsch ist und wie man es behebt, in Textform, nicht nur mit einem roten Rahmen, der jemandem, der Rot oder den Rahmen überhaupt nicht sehen kann, gar nichts mitteilt. Das ist keine Kleinigkeit: Fehlende Formularbeschriftungen tauchten auf 51 Prozent der Startseiten auf (WebAIM, zur erneuten Prüfung), was bedeutet, dass jede zweite Website die Hälfte ihrer Besucher raten lässt.

Was hat WCAG 2.2 hinzugefügt, wovon die meisten Website-Betreiber noch nie gehört haben?

WCAG 2.2 hat neun neue Erfolgskriterien zu 2.1 hinzugefügt, und vier davon sind die, die ich ständig übersehen sehe, weil die meisten bestehenden Checklisten vor dem Erscheinen von 2.2 geschrieben und nie aktualisiert wurden (W3C).

Zielgröße, 2.5.8. Interaktive Ziele, Schaltflächen, Links, Icons, die Sie antippen, müssen mindestens 24 mal 24 CSS-Pixel groß sein, oder genug Abstand zueinander haben, dass ein 24 Pixel großer Kreis um die Mitte jedes Ziels den Nachbarn nicht berührt (W3C). Das gilt für jeden mit eingeschränkter Feinmotorik, und für uns alle, wenn wir mit dem Handy in einem fahrenden Bus stehen.

Fokus nicht verdeckt, 2.4.11. Wenn etwas den Tastaturfokus erhält, darf ein fixierter Header, ein Cookie-Banner oder ein Chat-Widget es nicht vollständig verdecken. Wenn Sie nicht sehen können, wo der Fokus liegt, können Sie die Tastatur nicht mit Sicherheit bedienen, und fixierte Header sind heute überall.

Redundante Eingabe, 3.3.7. Wenn ein Nutzer Ihnen eine Information bereits früher in einem Ablauf gegeben hat, zwingen Sie ihn nicht, sie in derselben Sitzung erneut einzutippen, außer Sie füllen sie automatisch aus oder bieten sie als auswählbare Option an. Mehrstufige Checkouts und lange Antragsformulare sind die üblichen Verursacher.

Barrierefreie Authentifizierung, 3.3.8. Sich anzumelden sollte nicht erfordern, ein Rätsel zu lösen, ein verzerrtes Bild abzutippen, oder sich etwas ohne Alternative zu merken. Passwort-Manager, „Schick mir einen Link“ und biometrische Verfahren erfüllen diese Anforderung alle. Ein CAPTCHA ohne alternativen Weg tut das nicht.

Keines dieser vier taucht zuverlässig in einem automatisierten Scan auf. Alle vier sind Dinge, die Sie selbst von Hand prüfen, in unter zehn Minuten pro Seite.

Sie haben zwanzig Probleme gefunden. In welcher Reihenfolge beheben Sie sie?

Arbeiten Sie nicht von oben nach unten. Arbeiten Sie danach, wie vielen Menschen eine Behebung hilft, im Verhältnis dazu, wie lange sie dauert.

Beginnen Sie mit der Handvoll Fehlertypen, die ständig auftauchen, denn ein Muster einmal zu beheben, löst es meist überall dort, wo es sich wiederholt. WebAIMs Untersuchung ergab, dass nur sechs Fehlerkategorien, kontrastarmer Text, fehlender Alt-Text, fehlende Formularbeschriftungen, leere Links, leere Schaltflächen und fehlende Dokumentsprache, für 96 Prozent aller erkannten Fehler auf der eine Million meistbesuchten Startseiten verantwortlich sind (WebAIM, zur erneuten Prüfung). Das sind selten sechs getrennte Aufgaben. Es ist meist je ein Design-Token, eine Komponente und eine Vorlagenkorrektur, die sich in dem Moment, in dem Sie sie einspielen, über Ihre gesamte Website wiederholt.

Eine einfache Methode, das Gefundene zu priorisieren:

1. Blockiert eine Aufgabe vollständig. Eine Tastaturfalle, ein unbeschriftetes Pflichtfeld, ein Login, den ein Screenreader-Nutzer nicht abschließen kann. Beheben Sie das immer zuerst.
2. Betrifft die meisten Seiten durch eine einzige Ursache. Ein globales Kontrast-Token, eine Button-Komponente, eine Header-Vorlage. Eine Änderung behebt Dutzende Fälle auf einmal.
3. Betrifft eine einzelne Seite oder einen seltenen Pfad. Eine einmalige Bildunterschrift, eine alte Landingpage, auf die niemand verlinkt. Beheben Sie es, sobald Sie diese Seite als Nächstes anfassen.
4. Kosmetischer oder AAA-Feinschliff. Tatsächlich niedrigere Priorität, kann problemlos hinter den ersten drei einsortiert werden.

Was ein Audit im ersten Durchgang nicht ist

Ich möchte hier ehrlich zu Ihnen sein, denn zu viel zu versprechen ist das Einzige, was ich auf dieser Website nicht tun werde. Ein selbst durchgeführtes Audit im ersten Durchgang ist keine Zertifizierung. Es ist kein VPAT (ein Voluntary Product Accessibility Template), es ist keine rechtliche Absicherung, und es ersetzt keine Tests mit tatsächlichen Menschen mit Behinderungen, die Dinge finden, die keine Checkliste vorhersieht, weil sie assistive Technologie unter realen Bedingungen nutzen, die Sie und ich an einem Schreibtisch nicht vollständig simulieren können. Die eigene Leitlinie des W3C zur Bewertung von Barrierefreiheit sagt es unumwunden: Kein Tool allein kann bestimmen, ob eine Website Barrierefreiheitsstandards erfüllt, und fachkundige menschliche Bewertung ist erforderlich, um dieses Urteil zu fällen (W3C). Ein Nachmittag mit den obigen Prüfungen verschafft Ihnen einen echten, ehrlichen ersten Durchgang: die lautesten Probleme gefunden und behoben, und ein klareres Gefühl dafür, wo die tieferen Lücken vermutlich liegen. Das lohnt sich, noch heute zu tun. Es ist nicht die Ziellinie.

Der Durchgang, den ich auf jeder Seite mache

Die Routine, damit Sie sie sich abschauen können:

• Führen Sie einen automatisierten Scan durch. Beheben Sie jedes markierte Problem; es kostet nichts.
• Stecken Sie die Maus aus. Tabben Sie sich durch und notieren Sie alles, was unerreichbar, unsichtbar oder gefangen ist.
• Schalten Sie NVDA oder VoiceOver ein und erledigen Sie Ihre wichtigste Aufgabe mit geschlossenen Augen.
• Prüfen Sie den Kontrast bei Fließtext, Links, Platzhaltern und Schaltflächenrahmen.
• Lesen Sie Ihren Alt-Text und Ihre Formularbeschriftungen laut vor, als würden Sie die Seite zum ersten Mal sehen.
• Prüfen Sie die vier Ergänzungen aus WCAG 2.2 von Hand: Zielgröße, verdeckter Fokus, redundante Eingabe, barrierefreie Authentifizierung.
• Priorisieren Sie das Gefundene danach, wie viele Menschen es blockiert, nicht danach, auf welcher Seite es liegt.
• Beheben Sie zuerst die Muster, die den größten Schaden anrichten, und arbeiten Sie sich dann nach unten vor.

Machen Sie das einmal richtig, und Sie werden Ihre eigene Website danach für immer anders lesen.