Accessibility Testing

Accessibility Testing

0:00 Jetzt kommt das Modul, auf das Tag zwei hingearbeitet hat: Wie prüft man das alles? Und ich stelle den wichtigsten Satz gleich an den Anfang, weil er in Projekten oft anders behauptet wird: Ein sauberer automatischer Lauf ist kein Konformitätsnachweis. Werkzeuge sind nützlich, sie sind schnell, und sie finden zuverlässig einen Teil der Fehler. Aber sie können bestimmte Dinge grundsätzlich nicht prüfen — dazu gleich mehr.

0:24 Das W3C weist ausdrücklich darauf hin, dass menschliches Urteil erforderlich bleibt und Werkzeuge auch falsche oder irreführende Ergebnisse liefern können. Wir schauen uns deshalb an, was womit geprüft wird.

Accessibility Testing

0:37 Neun Kapitel, aufgebaut wie ein Prüfhandbuch. Erst die Einordnung der drei Prüfarten, dann das Werkzeug, das Sie sowieso schon haben — den Accessibility Tree im Browser. Dann die automatischen Prüfwerkzeuge und ihre Verortung im Prozess. Danach vier manuelle Prüfungen: Tastatur, visuelle Bedingungen, ein Screenreader-Rauchtest und die dynamischen Zustände.

0:58 Und zum Schluss die Frage, wie ein Befund aussehen muss, damit er tatsächlich bearbeitet wird. In der Übung prüfen Sie zwei Seiten und schreiben einen Bericht — mit einer Auswertung, die regelmäßig überrascht.

Automatisiert, halbautomatisiert und manuell

1:11 Drei Prüfarten, die einander ergänzen und nicht ersetzen. Der Reiz der ersten ist offensichtlich: Sie kostet nichts und läuft ständig. Die Grenze ist es leider auch — man muss sie nur kennen. Automatische Prüfungen finden zuverlässig einen Teil der Fehler: fehlende Alternativtexte, unzureichende Kontraste, kaputte Verknüpfungen.

1:32 Das ist echter Wert, und es ist Fließbandarbeit, die niemand von Hand machen sollte. Halbautomatische Werkzeuge gehen einen Schritt weiter: Sie führen Sie durch Prüfschritte, die menschliches Urteil brauchen — sie fragen, statt zu entscheiden. Und die manuelle Prüfung deckt den Rest ab. Die entscheidende Aussage ist die letzte: Keine ersetzt die andere.

1:53 Wer das eine gegen das andere ausspielt, bekommt entweder eine unvollständige Prüfung oder eine unbezahlbare. Die Kunst ist die Kombination. Die rechte Spalte ist das Herzstück dieser Folie. Automatische Prüfung findet fehlende Namen und misst Kontrastwerte — sie kann aber grundsätzlich nicht beurteilen, ob ein vorhandener Name sinnvoll ist.

2:15 Ein Alternativtext „Bild" besteht jede automatische Prüfung. Halbautomatik sagt Ihnen, was zu prüfen ist, nimmt Ihnen die Entscheidung aber nicht ab. Und bei der manuellen Prüfung steht in der rechten Spalte etwas Bemerkenswertes: „Nichts — aber es kostet Zeit". Das ist die ehrliche Bilanz. Der Mensch kann alles prüfen.

2:34 Deshalb ist die Frage nicht, ob man manuell prüft, sondern wie gezielt. Der erste Stolperstein ist der Leitsatz dieses Moduls: einen grünen automatischen Lauf als Konformitätsnachweis führen. Das passiert vor allem gegenüber Dritten und wird dort früher oder später auffliegen. Der zweite ist der eben gezeigte: Alternativtexte als vorhanden werten, ohne ihren Inhalt zu prüfen.

2:57 Vorhanden und sinnvoll sind zwei verschiedene Dinge, und nur das erste ist messbar. Und der dritte ist der gefährlichste, weil er so plausibel klingt: die manuelle Prüfung streichen, weil das Werkzeug nichts meldet. Das Werkzeug meldet nichts über Dinge, die es nicht prüfen kann — Stille ist hier keine Auskunft.

Der Accessibility Tree im Browser

3:16 Jetzt zum Werkzeug, das Sie schon haben und wahrscheinlich noch nie geöffnet haben. Es sitzt in Ihren Entwicklerwerkzeugen und beantwortet die meisten Fragen in dreißig Sekunden. In jedem modernen Browser zeigen die Entwicklerwerkzeuge zu jedem Element genau die vier Angaben aus Modul neun: Rolle, Name, Zustand und Wert.

3:35 Das ist der schnellste Weg, eine Vermutung zu prüfen. Sie glauben, der Knopf heißt „Buchen"? Ein Blick zeigt Ihnen, dass er gar keinen Namen trägt. Und jetzt kommt der wirtschaftlich interessante Teil: Wer diesen Blick zur Gewohnheit macht, findet Fehler beim Entwickeln statt in der Abnahme. Das ist die billigste Verschiebung im ganzen Prozess — ein Fehler, den Sie beim Schreiben bemerken, kostet Minuten. Derselbe Fehler in der Abnahme kostet Tage.

4:02 Fünf Handgriffe, und Sie brauchen dafür wirklich nur eine halbe Minute. Element auswählen, den Accessibility-Bereich öffnen, dann drei Fragen: Entspricht die Rolle dem, was das Element sein soll? Steht im Namen das, was sichtbar dransteht? Spiegelt der Zustand die aktuelle Darstellung? Und bei Abweichung — Schritt fünf — im Markup nachsehen, nicht im Stylesheet.

4:24 Das ist wichtig: Die Ursache sitzt praktisch nie in der Gestaltung. Die Fußzeile ergänzt einen Punkt, den wir mehrfach hatten: Weicht der Name von der sichtbaren Beschriftung ab, scheitert auch die Sprachsteuerung — und das betrifft Menschen, die gar keinen Screenreader nutzen. Der erste Stolperstein begleitet uns seit Modul acht: nur das DOM ansehen und den zweiten Baum nie öffnen. Er ist zwei Klicks entfernt.

4:49 Der zweite ist eine feine, aber folgenreiche Verwechslung: den berechneten Namen mit dem Wert eines Attributs verwechseln. Der Name entsteht aus mehreren Quellen nach festen Regeln — was Sie im Attribut geschrieben haben, ist nicht zwingend das, was ankommt. Der Baum zeigt Ihnen das Ergebnis. Und der dritte ist ein Prüfumfangsfehler: Zustände im Ruhezustand prüfen und den geänderten nie nachsehen.

5:12 Klappen Sie das Panel auf und schauen Sie noch einmal — das ist der eigentliche Test.

Werkzeuge für automatische Prüfungen

5:17 Jetzt zu den Werkzeugen. Die gute Nachricht: Es gibt mehrere gute. Die praktische Empfehlung ist trotzdem eindeutig — legen Sie sich auf eines fest und verwenden Sie es überall. Lighthouse, axe und Accessibility Insights prüfen im Kern ähnliche Regelsätze mit verschiedenen Oberflächen. Welches Sie nehmen, ist weniger wichtig, als es die Diskussionen im Team vermuten lassen.

5:41 Wichtig ist die Festlegung: eines auswählen und überall verwenden — im Browser, in der Komponentenwerkstatt und in der Pipeline. Denn wenn an drei Stellen drei Werkzeuge laufen, bekommen Sie drei verschiedene Zahlen für denselben Zustand. Und dann diskutiert Ihr Team über Zahlen statt über Behebungen. Ich habe das mehrfach erlebt; es kostet erstaunlich viel Energie und bringt nichts.

6:03 Vier Orte, vier Zwecke — und dieselbe Prüfengine an allen vieren. Im Browser als Erweiterung, für die Arbeit beim Entwickeln und beim Review. In der Komponentenwerkstatt je Eintrag, um Fehler zu finden, bevor die Komponente irgendwo verwendet wird — das ist die wirksamste Stelle überhaupt, weil eine Komponente an dreißig Orten steckt.

6:23 In der Pipeline mit fester Schwelle, um Rückfälle zu verhindern. Und im Bericht mit Datum, als Nachweis gegenüber Dritten. Achten Sie auf die zweite Zeile: Prüfen auf Komponentenebene ist die günstigste Prüfung, die Sie einrichten können. Der erste Stolperstein ist der eben besprochene: zwei Werkzeuge parallel führen und ihre Zahlen vergleichen.

6:44 Sie messen leicht Verschiedenes, und der Vergleich erzeugt Misstrauen gegen beide. Der zweite ist eine Nachvollziehbarkeitsfrage: die Regelversion nicht festhalten. Regelsätze werden weiterentwickelt — dieselbe Seite kann nächstes Jahr andere Ergebnisse liefern, ohne dass sich etwas geändert hat. Notieren Sie die Version, wie die Fassung der Norm in Modul sieben. Und der dritte ist ein Frustgenerator: im Browser prüfen und in der Pipeline andere Regeln aktiv haben.

7:11 Dann bricht der Bau bei etwas, das lokal grün war.

Tastatur- und Fokusprüfung

7:15 Jetzt der wirksamste manuelle Test überhaupt. Er dauert wenige Minuten, braucht kein Werkzeug und keine Schulung — und er gehört in jede Definition of Done. Einmal mit dem Tabulator durch die Seite. Das ist der ganze Test. Geprüft wird viererlei: Ist alles erreichbar, stimmt die Reihenfolge, bleibt der Fokus sichtbar, bleibt man nirgends hängen.

7:36 Und weil die Tastatur der gemeinsame Nenner fast aller assistiven Techniken ist — das war die Kernaussage von Modul acht —, deckt dieser eine Test einen erstaunlich großen Teil der Bedienbarkeit ab. Deshalb meine klare Empfehlung: Nehmen Sie ihn in Ihre Definition of Done auf. Er kostet drei Minuten pro Änderung, verlangt keine Anschaffung und keine Fortbildung, und er findet die häufigsten Fehler.

7:59 Vier Fragen, und sie decken die Kapitel eins bis sieben von Modul zehn ab. Ist jedes Bedienelement erreichbar — auch das hinter Aufklappflächen, was gern vergessen wird. Entspricht die Reihenfolge dem, was das Auge erwartet? Bleibt der Indikator jederzeit sichtbar und unverdeckt — denken Sie an die klebende Kopfzeile. Und komme ich überall wieder heraus, ohne zur Maus zu greifen? Das ist die Fokusfallen-Frage. Vier Fragen, ein Durchlauf.

8:26 Wenn Sie in Ihrem Team nur eine einzige Prüfung einführen können, dann diese — sie hat das beste Verhältnis von Aufwand zu gefundenen Fehlern. Der erste Stolperstein ist ein Umfangsfehler: nur den Hauptweg prüfen und Dialoge und Fehlerfälle auslassen. Genau dort liegen die Fokusprobleme, wie Modul zehn gezeigt hat. Der zweite ist subtil und passiert jedem: die Prüfung mit sichtbarem Mauszeiger machen und unbewusst korrigieren.

8:53 Man greift kurz zur Maus, ohne es zu merken, und die Lücke ist übersprungen. Nehmen Sie die Hand von der Maus. Und der dritte ist ein Abbruchfehler: bei der ersten Hürde aufhören. Notieren Sie sie, helfen Sie sich einmalig mit der Maus über genau diese Stelle und gehen Sie weiter — sonst finden Sie nur den ersten Fehler.

Kontrast, Zoom und responsive Varianten prüfen

9:12 Drei Prüfungen, die schnell erledigt und selten systematisch gemacht werden. Der Grund dafür ist organisatorisch: Sie fallen zwischen Design und Entwicklung durch, und niemand fühlt sich zuständig. Drei Prüfungen aus Modul dreizehn, jetzt als Verfahren. Kontraste prüft man an den tatsächlichen Zuständen — auch Hover, Fokus und Fehler, nicht nur im Ruhezustand.

9:34 Zoom prüft man bei zweihundert und vierhundert Prozent sowie bei dreihundertzwanzig Pixeln Breite. Und der dritte Punkt ist der, den ich für den wichtigsten halte: Jede Breite ist eine eigene Oberfläche. Der Filter, der auf dem Desktop offen daliegt, steckt mobil hinter einem Dialog — mit eigenem Fokusverhalten, eigenem Zustand, eigenen Fehlermöglichkeiten.

9:55 Sie prüfen also nicht dieselbe Seite kleiner, Sie prüfen eine zweite Oberfläche. Fünf Schritte, zehn Minuten. Kontraste erst im Ruhezustand, dann in den drei anderen Zuständen. Auf zweihundert Prozent zoomen und auf abgeschnittenen Text achten. Auf vierhundert Prozent und prüfen, ob das Layout umbricht. Auf dreihundertzwanzig Pixel und horizontales Scrollen suchen.

10:18 Und Schritt fünf ist der, den die Fußzeile zu Recht heraushebt: die mobile Fassung gegen die Funktionsliste der breiten abgleichen. Das ist der häufigste Befund dieser ganzen Reihe — irgendetwas fehlt in der schmalen Fassung, stillschweigend. Sie brauchen dafür die Liste aus Modul fünf; ohne sie sehen Sie das Fehlende nicht.

10:38 Der erste Stolperstein ist der Vollständigkeitsfehler beim Kontrast: nur den Ruhezustand messen. Fokus und Fehler haben eigene Farben, und die sind oft schwächer. Der zweite ist ein Abbruch zur Unzeit: bei vierhundert Prozent aufhören, bevor Formulare und Dialoge geprüft sind. Ausgerechnet bei starker Vergrößerung werden Dialoge zum Problem — sie passen dann nicht mehr auf den Bildschirm.

11:01 Und der dritte ist der eben genannte: die schmale Fassung prüfen, ohne zu wissen, was in der breiten steht. Ohne den Abgleich sehen Sie eine aufgeräumte mobile Seite und halten sie für gut gemacht.

Screenreader-Smoke-Tests mit NVDA und VoiceOver

11:13 Jetzt der Test, vor dem die meisten zurückschrecken. Die gute Nachricht: Sie müssen kein geübter Nutzer sein. Ein Dutzend Tastenkombinationen reicht für einen aussagekräftigen Rauchtest. Ein kurzer Durchlauf beantwortet drei Fragen: Wird die Seitenstruktur klar? Haben alle Bedienelemente Namen? Werden Änderungen angesagt?

11:33 Dafür brauchen Sie kein Expertentum, nur ein paar Tastenkombinationen. Wichtig zu wissen: Screenreader verhalten sich unterschiedlich, und Kombinationen aus Screenreader und Browser noch mehr — dieselbe Seite kann sich in zwei Kombinationen deutlich anders anhören. NVDA mit Firefox unter Windows und VoiceOver mit Safari auf dem Mac sind eine sinnvolle Mindestabdeckung.

11:56 Und daraus folgt die wichtigste Regel für Ihre Befunde: Nennen Sie immer die geprüfte Kombination. Vier Fragen, vier Handgriffe. Die Überschriftenliste aufrufen — jeder Screenreader kann das mit einer Taste — und sehen, ob die Struktur trägt. Die Landmarkliste aufrufen und prüfen, ob Bereiche anspringbar sind; wenn Inhalt fehlt, steht er außerhalb aller Bereiche.

12:18 Die Elementliste durchgehen und nach Schaltflächen ohne Bezeichnung suchen — das ist eine sehr effiziente Art, Namenslücken zu finden. Und den Filter ändern und hören, ob etwas gemeldet wird; Stille ist hier der Befund. Diese vier Handgriffe sind in zehn Minuten gemacht und finden Dinge, die kein automatisches Werkzeug findet.

12:38 Der erste Stolperstein kennen Sie aus Modul acht und er bleibt der wichtigste: den eigenen ungeübten Umgang mit dem Werkzeug als Produktfehler protokollieren. Kennzeichnen Sie im Zweifel, dass Sie unsicher sind — das ist ehrlicher und hilft bei der späteren Bewertung. Der zweite: nur eine Kombination prüfen und das Ergebnis verallgemeinern. Was in einer Kombination funktioniert, kann in einer anderen scheitern.

13:02 Und der dritte ist ein Berichtsfehler mit großer Wirkung: die geprüfte Kombination im Befund nicht nennen. Dann kann niemand den Befund nachstellen — und ein nicht nachstellbarer Befund wird zurückgewiesen.

Dynamische Zustände prüfen

13:14 Jetzt eine Erkenntnis, die die Prüfstrategie verändert. Die meisten Fehler stecken nicht im Ausgangszustand — sondern in den Zuständen, die eine automatische Prüfung selten überhaupt erreicht. Denken Sie an eine Wohnungsbesichtigung. Sie sehen die aufgeräumte Wohnung bei Tageslicht — und erfahren nichts über die Heizung im Winter und den Lärm am Abend.

13:35 Genauso ist es mit der frisch geladenen Seite. Die meisten Fehler stecken im geöffneten Dialog, im Fehlerfall, in der leeren Ergebnisliste, im Ladezustand. Eine Prüfung, die nur den Ausgangszustand betrachtet, übersieht genau die Stellen, an denen Nutzende tatsächlich scheitern. Und es sind genau die Zustände, die automatische Läufe selten erreichen, weil sie eine Interaktion brauchen. Das ist der Grund, warum die manuelle Prüfung nicht ersetzbar ist.

14:01 Die mittlere Spalte ist praktisch — sie sagt Ihnen, wie Sie in jeden Zustand kommen. Dialog auslösen und dort messen. Ungültig absenden, um in den Fehlerfall zu kommen. Einen unmöglichen Filter setzen für die leere Ergebnisliste — bei Fahrtwind etwa eine Verbindung in der Vergangenheit. Und die Verbindung drosseln für den Ladezustand; das können die Entwicklerwerkzeuge in jedem Browser.

14:25 Die rechte Spalte nennt den typischen Befund, und alle vier sind uns in diesem Seminar schon begegnet. Machen Sie sich daraus eine kleine Prüfliste — vier Zustände, die jede Prüfung erreichen muss. Der erste Stolperstein ist der naheliegende und der häufigste: den automatischen Lauf nur auf der geladenen Seite ausführen.

14:45 Die meisten Werkzeuge lassen sich auch im geöffneten Dialog auslösen — tun Sie das. Der zweite ist eine Abkürzung, die Ergebnisse verfälscht: Fehlerzustände von Hand im Markup nachstellen, statt sie auszulösen. Der nachgestellte Zustand hat womöglich genau die Attribute, die im echten Ablauf nicht gesetzt werden. Und der dritte ist ein Umgebungsproblem: den Ladezustand auslassen, weil er lokal nie sichtbar wird. Auf Ihrem Rechner ist alles sofort da. Bei Ihren Nutzern nicht.

Reproduzierbare Befunde und Conformance Reports

15:14 Das letzte inhaltliche Kapitel behandelt das Ergebnis. Denn ein Befund, den man nicht nachstellen kann, wird zurückgewiesen — und dann war die ganze Prüfung umsonst. Ein brauchbarer Befund nennt sieben Dinge: Seite, Element, Schritte, erwartetes und tatsächliches Verhalten, das verletzte Kriterium, die geprüfte Technikkombination und die Auswirkung auf Nutzende.

15:36 Das klingt nach viel und passt auf acht Zeilen, wie Sie gleich sehen. Für Nachweise gegenüber Dritten wird der Konformitätsstand strukturiert dokumentiert: je Kriterium eine Bewertung mit Begründung. Und die Anforderungen an so einen Bericht kennen Sie schon aus Modul sieben — ohne Datum, Umfang und zugrunde gelegte Fassung ist er wertlos.

15:55 Das ist dieselbe Aussage, hier aus der Prüfperspektive. Vergleichen Sie die beiden Fassungen. Oben: „Sitzplatzwahl nicht barrierefrei." Das ist keine Meldung, das ist ein Vorwurf — und es wird zurückgewiesen, weil niemand damit arbeiten kann. Unten dieselbe Sache in acht Zeilen: Wo, was, wie komme ich hin, was habe ich erwartet, was ist passiert, welches Kriterium ist verletzt, womit geprüft, wen betrifft es.

16:20 Die Fußzeile hebt die letzten beiden Zeilen hervor, und das zu Recht: Die Technikkombination macht den Befund nachstellbar, die Auswirkung macht ihn priorisierbar. Ohne die Auswirkung bleibt es eine Formalie, die im Backlog verstaubt. Der erste Stolperstein macht jeden Befund angreifbar: ohne Reproduktionsschritte melden.

16:40 Die Entwicklung kann es nicht nachstellen, schließt das Ticket als nicht reproduzierbar, und beide Seiten sind frustriert. Der zweite ist der eben besprochene: die Auswirkung weglassen. Dann steht ein Kriterium da, und die Priorisierung wird zur Formaldiskussion — statt „blinde Reisende können nicht buchen" steht dort eine Nummer.

16:59 Und der dritte betrifft den Bericht als Ganzes: ihn ohne Prüfumfang und Datum herausgeben. Was wurde geprüft und was nicht — ohne diese Angabe ist ein Bericht nicht bewertbar und in Abnahmen wertlos.

Übung — einen Prüfdurchlauf mit Bericht

17:11 In der Übung machen Sie einen vollständigen Durchlauf — automatisch und manuell — und werten am Ende etwas aus, das den meisten Gruppen die Augen öffnet. Sie prüfen zwei Seiten und schreiben einen Bericht. Geübt wird die Kombination von automatischer und manueller Prüfung — so, dass jeder Befund reproduzierbar und einem Kriterium zugeordnet ist.

17:31 Erfolgreich sind Sie, wenn der Bericht je Befund Schritte, Kriterium, Technikkombination und Auswirkung nennt und ausgewiesen ist, welche Befunde nur der Mensch gefunden hat. Diese letzte Ausweisung ist der Kern der Übung: Die Gruppe sieht dann schwarz auf weiß, wie groß der manuelle Anteil tatsächlich ist. Wer früh fertig ist, prüft dieselben Seiten mit einem zweiten Werkzeug und vergleicht die Unterschiede.

17:55 Fünf Schritte, und die Reihenfolge ist bewusst gewählt. Zuerst automatisch prüfen und die Befunde unverändert festhalten — unverändert ist wichtig, damit Sie später vergleichen können. Dann mit der Tastatur durchgehen und ergänzen, was das Werkzeug nicht fand. Dann die dynamischen Zustände auslösen und dort erneut prüfen.

18:14 Dann je Befund Kriterium, Technikkombination und Auswirkung ergänzen. Und Schritt fünf ist der Lerneffekt: nach Schwere ordnen und ausweisen, was nur manuell gefunden wurde. Der manuelle Anteil überrascht regelmäßig — und danach diskutiert niemand mehr darüber, ob der automatische Lauf reicht. Der erste Stolperstein macht die Übung sinnlos: nur die automatisch gefundenen Befunde in den Bericht übernehmen. Dann fehlt genau der Teil, um den es geht.

18:42 Der zweite ist eine gut gemeinte Straffung: Befunde zusammenfassen — „mehrere Elemente ohne Namen". Damit ist die Reproduktion unmöglich, und die Behebung wird zur Suche. Ein Befund je Stelle. Und der dritte ist eine Verwechslung von Kategorien: die Auswirkung als Schweregrad formulieren. „Schwer" ist eine Bewertung, „blinde Reisende können nicht buchen" ist die Folge für Menschen — und nur das Zweite überzeugt in einer Priorisierungsrunde.

19:10 Vier Punkte. Automatische Prüfungen decken einen Teil ab — menschliches Urteil bleibt nötig, und das ist keine Meinung, sondern die Position des W3C. Der Accessibility Tree beantwortet die meisten Fragen in dreißig Sekunden; machen Sie den Blick zur Gewohnheit. Die meisten Fehler sitzen in dynamischen Zuständen, nicht auf der geladenen Seite. Und ein Befund ohne Auswirkung und Technikkombination wird abgetan.

19:35 Ein letzter organisatorischer Rat aus der Fußzeile: ein Werkzeug überall statt mehrerer nebeneinander. Als Nächstes verankern wir all das im Entwicklungsprozess — damit es nicht von einzelnen Personen abhängt.