Interview mit Marco Zehe über den Accessibility Inspector

Mozillas Accessibility Inspector: „Barrierefreiheit ist ein Prozess, kein Zustand“
Keine Kommentare

Barrierefreiheit im Internet ist ein wachsendes Thema, das bei der Erstellung von Webseiten leider immer noch oft vernachlässigt wird. Ein Tool, das diesem Problem Abhilfe verschaffen möchte, ist der Accessibility Inspector in den Firefox DevTools. Wir haben mit Marco Zehe von Mozilla über die Software und Barrierefreiheit im Internet gesprochen.

Der Inspektor für Barrierefreiheit (engl. Accessibility Inspector) ist seit 2018 Teil der Firefox DevTools. Er soll dabei helfen, Web-Angebote für alle Nutzer, unabhängig von ihren Einschränkungen, zugänglich zu machen. Darüber hinaus kann das Tool Entwicklern eine Hilfestellung bei häufig vorkommenden Problemen hinsichtlich Design und Darstellung geben. Wir haben mit Marco Zehe, Senior Accessibility Platform Manager bei Mozilla, über das Projekt selbst und die aktuelle Situation der Barrierefreiheit im Internet gesprochen.

Entwickler: Der Inspektor für Barrierefreiheit wird ab Firefox 70 standardmäßig in den DevTools verfügbar sein. Was genau kann der Inspektor leisten und wie hilft er Menschen mit Sehbehinderungen bei der Überwachung und Überprüfung von Webseiten?

Quelle: Marco Zehe

Marco Zehe: Der Inspektor für Barrierefreiheit hilft auf vielfältige Weise verschiedenen Benutzergruppen. Zum einen können Web-Entwickler ihn nutzen, um ihre Arbeit auf häufig vorkommende Probleme zu überprüfen. Hierzu gehören schwache Farbkontraste von Text zum Hintergrund, die fehlende Beschriftung von Grafiken, Buttons, Formularfeldern und Ähnliches. Aber auch Probleme, die bei der Tastatur-basierten Nutzung einer Seite entstehen können, besonders im Zusammenspiel mit der damit auch zwingend notwendigen Sichtbarkeit des Tastaturfokus. Für all diese Problemfelder bietet der Inspektor eine Überprüfung mit Verlinkungen zum Mozilla Developer Network an, wo Entwickler Erklärung und vor allem auch Lösungen für Probleme finden können.

Der Inspektor kann die Ansicht einer Webseite für Menschen mit Farbfehlsichtigkeiten simulieren. Ein Web-Entwickler oder Designer kann mit deren Hilfe abschätzen, ob eine Person mit einer Rot-Grün-Farbsehschwäche immer noch alle kommunizierten Informationen erfassen kann.

Der Inspektor selbst ist ebenfalls barrierefrei, so dass auch Menschen mit verschiedenen Einschränkungen ihn nutzen können, um gezielt Probleme an den Seitenbetreiber melden zu können. Der Umstand, dass beide dieselben Tools zur Überprüfung der Probleme nutzen, erleichtert die Kommunikation erheblich.

Entwickler: Du arbeitest seit 2007 bei Mozilla, was war deine Rolle bei der Entwicklung des Inspektors?

Zehe: Ich habe den Inspektor von seiner Designphase über die Implementierung bis zur Qualitätsnachsorge nach den ersten Releases begleitet. Mein Input bestand zum einen im Formulieren von Wünschen, was ich mir selbst als Blinder von so einem Tool erhoffe. Zum anderen testete ich, was die Entwickler implementiert hatten und erstellte Fehlerberichte, Verbesserungsvorschläge, etc. Außerdem habe ich ihn bei mehreren Gelegenheiten demonstrieren können, so z. B. auf dem Web-Kongress Erlangen 2018, einem WebWorker-Treffen Nordrhein-Westfalen im August 2018 und einem Accessibility Community Meetup in Toronto in Kanada im März 2018.

Entwickler: Wo siehst du die Vorteile des Barrierefreiheits-Inspektors von Mozilla gegenüber ähnlichen Tools, wie etwa aViewer?

Zehe: Man muss keine weiteren Tools oder Erweiterungen installieren.

Der Vorteil ist, dass der Inspektor gleich beim Installieren von Firefox startklar ist.

Er ist außerdem vollständiger Bestandteil der Entwickler-Toolbox und hat somit Zugriff auf alle Ressourcen, die z. B. auch der HTML-Inspektor mit seinen verschiedenen CSS-Ansichten nutzt. Man kann auch sehr einfach zwischen dem Barrierefreiheits- und HTML-Inspektor hin und her springen. Findet man z. B. ein Problem mit Farbkontrasten im Barrierefreiheitsinspektor, kann man vom betroffenen Accessibility-Objekt direkt zum zugehörigen HTML-Element springen, sich die zugehörigen CSS-Regeln anzeigen lassen usw. Mehr noch, man kann direkt Änderungen vornehmen, zurückspringen und überprüfen, ob diese Änderung das Problem behoben hat. Ist dies der Fall, kann die Änderung in den tatsächlichen Code übernommen werden.

Auch die Vielzahl der bekannten Probleme sowie die zielorientierte Dokumentation zur deren Lösung ist ein Alleinstellungsmerkmal. Der Inspektor sagt eben nicht nur, dass da ein Problem gefunden wurde, sondern bietet durch die Dokumentation auf MDN auch direkt praxisnahe Lösungsansätze mit Codebeispielen.

Entwickler: Wie schätzt du die allgemeine Lage der Barrierefreiheit im Internet ein? Braucht es noch mehr Engagement und Tools, um sehbehinderten Menschen Zugang und Nutzen von Online-Angeboten zu erleichtern?

Zehe: Ein kluger Mensch in der Barrierefreiheitsgemeinde prägte irgendwann mal den Satz, dass Barrierefreiheit ein Prozess ist, kein Zustand. Und das trifft auf das Web im Besonderen zu, denn es gibt fast jeden Tag neue Ideen und Vorschläge zur Verbesserung. Es gibt Standards-Gruppen, die diese dann auf eine mögliche Umsetzung überprüfen. Und es gibt alle paar Wochen neue Ideen für Frameworks, meist in JavaScript, welche den Entwicklern die Arbeit an immer komplexer werdenden Projekten erleichtern sollen.

Leider haben gerade diese JS-Frameworks oft das Problem, dass sie nicht mit semantisch korrektem und somit barrierefreiem HTML arbeiten. Sie verwenden stattdessen generische Elemente, die zwar wunderbar auf Mausinteraktion reagieren, aber auf sonst nichts. Das schließt nicht nur Blinde mit Screen Readern aus, sondern auch Leute, die, aus welchen Gründen auch immer, keine Maus verwenden können und auf eine Tastaturbenutzbarkeit angewiesen sind. Wieder andere müssen Webseiten mit Schaltersteuerung oder durch die Bewegung der Augen bedienen können. All dies funktioniert nur, wenn sich Webseiten und Applikationen an die Standards halten und es somit den Browsern ermöglichen, diese Funktionalität auch zur Verfügung zu stellen.

Eine ganze Zeit lang bestanden die größten Hindernisse im Web aus Flash-Inhalten und Java-Applets.

Seit diese auf dem Rückzug sind, wird das Web als zugänglicher empfunden. Die aus jeder Ecke des Web kommenden JavaScript-Frameworks schmälern dieses Empfinden jedoch immer wieder, weil sie eben die Standards der Barrierefreiheit nicht einhalten. Man muss viel nacharbeiten, um darauf basierende Applikationen zumindest halbwegs nutzen zu können. Und dann muss man hoffen, dass mit der nächsten Version diese Arbeit nicht wieder durch ein Redesign zunichte gemacht wurde. Die Aussage, dass das Web zwischendurch als zugänglicher empfunden wurde, dieses Empfinden aber seit zwei, drei Jahren wieder rückläufig ist, lässt sich auch gut aus den verschiedenen Ausgaben des WebAIM Screen Reader User Surveys ablesen. Das WebAIM-Projekt stellt diese und andere Fragen ca. alle 18 Monate.

Es gibt also noch sehr viel zu tun. Trotz der Tatsache, dass ab ca. 2030 jeder zweite in Deutschland lebende Mensch 60 Jahre oder älter sein wird, werden an Schulen und Universitäten die Grundsätze von inklusivem Design immer noch nicht konsequent gelehrt. Junge Webdesigner und -entwickler designen oder programmieren ihre Anwendungen immer noch primär für Mausbenutzer und schließen so ca. 20% der Bevölkerung, die irgendeine Form von Behinderung haben, aus. Durch immer mehr Senioren im Netz wird die Zahl derer, die mit einem Design von Jungen für Junge Probleme haben, in den nächsten Jahren noch viel größer werden. Hier muss ein Umdenken stattfinden. Denn es sind tatsächlich zahlungskräftige Kunden, die hier auf der Strecke bleiben. Insofern reicht auch die jetzt verabschiedete EU-Richtlinie nicht aus, die besagt, dass bis September 2020 alle Webseiten öffentlicher Stellen barrierefrei sein müssen. Es wäre eigentlich nötig, dies auf alle Unternehmen, die irgendeine Art von Kundenverkehr haben, zu erweitern. Und an den Universitäten muss endlich angefangen werden, von Anfang an inklusiv zu denken und zu lehren.

Entwickler: Der Inspektor für Barrierefreiheit wurde bereits 2018 veröffentlicht. Wie beurteilst du die Entwicklung des Tools und was kann für die Zukunft erwartet werden?

Zehe: Die Entwicklung des Tools beurteile ich als sehr positiv. Am Anfang war er lediglich ein Anzeigewerkzeug für den ganzen Barrierefreiheitsbaum, aus dem Screen Reader und andere Hilfsmittel ihre Infos beziehen. Das half aber niemandem wirklich weiter. Durch das Hinzufügen der Überprüfung auf Kontraste, fehlende Beschriftungen, Tastaturbenutzbarkeit und fokussierbare Elemente, sowie die Simulation von Farbfehlsichtigkeiten, ergeben die Informationen erst richtig Sinn. Für die Zukunft haben wir noch ein paar weitere Ideen. So ist ein häufiges Problem eine falsche Überschriftenstruktur. Auch das ist ein relativ einfach prüfbares Szenario. Und wenn jemand aus der Entwicklergemeinde Ideen hat, was sie gerne im Inspektor sehen möchten, kann uns das immer gern per Feedback mitgeteilt werden. Dasselbe gilt natürlich auch für auftretende Probleme, wenn z. B. die Überprüfung auf interaktive Elemente anmerkt, dass keine Fokusanzeige vorliegen würde, dies aber der Fall ist. Es wird immer Szenarien geben, in denen Tools sich irren. Aber mit Beispielen können sie auch weiter dazulernen und verbessert werden.

Entwickler: Vielen Dank für dieses Interview!

Im Interview: Marco Zehe
Marco Zehe arbeitet seit 2007 bei Mozilla im Bereich Barrierefreiheit. Er testet die Mozilla-Produkte auf Zugänglichkeit für Menschen mit Behinderungen, berät Entwickler bei der Umsetzung von Funktionen für die Barrierefreiheit und ist auch als Konferenzvortragender für diese Themen unterwegs. Früher arbeitete er bei einem großen Hersteller von Hilfsmitteln für Blinde und sammelte dort Erfahrungen im Entwickeln von Screen Readern.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -