Web-Accessibility-Mythen und -Fails

Web-Accessibility-Mythen und -Fails Beispiele von Websites, Herausforderungen und Lösungsansätze

Hallo und Guten Morgen. Erst Mal vielen Dank, dass ich zum ersten Mal hier zu Besuch im wunderschönen Bern sein darf.

Mein Name ist Manuel Matuzovic. Ich bin Frontend Developer, Berater und Auditor aus Wien und lebe aktuell in Graz. Heute bin ich hier um über Mythen und Fails in der Barrierefreiheit in Web zu sprechen. Ich vermute, dass sich sehr viele von ihnen aktiv mit Barrierefreiheit im Web beschäftigen. Deswegen wissen wie sicher auch, dass es sehr viele Mythen gibt und noch viel mehr Fails. Ich könnte also heute den ganzen Tag hier sitzen und mit würde das Material nicht ausgehen. Meine Zeit ist aber limitiert und deswegen habe ich mir drei Mythen ausgesucht, die mich in der Praxis stark beschäftigen.

matuzo.social accessibility-cookbook.com matuzo.social htmhell.dev matuzo.at manuel@matuzo.at

Der erste Mythos ist “Solange wir alles beschriften, ist alles gut”. Wenn ich von beschriften rede meine ich die Bereitstellung von Textalternativen für Multimedia-Inhalte und die Bezeichnung von semantischen Elementen. Jetzt werden sich ein paar von ihnen denken “Naja, aber Beschriften ist ja grundsätzlich nicht Schlechtes.” Sowieso nicht. Wir haben vor allem auch ein massives Problem mit zu wenig Beschriftung im Web. Dazu gibt es auch Zahlen.

Die NGO WebAim veröffentlicht jährlich einen Report namens “The WebAim Million”. Sie testen die Barrierefreiheit von den Top 1 Million Websites mit dem automatisierten Testing Tool “Wave”, werten die Daten aus und machen eben den Bericht.

https://webaim.org/projects/million

In dem Bericht sagen sie uns beispielsweise, dass sie automatisch erkennbare Fehler auf 95.9% der getesteten Websites gefunden haben.

Sie listen auch die 6 häufigsten Fehler auf. - Mangelhafter Kontrast - Fehlende Bildbeschreibungen - Fehlende Beschriftung von Formularfeldern - Leere Links - Leere Button - Fehlende Auszeichnung der natürlichen Sprache 4 von 6 Fehlern sind auf mangelhafte Beschriftung zurückzuführen. Wir haben da also wirklich Verbesserungsbedarf. Das Problem ist nur, dass es manche von uns zu gut meinen.

https://webaim.org/projects/million/#errors

Nehmen wir zum Beispiel die Schaltfläche, einen Button, in einem Suchformular. Oft kommt diese ohne sichtbaren Text, sondern besteht nur aus einem Button und einem Piktogramm auf dem eine Lupe dargestellt ist. Der Button und das Piktogramm in Kombination mit einem einzelnen Eingabefeld funktionieren für sich stehend so gut, dass die meisten Menschen wissen, was hier zu tun ist und was sie erwarten können. Der Such-Button ist ein erlerntes Muster. Für jene, die einen Screenreader verwenden, muss ich eine Alternative Text-Bezeichnung bereitstellen, zB “Suchen”. Kurz und knackig, auf den Punkt. Das passt.

<button aria-label=”Suchen”> <svg>…</svg> </button>

Manche meinen es aber leider zu gut und sind über engagiert. Oft findet man statt einfach nur “Suchen” Bezeichnungen wie “Um eine Suchanfrage abzusenden, klicken sie bitte auf diese Schaltfläche”.

<button aria-label=”Um eine Suchanfrage abzusenden, klicken Sie bitte auf diese Schaltfläche.”> <svg>…</svg> </button>

Das wäre ca. so als würde man vor einer Tür stehen, wie hier bei einem Restaurant in Graz zu sehen, und anstatt “Ziehen” steht da…

“Um die Türe zu öffnen nehmen sie die Klinke in die Hand, drücken sie hinunter und ziehen”. Mein sieht hier die selbe Tür aber mit eben diesem Satz meisterhaft von mir gephotoshoppt. Das klingt vielleicht nicht schlimm, aber wenn das gesamte Interface so ist, kann es schon sehr mühsam sein, die Website zu bedienen. Außerdem ist sowas sehr fehleranfällig, so wie man auf dem Foto sehen kann, weil es das gar keine Klinke sondern nur einen Griff gibt.

Hier ein weiteres Beispiel, das kürzlich eine blinde Entwickler-Kollegin mit mir geteilt hat. Auf der Website waren einige Links, Buttons, und Bilder zu sehen. Nichts aufregendes. Ein Link mit der Bezeichnung Produkte, einer Team, ein Button mit der Bezeichnung Login, ein Bild mit Beschreibung, etc. Ich habe einen Screenreader gestartet und erwartet, dass ich sowas wie “Produkte, Link”, “Team, Link”, “Login, Button” oder “Gruppenfoto unseres Teams, Bild” hören werde. Also das Standardverhalten bei dem immer die Bezeichnung mit der semantischen Rolle des Elements vorgelesen wird. Bekommen habe ich aber “Link, Link”, “Link, Link”, “Button, Button”, “Bild, Bild”.

<a href=”/produkte”> Produkte </a> <a href=”/team”> Team </a> <button> Login </button> <img src=”team.png” alt=”Gruppenfoto unseres Teams”>

Das Problem ist, dass die Entwickler es zu gut gemeint haben und sich dachten “Na, wie sollen die Screen Reader Nutzer:innen sonst wissen, womit sie es zu tun haben?”. Und somit haben sie jeden Link auf der Website mit Link beschriftet jeden Button mit Button, etc.

<a href=”/produkte” aria-label=”Link”> Produkte </a> <a href=”/team” aria-label=”Link”> Team </a> <button aria-label=”Button”> Login </button> <img src=”team.png” aria-label=”Bild”>

Das ist ca. so als würde man in einen Supermarkt gehen und anstatt der unterschiedlichen Marken und Bezeichnungen steht überall nur drauf, was es ist. Hier ein Foto vom Kaffee Regal in einem Supermarkt in Graz.

Also anstatt Meinl, Jacobs oder Dallmayr Kaffee bekommt man nur Kaffee. Hier dasselbe Bild aus dem Supermarkt nur dass jetzt auf jedem Kaffee einfach nur Kaffee steht

Das passiert leider öfter als man es sich wünschen würde. Ein weiteres noch extremeres Beispiel habe ich, zugegeben, erst einmal gesehen. Wir nehmen wieder unsere Links, den Button und das Bild von vorhin.

<a href=”/produkte”> Produkte </a> <a href=”/team”> Team </a> <button> Login </button> <img src=”team.png” aria-label=”Gruppenfoto unseres Teams”>

Da haben sich die Entwickler gedacht “Unsere Website ist derartig zum vergessen, dass wir den Leuten klarmachen müssen, dass sie uns am besten anrufen, wenn sie was wollen”. Und somit war dann die Bezeichnung jedes Links, jeder Schaltfläche und jedes Bildes “Wenn Sie zusätzliche Hilfe bei der Navigation oder beim Zugriff auf den Inhalt dieser Website benötigen, rufen Sie bitte unseren gebührenfreien Kundendienst unter der Nummer 1-800-666-8654309 an.”.

Das ist ca. so als würden Sie vor einem großen Platz stehen und auf eine Tafel schauen um sich zu orientieren. Doch anstatt der Orte und Gebäude, wie hier am Grazer Hauptplatz,…

…sieht man nur die Info “Wenn Sie zusätzliche Hilfe bei der Navigation oder beim Zugriff auf Gebäude benötigen, rufen Sie bitte unseren gebührenfreien Kundendienst unter der Nummer 1-800-666-8654309 an.” Okay, jetzt aber genug von meinen Photoshop-Künsten. Ich glaube, die Message ist angekommen.

Der zweite Mythos ist “Technologie und AI lösen all unsere Probleme”. Wie schon erwähnt, bin ich Auditor. Ich teste also die Barrierefreiheit von Websites. Das macht man üblicherweise in mehreren Schritten mit unterschiedlichen Werkzeugen. Einer der ersten Schritte ist oft automatisiertes Testing. Man lässt also ein Script über eine Seite laufen, um zu sehen, ob es automatisch erkennbare Fehler gibt. Das ist super, weil man so schnell kritische Fehler finden kann.

Das Ding ist nur, das diese Tools, je nachdem wen man fragt, nur 30-60% der Fehler auf einer Website finden. Den Rest muss man durch manuelles Testing entdecken. Leider hören vielen schon nach dem ersten Schritt auf weil sie denken, dass 0 Fehler oder ein perfekter Score in dem Tool heißt, dass die Seite perfekt und komplett barrierefrei ist.

Dass das so nicht ist, habe ich versucht mit einem Experiment zu beweisen. Ich habe eine einfache Seite in höchstem Grade unzugänglich gemacht ohne dass sich auch nur eines der populären Testing-Tools beschwert hat. Das Experiment habe ich in einem Artikel mit dem Titel “Building the most inaccessible site possible with a perfect Lighthouse score” beschrieben.

https://matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score

Links sieht man das originale Dokument, das aus einer Überschrift, Absätzen, einer Liste und einem einfachen Formular besteht. Dieses Dokument hat 0 Fehler bzw. einen Score von 100. Rechts sieht man dasselbe Dokument, aber der Text ist kaum lesbar. Das Dokument ist nicht mit dem Keyboard, mit der Maus oder dem Screen Reader nutzbar, aber der Score ist immer noch 100. Diese Tools sind super und wichtig, aber es reicht nicht sich nur auf die Technologie zu verlassen. Man muss auch manuell testen mit dem Keyboard, Screen Readern und anderen Werkzeugen. Ein weiteres Beispiel dafür sind Bildbeschreibungen. Viele KI-basierte Tools können Bilder sehr gut beschreiben, man braucht aber Kontext, das den nur ein Mensch liefern kann.

https://codepen.io/matuzo/pen/joeeqy

Hier sieht man beispielsweise ein Schwarz-Weiss Photo, das in den 50-60 Jahren während des Civil Rights Movement in den USA entstanden ist. Es ist ein junger Schwarzer man zu sehen der von einem Polizisten mit einer Hand festgehalten wird. In der anderen Hand hält er eine Hundeleine. Der Hund attackiert den Mann. Daneben steht ein weiterer Mann mit Hund. Im Hintergrund sind weitere schwarze Menschen auf der Strasse zu sehen, die irritiert aussehen. Ich weiß nicht, was da passiert ist. Ich weiß nicht, ob der Polizist den Hund auf dem Mann losgelassen hat oder ob er den Hund zurück hält. Mir fehlt hier Kontext und Hintergrundwissen um ausreichend beschrieben zu können. Meine Beschreibung ist nicht perfekt, aber okay würd ich sagen. MS PowerPoint, das auch ein Bildbeschreibungstool hat, hat das Bild beschrieben mit “Ein Polizist hilft einer person mit einem Hund”. Das passt halt wirklich absolut gar nicht und kann sehr problematisch sein. Zugegeben hat ChatGPT hingegen eine ausgesprochen detaillierte Beschreibung geliefert, aber es konnte mir auch den Namen des Photographen sagen. Es kannte wohl also das Bild. Wichtig ist für uns nur, KI kann uns bei Bildbschreibungen nicht ablösen sondern nur unterstützen, wenn wir gute Beschreibungen wollen.

Ein Polizist hilft einer Person mit einem Hund

Ein Weiteres Beispiel für KI-basierte Tools sind sogenannte Overlays. Widgets, die man auf einer Website einbinden kann, die versprechen die Barrierefreiheit zu verbessern. Zur erkennen sind die an einem Button mit Strichmännchen. Klickt man den Button kann man Kontraste anpassen, Schriftgröße erhöhen, etc. Man kann das Tool auch Dinge automatisch verbessern lassen. Ein Beispiel dafür findet man auf der Website des Österreichischen Paralympischen Committees. Diese Website ist nicht barrierefrei, was sehr überraschend war für mich. Jedenfalls kann man mit der Maus auf den Burger-Button klicken. Dann öffnet sich ein Menü. Die Menüpunkte haben Untermenüpunkte, die aufklappen.

Wenn man dasselbe mit dem Keyboard macht, kickt die KI rein und fügt Skip-Links hinzu, was super ist. Es macht den Button auch zugänglich mit dem Keyboard, was er vorher nicht war, aber aus irgendeinem Grund bekommen sie Submenüs die selbe Hintergrundfarbe wie der Text wenn man das Keyboard verwendet.

Es gibt viele weitere Gründe, warum Overlays keine sehr gute Lösung sind. Untere anderem die schwierige Auffindbarkeit und die Tatsache, das man auf einer Seite die Einstellungsmöglichkeiten hat und auf der nächsten dann wieder nicht oder ein anderes Tool. Solche Einstellungen müssen im Browser oder im Betriebssystem gemacht werden. Zum Schluss kommen wir zum dritten Mythos. Weitere Details liefert meine geschätzte Kollegin Daniela Kubesch in ihrem Vortag “Accessibility Overlays wissenschaftlich beleuchtet”.

https://youtube.com/live/Atc5v64gqdE

“Nur die anderen müssen barrierefreie Websites machen”. Irgendwie gibts es diesen Irrglauben, dass nur jene, die im öffentlichen Sektor arbeiten barrierefreie Websites machen müssen. Das macht überhaupt keinen Sinn. In der Webentwicklung geht es nicht darum, Gesetze zu beachten oder Kriterien zu erfüllen, sondern darum Menschen Zugang zu geben und ihnen zur Erlauben Teil der Gesellschaft zu sein. Und das bedeutet also, dass alle Websites barrierefrei sein müssen ganz unabhängig von irgendwelchen gesetzlichen Regelungen.

Und damit möchte ich mich auch schon verabschieden und mich für die Aufmerksamkeit bedanken und viel Spass mit den weiteren Vorträgen wüschen. Vielen Dank!

accessibility-cookbook.com matuzo.social htmhell.dev matuzo.at manuel@matuzo.at