Blog ·
Barrierefreiheit: eine Ausnahme, die sich misst
Jeder Barrierefreiheitsprüfer endet mit einer Ausnahmeliste. Unsere hält zwei, jede mit einer Messung, und der Lauf scheitert, wenn eine nicht mehr passt.
Von Provibr
Richten Sie einen automatischen Barrierefreiheitsprüfer auf ein echtes Produkt, und Sie bekommen eine Zahl. Beheben Sie alles, was er gefunden hat, und Sie bekommen eine kleinere Zahl. Irgendwo in diesem Ablauf stoßen Sie auf einen Befund, der wirklich kein Defekt ist, und in diesem Moment schreiben Sie Ihre erste Ausnahme.
Das ist der interessante Teil, denn eine Ausnahmeliste ist der Ort, an dem ein Programm für Barrierefreiheit still stirbt. Sie beginnt mit zwei gut begründeten Einträgen. Ein Jahr später sind es elf, von denen drei nichts mehr treffen und einer ein echtes Problem verdeckt, und niemand kann sich erinnern, warum irgendeiner davon dort steht. Der Bericht sagt null und meint nichts.
Wir haben den Prüfer für unser Panel in diesem Monat gebaut. Er meldet in keinem Schweregrad einen Befund, und in diesem Stück geht es vor allem darum, warum wir dieser Zahl für sich allein nicht glauben.
Drei Regeln waren standardmäßig aus, und zwei davon verbargen Befunde
Die Bibliothek, die wir benutzen, liefert einige Regeln standardmäßig deaktiviert aus. Wir haben nachgesehen, welche, indem wir sie gefragt haben statt es anzunehmen: Name und Inhalt stimmen nicht überein, Tabellenzellen ohne Kopfzellen und Zielgröße sind ab Werk alle aus.
Zwei davon haben auf unserem Panel echte Befunde erzeugt, 36 zusammengenommen, darunter die beiden Punkte, die eine frühere Runde offen gelassen hatte. Ein Prüfer, der mit dem voreingestellten Regelsatz läuft, ist damit genau bei den Fehlern grün, nach denen jemand bereits gesucht hatte, und das ist die schlimmste Art von Grün: Es ist nicht von einem Produkt zu unterscheiden, das in Ordnung ist.
Sie werden ausdrücklich eingeschaltet, und diese eine Entscheidung hat die Ausgangsmessung stärker verändert als jede andere Konfigurationswahl.
Neun Sprachen, weil eine Sprache ein Münzwurf ist
Der Sprachumschalter in unserer Kopfleiste zeigt einen Code aus zwei Buchstaben und hat einen barrierefreien Namen, der sagt, welche Sprache es ist. Auf Englisch steht auf der Schaltfläche EN und sie heißt „Language: English“, und die Regel besteht, weil en zufällig in English vorkommt.
Auf Niederländisch scheitert sie. Dieselbe Komponente, derselbe Code, dasselbe Markup.
Über alle neun Sprachen gemessen, die wir ausliefern: Drei scheitern und sechs bestehen, und jede dieser sechs besteht durch Zufall: en in English, de in Deutsch, fr in Français, it in Italiano, es in Español, ro in Română. Hier eine Sprache zu prüfen ist leeres Grün.
Deshalb läuft die Marketingstrecke jede Sprache auf den Regeln, deren Ergebnis von der Sprache abhängen kann. Es kostet Zeit, und es ist der einzige Weg, auf dem dieser Befund überhaupt existiert.
Die Ausgangsmessung und woraus sie bestand
Der erste vollständige Lauf über Marketing, Anmeldung und das angemeldete Panel meldete 3 kritische, 51 schwerwiegende, 72 mittlere und 6 geringe Befunde. Acht Regeln machten alles davon aus.
| Regel | Befunde |
|---|---|
| Inhalt außerhalb eines Landmarks | 60 |
| Name und Inhalt stimmen nicht überein | 33 |
| Farbkontrast | 13 |
| fehlendes Main-Landmark | 9 |
| leerer Tabellenkopf | 6 |
| scrollbarer Bereich nicht fokussierbar | 5 |
| Tabellenzelle ohne Kopfzelle | 3 |
| Überschriftenreihenfolge | 3 |
Fast alles davon war strukturell und nicht visuell. Den Anmeldeseiten und dem Panel fehlten ein main-Element und ein Skip-Link. Die Tabellen der Artikel hatten leere Kopfzellen. Codeblöcke scrollen waagerecht und waren mit der Tastatur nicht erreichbar, was bedeutet, dass ein Tastaturnutzer die rechte Seite eines langen Befehls schlicht nicht lesen kann. Der Statistikreiter setzte eine Diagrammüberschrift unter der Seitenüberschrift auf die falsche Ebene.
Nach den Reparaturen: null, null, null, null. Womit wir wieder bei der Frage sind, was diese Null wert ist.
Zwei Ausnahmen, jede mit einer Messung
Die Ausnahmeliste hat genau zwei Einträge, und jeder von ihnen trägt einen Grund und eine Messung, die tatsächlich vorgenommen wurde.
Farbkontrast bei erzwungenen Farben. Das Panel mit aktiven erzwungenen Farben laufen zu lassen erzeugte 610 Kontrastfehler auf zwölf Seiten. Das ist kein Produktdefekt, sondern ein Zusammenspiel zwischen dem Prüfer und dem Browser. Der Prüfer liest -webkit-text-fill-color vor color, und Chrome erzwingt Ersteres nicht. Auf der Anmeldeseite, an derselben Überschrift, im selben Seitenaufbau:
| Eigenschaft | normal | erzwungene Farben |
|---|---|---|
color | rgb(16, 19, 25) | rgb(255, 255, 255) |
-webkit-text-fill-color | rgb(16, 19, 25) | rgb(16, 19, 25) |
| Seitenhintergrund | rgb(244, 246, 248) | rgb(0, 0, 0) |
Er vergleicht also den vom Autor gesetzten Vordergrund mit dem erzwungenen Hintergrund und meldet 1,12 zu 1, wo der Bildschirm in Wahrheit 21 zu 1 zeigt. In diesem Modus gilt die Kontrastanforderung ohnehin nicht, denn die Palette gehört dem Benutzer.
Die Regel ist in genau diesem einen Modus aus, und der Grund wird bei jedem Lauf neu gemessen. Beheben Chrome oder der Prüfer das, scheitert diese Selbstprüfung, und die Ausnahme muss neu begründet werden. Eine Ausnahme ohne Selbstprüfung ist eine stille Allowlist.
Die Kontoschaltfläche. Die Regel zu Name und Inhalt schlägt auf der Benutzermenü-Schaltfläche im Panel an. Sechs mögliche barrierefreie Namen wurden auf die echte Schaltfläche gesetzt und die Regel gegen jeden einzelnen laufen gelassen. Sie besteht nur, wenn der Name buchstäblich die Zeichenkette DKDemo Klant€0.00 enthält, in der die Initialen und der Kontoname zusammengezogen sind, und sie scheitert mit genau demselben Text mit Abständen als DK Demo Klant €0.00 und mit dem echten Namen. Alle drei Kinder dieser Schaltfläche sind vor assistiver Technik verborgen, was die Regel ignoriert.
Zu bestehen hieße also, dass ein Screenreader DKDemo als ein Wort ansagt. Das ist die schlechtere Schaltfläche, angenommen, um einer Regel zu genügen, die die Bibliothek selbst als experimentell kennzeichnet und deaktiviert ausliefert. Die funktionale Anforderung ist erfüllt: Wer Sprachsteuerung benutzt, sagt „Demo Klant“, und das steht im Namen.
Die Ausnahme, die starb, ohne etwas zu sagen
Das ist der Teil, der den ganzen Artikel wert ist.
Eine Ausnahme muss das Element wiedererkennen, für das sie gilt. Der CSS-Selektor des Prüfers ist dafür nicht stabil genug: Dieselbe Kontoschaltfläche wurde auf der einen Seite so und auf der nächsten anders bezeichnet, also deckt eine Ausnahme, die über den Selektor greift, die eine Seite ab und die andere nicht. Stattdessen greift die Ausnahme über ein Markierungsattribut, das die Komponente selbst setzt, im HTML-Fragment des Elements.
Das Fragment, das der Prüfer meldet, ist bei 140 Zeichen abgeschnitten.
Die barrierefreie Beschriftung der Schaltfläche wuchs, weil das Kontoguthaben hinzukam. Die Markierung rutschte über die Grenze von 140 Zeichen hinaus. Das Fragment endete nun auf ... Credit €0.00." data-us. Die Ausnahme traf nichts mehr, still, und der Lauf meldete 27 schwerwiegende Befunde, die er im Lauf davor abgedeckt hatte.
Nichts an diesem Versagen ist laut. Die Ausnahme warf keinen Fehler, die Liste schrumpfte nicht, keine Konfiguration änderte sich. Eine Änderung an der Oberfläche in einer unbeteiligten Funktion verschob eine Zeichenkette, und ein Stück Sicherheitsinfrastruktur hörte auf zu arbeiten. Die Behebung besteht darin, mit dem ungekürzten öffnenden Tag abzugleichen, das der Prüfer ebenfalls liefert.
Die allgemeine Lehre ist größer als Barrierefreiheit: Alles, was mit abgeschnittenem Text abgeglichen wird, ist ein Wächter, der genau in dem Moment versagt, in dem sich etwas ändert, und das ist der einzige Moment, in dem er gebraucht wurde.
Eine Ausnahme, die nichts trifft, lässt den Lauf scheitern
Jeder Eintrag wird gezählt. Endet ein vollständiger Lauf mit einer Ausnahme, die null Mal getroffen hat, ist der Lauf rot.
Das ist dieselbe Form wie eine Liste von Konstanten anderswo in diesem Code, und aus demselben Grund: Eine Ausnahme, die nichts mehr abdeckt, gehört gelöscht und nicht stehen gelassen. Bleibt sie stehen, ist sie eine weitere Zeile, über die die nächste Person nachdenken muss, und irgendwann wird sie gar nicht mehr gelesen.
Das Zählen gilt nur für einen vollständigen Lauf. Beschränken Sie den Lauf auf eine Strecke oder einen Modus, dann bedeutet „nicht getroffen“ nichts.
Eine Null als echte Null nachweisen
Die Zielgröße, also die Anforderung, dass ein Bedienelement mindestens 24 mal 24 Pixel misst, ist eine der drei Regeln, die die Bibliothek deaktiviert ausliefert. Wir haben sie eingeschaltet und daneben eine zweite eigene Messung geschrieben, denn die beiden Ausnahmen, die der Standard selbst zugesteht, müssen gemessen und nicht angenommen werden. Der abschließende Lauf untersuchte 2056 Ziele. 155 lagen unter der Größe. 70 davon fielen unter die Inline-Ausnahme des Standards, das Ziel sitzt also in einem Satz, und 85 unter die Abstandsausnahme, ein Kreis von 24 Pixeln um das Ziel berührt also nichts anderes. Übrig blieb null.
Eine Null aus einer Sonde, die Sie selbst geschrieben haben, ist nicht von einer Sonde zu unterscheiden, die überhaupt nichts melden kann. Deshalb injiziert ein getrenntes Skript auf einer echten Seite eine Schaltfläche von 16 mal 16 Pixeln neben einen Nachbarn und lässt denselben Sondentext darüber laufen, aus der Quelldatei gelesen statt kopiert. Es geht von 0 auf 1 und benennt das Element. Der Meldeweg funktioniert, also ist die Null ein Ergebnis und kein Schweigen.
Beide Ausnahmen des Standards werden gemessen und nicht geraten. Inline heißt, dass der berechnete Wert für die Anzeige genau inline ist und der nächste Block-Vorfahre außerdem anderen Text enthält, und das ist es, was „sitzt in einem Satz“ tatsächlich bedeutet. Das ist keine Liste von Klassennamen. Und die Abstandsprüfung misst den Kreis gegen die Rechtecke der anderen Ziele statt gegen deren Kreise, was strenger ist als der Standard: Sie kann ein falsches Rot erzeugen, nie ein falsches Grün.
Was eine Maschine nicht kann
Es gibt ein kurzes Handbuch mit vier Toren, die einen Menschen brauchen, denn sie sind das, was kein Prüfer erreicht: ob die Lesereihenfolge Sinn ergibt und eine Ansage tatsächlich ankommt, ob eine Strecke allein mit der Tastatur machbar ist statt nur erreichbar, ob das Layout bei 200 Prozent lesbar bleibt statt nur zu passen, und ob der Bildschirm in der eigenen Palette des Benutzers noch etwas bedeutet.
Diese vier sind offen. Das zu sagen gehört zum Punkt: Ein Bericht, der null sagt und nicht sagt, was er sich nicht angesehen hat, ist dasselbe Versagen wie eine Ausnahme ohne Messung.
Was wir aufschreiben würden
- Fragen Sie die Bibliothek, welche Regeln aus sind, nehmen Sie es nicht an. Bei den deaktivierten lagen unsere Befunde.
- Lassen Sie jede Sprache laufen, die Sie ausliefern, auf jeder Regel, deren Ergebnis vom Text abhängen kann.
- Geben Sie jeder Ausnahme einen Grund und eine Messung, aufgeschrieben dort, wo die Ausnahme steht.
- Lassen Sie eine Ausnahme, die nichts trifft, den Lauf scheitern.
- Gleichen Sie einen Wächter nie mit abgeschnittenem Text ab.
- Weisen Sie Ihre Nullen nach, indem Sie etwas injizieren, das gefunden werden müsste.
- Veröffentlichen Sie, was eine Maschine nicht prüfen kann, damit die Zahl als das gelesen wird, was sie ist.
Derselbe Instinkt, angewendet auf Übersetzungen statt auf Markup, steht in sechzehntausend Schlüssel in neun Sprachen.
Aus der Panel-Arbeit bei Provibr.