Dass automatisierte Tests nur einen Bruchteil der WCAG-Kriterien abdecken, ist bekannt. Nicht alles lässt sich aktuell ohne ein menschliches Auge zuverlässig prüfen. Aber mit all der KI, die in den letzten Jahren Einzug gehalten hat: haben wir hier eigentlich wesentliche Fortschritte gemacht?
Ich bin über einen großartigen Artikel von Manuel Matuzović gestolpert in dem er 2019 versucht hat, die schlimmste Seite zu bauen, die nur möglich ist – und dabei den perfekten 100%-Lighthouse-Score einzuheimsen. Und beim Lesen habe ich mich immer wieder gefragt: Würde das heute noch genauso funktionieren? Sind die Tests besser geworden und entlarven Manuels irrwitzige Machenschaften?
Das schauen wir uns heute mal an. Macht euch bereit für Kopfschütteln und Facepalms in Dauerschleife. Und wer nicht wissen will, wie die Seite entsteht, der scrollt einfach direkt zu Kapitel 2.
Die perfekte, schlimmste Website
Fangen wir mit der Website selbst an. Ich baue bewusst erst einmal die Website nach, die Manuel 2019 (mit kleineren Updates von 2021) erstellt hat. Bekommen wir damit immer noch unseren Stempel „barrierefrei“ verliehen?
Der Grundaufbau
Wir beginnen mit einer kleinen aber feinen HTML-Seite. Nichts verrücktes, aber ein wenig Text, ein Formular, ein Link. Dabei kann erstmal nicht viel schief gehen.
Nur mit CSS
Nun geht es daran, Barrieren einzubauen. Wir beginnen damit, CSS zur Pflicht zu machen. Wie? Nun, wir fügen ein „hidden“ hinzu und blenden die Inhalte so für alle Nutzer aus. hidden ist praktisch das HTML-Äquivalent zum display:none in CSS. Dann laden wir zusätzliches CSS, das dieses hidden wieder rückgängig macht.
<main>
<div class="show" hidden>
<header>...</header>
...
<footer>...</footer>
</div>
</main>.show {
display:block;
}Mehr darüber, wie man barrierefrei Inhalte ausblenden kann, gibt es übrigens im Artikel aria-hidden oder display: none – Inhalte barrierefrei ausblenden.
Nur mit JavaScript
Nur CSS wird benötigt um die Seite anzuschauen? Das ist zu einfach. Erweitern wir das Ganze doch noch und setzen die Klasse, die die Inhalte wieder einblendet, per JavaScript.
<main>
<div id="container" hidden>
<header>...</header>
...
<footer>...</footer>
</div>
</main>document
.getElementById('container')
.classList.add('show');Optisch hat sich nichts getan, aber jetzt brauchen wir schon 2 unnütze zusätzliche Ressourcen, damit überhaupt etwas zu sehen ist. Das läuft gut.
Bitte keine Screenreader
Nun wollen wir aber mal wirklich Leute ausschließen. Bisher kommt man an den Inhalt ja wirklich noch ran. Fangen wir bei den Nutzern von Screenreadern an, weil diese ja auch sonst genug Alternativen haben (nicht).
Die einfachste Art, Inhalte vor Screenreadern und anderen assistiven Technologien zu verstecken ist das Attribut aria-hidden. Wie bei allen ARIA-Attributen gilt auch hier: in der Barrierefreiheit ist es unheimlich wichtig, kann bei falschem Einsatz aber sehr schaden.
Und genau das haben wir vor, deshalb wird jetzt einfach der gesammte Inhalt mit aria-hidden=“true“ versteckt.
<main>
<div id="container" hidden aria-hidden="true">
<header>...</header>
...
<footer>...</footer>
</div>
</main>In seinem Update von 2021 stelle Manuel fest, dass die Tests hier schon kritischer geworden sind und es bemerken, wenn man interaktive Elemente vor Screenreadern verbirgt. Die Lösung? Nehmen wir doch die Interaktion weg. Alle bisher mit Tab erreichbaren Elemente (also Links und Eingabefelder) bekommen jetzt ein tabindex="-1" und sind so nicht viel mehr als normaler Text.
Mehr zum Thema Screenreader, ARIA-Attribute und tabindex:
- Was ist ein Screenreader?
- ARIA Rollen und Attribute – was sie bringen und was nicht
- Echtzeit-Updates mit ARIA Live Region
- Icon-Buttons richtig beschriften – so werden sie mit aria-label und co. barrierefrei
- Den HTML tabindex richtig einsetzen
Wer braucht schon Farbkontraste
Personen mit starken Sehschwächen haben wir jetzt ausgeschlossen. Aber solche, die die Website sehen können, noch nicht. Das lässt sich zum Glück recht einfach lösen. Schon einmal etwas von Farbkontrasten gehört? Braucht man nicht. Unsichtbarer Text ist der neue Schrei.
Nach einem Update von 2021 (Lighthouse hatte für seine erste Lösung tatsächlich Punkte abgezogen) kam Manuel mit dieser Lösung hier um die Ecke. Nahezu komplett transparenter Text.
#container {
filter: opacity(0.03);
}Das ist schon gut. Aber was, wenn jemand in seinem Browser die Hochkontrastversion einstellt? Die können wir separat abfangen und nutzen als Schriftfarbe einfach direkt die Hintergrundfarbe des Browserfensters.
@media screen and (-ms-high-contrast: active) {
* {
color: window !important;
}
}Du willst mehr über Farben und Kontraste wissen?
- Barrierefreie Farben gibt es nicht
- 3:1, 7:1 – Wie berechnet sich eigentlich der Kontrast zwischen Farben?
- Hochkontrast und Schriftvergrößerung – die Accessibility Toolbar
Reader-Modus? Bloß nicht!
Screenreader: Check.
Ansicht im Browserfenster: Check.
Jetzt kommt Safari aber mit einer eigenen Funktion um die Ecke: dem Reader-Modus. Dabei wird der Text wie in einem Word-Dokument aufbereitet, so dass man ohne Ablenkung durch Farben, Bilder usw. den Text konzentriert lesen kann. Ärgerlicherweise werden dafür eigene Farbschemen verwendet und man interessiert sich nicht für unsere Konfiguration.
Aber auch dafür hat Manuel eine Lösung parat. Die Schriftgröße, bemerkt er, wird nicht geändert. Also tut es ein einfaches:
#container {
font-size: 1px;
}Ohne Maus, ohne Tastatur
Lesbar ist der Text jetzt zwar nicht mehr, bedienbar bleibt die Seite aber. Das kann so in jedem Fall nicht bleiben. Fangen wir damit an, die Nutzer einer Maus auszusperren. Sie könnten auf Links oder Formularelemente zufällig klicken und damit tatsächlich ans Ziel kommen.
Um ihnen das zu ersparen, brauchen wir 2 verschiedene CSS-Befehle
cursor: none entfernt den sichtbaren Mauszeiger sobald er sich über dem Element befindet. Also lassen wir ihn doch einfach auf der ganzen Seite verschwinden.
pointer-events: none sorgt im Anschluss dafür, dass Nutzer (obwohl sie weder sehen können wo sich die Maus befindet noch wo der Text ist) aus Versehen etwas sinnvolles tun. Es sperrt jede Maus-Interaktion mit einem Element. Wir ergänzen also unser CSS ein wenig.
*,
*:hover {
cursor: none;
}
#container {
pointer-events: none;
}Nutzer der Tastatur müssen leider nicht wissen, wo der Text sich befindet. Mit der Tabulator-Taste kommen sie auch blind durch das Formular. Zwar haben wir mit dem Attribut tabindex schon verhindert, dass Elemente per tab erreichbar sind, aber wir gehen auf Nummer sicher. Könnte ja sein, jemand schafft es doch.
Bei der Bedienung wird Tastaturnutzern nämlich auch noch geholfen, indem der Browser eine outline um das fokussierte Element setzt. Etwas, das wir dringend unterbinden müssen.
*:focus {
outline: none !important;
}Um ganz sicher zu gehen, dass hier nichts mit der Tastatur erreicht wird, klauen wir Ihnen auch noch jede weitere Möglichkeit auf eventuelle Shortcuts.
document.addEventListener('keydown', function (e) {
e.preventDefault();
});Quelltext unlesbar
Wir haben jetzt also alle unsere Inhalte für sehende und nicht sehende Nutzer versteckt und die Interaktion sowohl mit der Maus als auch der Tastatur (und damit allen anderen assistiven Eingabegeräten) blockiert. Gute Arbeit. Aber echte Nerds werden sich einfach den Quelltext der Website ansehen. Und unser HTML sieht immernoch so aus wie am Anfang: Wunderbar aufgeräumter und lesbarer Quelltext.
Um die Sache hier nicht zu einfach zu gestalten, verschlüsseln wir nun unsere Texte mit cryptii. Hier ein Beispiel:
Aus
100% barrierefrei* (*fast)
wird 1
Wenn wir das mit allen lesbaren Texten machen, haben wir ein herrlich kryptisches HTML. Wer das lesen kann möge sich bei mir bitte melden. Ein Manko gibt es leider: Die Entwicklertools der Browser übersetzen es zurück in Text und machen den Inhalt so lesbar.
Automatisierte Tests
Nun wollen wir mal sehen, wie barrierefrei unsere Website angeblich ist. Nicht vergessen: diese Website ist für absolut niemanden mehr nutzbar. Sie ist nicht lesbar, hörbar oder bedienbar. Und innerhalb der letzten 5 Jahre sollte sich hier doch einiges getan haben, oder?
Google Lighthouse
Fangen wir an bei dem, was auch Manuel getestet hat. Google Lighthouse, der Test, den man im Google Chrome Browser mitgeliefert bekommt. Für viele ein wichtiges Tool zur Messung der Performance. Aber auch auf Kriterien der Barrierefreiheit kann getestet werden.
Und es zeigt sich: viel hat sich nicht getan. Wir bekommen weiterhin 100 Punkte mit einer unnutzbaren, völlig weißen Seite. Strahlend grün wird uns dokumentiert, dass unsere Seite offenbar sehr gut zugänglich ist. Zwar gelten die meisten Kriterien (auch weil unsere Seite so schön klein ist) als nicht anwendbar, aber Lighthouse bestätigt zumindest einen sehr guten Kontrast und die gute Zugänglichkeit der Schaltflächen durch Screenreader. Beides falsch.
Positiv ist aber immerhin zu bemerken, dass eine Liste an händisch zu prüfenden Kriterien beigelegt wird. Ob die allerdings wirklich bearbeitet wird, wenn das Ergebnis schon vorher 100% beträgt, mag zumindest bezweifelt werden.
Accessibility Checker
Schauen wir uns einmal andere Test-Tools an, schneiden die besser ab? Hat Manuel sich hier nur den einfachsten herausgesucht? Los geht es mit dem Accessibility Checker.
Der wertet die Seite tatsächlich ganz ähnlich, hier reicht es für 95%. Aber nicht etwa, weil irgendein Fehler gefunden wurde. Alle automatisierten Tests wurden bestanden, im wesentlichen die gleichen Prüfungen wie bei Lighthouse. Man ist hier einfach nur etwas vernünftiger in der Vergabe von Prozenten: Die restlichen 5% bekommt man nur mit manuellen Tests.
Das ist gut und macht auf den ersten Blick klar, dass eben doch noch etwas fehlt. Und es kitzelt die Motivation heraus, auf die 100 zu gehen und sich nicht auf den vorhandenen Tests auszuruhen. Trotz alledem bleibt die Tatsache bestehen, dass keine unserer Gemeinheiten gefunden wurde.
WAVE
Den Barrierefreiheitstest WAVE von WebAIM gibt es sowohl als Website als auch Browserplugin mit dem sich auch lokale Seiten in der Entwicklung gut testen lassen.
Beide Versionen geben unserer Seite den bisher schlechtesten Score (9.8 von 10) und haben tatsächlich etwas auszusetzen. Ein Fehler wird uns zwar nicht angekreidet, es erscheinen aber 2 Warnungen:
- Unsere Schriftgröße ist zu klein. Absolut korrekt bei nur 1px Größe. Aber er macht es richtig, das als Warnung auszugeben. Denn obwohl es natürlich falsch ist, eine so kleine Schrift auszugeben, ist die reine Standard-Schriftgröße einer Seite kein Kriterium der WCAG. Nur eine Vergrößerung muss möglich sein.
- WAVE wünscht sich ein <fieldset>-Element um unsere Radio-Buttons. Definitiv ein guter Code-Stil, aber nichts, was mit den Manipulationen auf unserer Testseite zu tun hat. Auch hier zurecht eine Warnung.
Accessibility Insights
Zuguterletzt werfen wir noch den Test von Accessibility Insights auf unser kleines Spaßprojekt. Und ich muss sagen, das Ergebnis allein ihres 3-Punkte-FastPass-Checks gefällt mir, obwohl dabei kaum etwas geprüft wird. Warum? Weil sie Unsicherheit zugeben.
Hier werden nämlich das erste Mal die fehlenden Kontraste bemerkt oder zumindest irgendwie als komisch wahrgenommen. Aber sie werden zur eigenen Überprüfung empfohlen. Das ist gerade bei Kontrasten wertvoll, denn die korrekte Vorder- und Hintergrundfarbe zu bestimmen ist nicht einfach. Diese hängt oft von der Größe des aktuellen Bildschirms ab, ändert sich gerade bei Bildern und Farbverläufen im Hintergrund ständig. Er findet hier also durchaus schwache Kontrast, gibt aber zu, dass er sich auch verrechnet haben könnte und das nicht zwingend ein Fehler sein muss.
Zu einer Punktzahl lassen sie sich garnicht erst hinreisen. So kann auch keine falsche Sicherheit suggeriert werden. Für alle anderen Kriterien wird ein manueller Test empfohlen und das Tool assistiert dabei nur.
Fazit – Kaum Verbesserungen und viel unkritisches Lob
Nun, im Fazit kann man wohl feststellen, dass sich in dem Bereich der automatisierten Testung auf Barrierefreiheit in den letzten Jahren wenig bis garnichts getan hat. Zumindest, was kostenfreie Tools angeht. Das ist schade, denn sie sind sie sind oft ein erster Einstieg für Laien um große Probleme aufzudecken und zu beheben ohne gleich ein teures Audit finanzieren zu müssen.
Problematisch finde ich, dass die ausgegebenen Punktzahlen suggerieren, dass die Barrierefreiheit schon sehr gut ist. Unabhängig davon, wie gut wir die Tests gerade ausgetrickst haben: sie testen eben nur auf einen sehr geringen Bruchteil an Problemen. Oft auch auf Dinge, die nicht WCAG-relevant sind (trotzdem aber durchaus auf einer barrierefreien Website helfen können, das streite ich nicht ab). 100% im Lighthouse-Test sagt aber eben absolut nichts über 100% WCAG-Konformität aus. Und schon erst recht nichts über 100% Barrierefreiheit (die es ohnehin kaum gibt).
Haben Manuel und ich mit unseremTest jetzt aber bewiesen, dass die Tests nutzlos sind? Absolut nicht. Sie wurden mit ziemlich fiesen Methoden aus Spaß an der Sache bewusst ausgetrickst um zu zeigen, dass es geht. Auf realen Websites finden sie durchaus relevante Probleme und können in jedem Fall als schneller Selbsttest genutzt werden um schon vor einem Audit oder während der Entwicklung die gröbsten Probleme zu entdecken und zu beheben. Ein manuelles Audit werden sie aber wohl zeitnah nicht ersetzen.
Hier gibt es den Originalartikel von Manuel Matuzović noch einmal zum Nachlesen (auf Englisch): Building the most inaccessible site possible with a perfect Lighthouse score.