Google I/O: Barrierefreiheit ist Optimierung für Suchmaschinen

Barrierefreie Interfaces eröffnen nicht nur neue Zielgruppen. Sie erleichtern auch Suchmaschinen die Indexierung. Auf der I/O gaben Google-Experten Ratschläge.

In Pocket speichern vorlesen Druckansicht 26 Kommentare lesen
Zwei Frauen unscharf

(Bild: Daniel AJ Sokolov)

Lesezeit: 4 Min.
Inhaltsverzeichnis

UX-Expertin Astrid Weber zeigt einen externen Schalter.

(Bild: Daniel AJ Sokolov)

Für mehr als 400 Millionen Personen ist eine Variante von Englisch Muttersprache. Aber über 600 Millionen Menschen sind farbenblind, Tendenz steigend. Dazu kommen weitere 400 Millionen mit anderen Einschränkungen. Zu oft werden sie bei der Entwicklung von IT-Anwendungen ignoriert. "Das Problem ist, dass die Entwickler oft selbst keine Schwierigkeiten haben", sagte Astrid Weber von Google Research auf der Google I/O, "Daher kennen sie die Anforderungen nicht. Zum Beispiel kann ein User Farben anders wahrnehmen, als Sie."

Google möchte Entwickler mit Werkzeugen und Ratschlägen unterstützen. Barrierefreiheit darf demnach nicht als Zusatz verstanden werden, der am Ende eines Entwicklungsprozesses für Behinderte aufgepfropft wird. Sie soll vielmehr von Beginn an mitgedacht werden, um dem Endprodukt die größtmögliche Reichweite zu verschaffen.

Und gute Nutzbarkeit kann auch die Platzierung in Suchergebnissen verbessern: "Barrierefreiheit hilft bei der Bereitstellung von Metadaten und es gibt damit mehr indexierbare Inhalte", sagte Googler Vitaly Tsaran im Gespräch mit heise online, "Barrierefreiheit ist SEO." (Search Engine Optimization, Optimierung für Suchmaschinen.)

Zur berühmten PageRank-Formel des eigenen Arbeitgebers äußerte sich Tsaran nicht. In der Vergangenheit ist durchgesickert, dass Google zumindest damit experimentiert hat, nicht barrierefreie Webseiten ein bisschen abzuwerten.

Google I/O 2015

Weber ist Expertin für User Interfaces. Gemeinsam mit ihrer Kollegin Jennifer Devins gab sie auf der Google I/O Tipps, die sich Entwickler auch unabhängig vom Thema Barrierefreiheit zu Herzen nehmen dürfen. Programmierer und Designer sollten nicht bloß einen bestimmten Typ von User im Auge haben, meinte Weber, sondern drei oder vier verschiedene.

Personen zu finden und zu befragen zahle sich aus: "Welche Ansprüche haben sie? Welche Techniken nutzen sie, um Barrieren zu überwinden?" Dabei helfe es enorm, wenn die Entwickler die Geräte ihrer Nutzer zumindest ein bisschen kennenlernten. Das sind etwa Braille-Displays für Blinde, externe Schalter für User mit motorischen Einschränkungen und Screenreader-Programme.

Danach kann die "Reise" des Benutzers durch die geplante Anwendung festgelegt werden. In welcher Reihenfolge werden welche Funktionen genutzt? Während der Programmierung helfen heuristische Analysen. Mit ihrer Hilfe kann man beispielsweise sicherstellen, dass alle Bilder und Knöpfe eine Textbeschreibung haben und fokussierbar sind, sowie dass alle kritischen Elemente vergrößert werden können.

Speziell für Android-Apps hat Googles Forschungsabteilung Google Research im Dezember das Accessibility Test Framework for Android als Open-Source-Library veröffentlicht. Seit Kurzem liegt Version 2 vor. Die ursprüngliche Variante ist in der Testumgebung Robolectric (ab 3.0) integriert, in Espresso (ab 2.2) ist schon die neue Version dieses speziellen Testing-Frameworks enthalten.

Wie wichtig gute Dokumentation ist, sollte man Entwicklern nicht erklären müssen. Geht es um User Interfaces, rät Weber auch Fotos, Screenshots und Videos zu machen und aufzuheben: "Dann können andere Leute, die an Ihrer App arbeiten, verstehen, was Sie gemacht haben und warum."

Mit dem Zimmermann Low Vision Simulation Kit kann man diverse Sichteinschränkungen simulieren. Braille-Display und externer Schalter sind separat erhältlich.

(Bild: Daniel AJ Sokolov)

"Beginnen Sie die Tests mit echten Usern erst, wenn Sie schon Ahnung von der Barrierefreiheit ihres Produkts haben", erinnerte Devins. Wer zu früh beginnt, laufe besondere Gefahr, dass ein einzelner Bug den Test frühzeitig stoppt. So etwas frustriert nicht zuletzt die Tester. Außerdem könne ein ungeduldiger Entwickler in die Situation geraten, dass er nicht verstehe, was sein Tester treibe. Dann bleibt der Lerneffekt wohl aus.

"Wenn Sie keine Testnutzer mit Behinderungen auftreiben können, simulieren Sie deren Erfahrungen", fügte Devins hinzu: Verbundene Augen lassen einen Tester vorübergehend erblinden, ein stark gedimmter Bildschirm reduziert Kontraste, Handschuhe erschweren die feinmotorische Steuerung. Außerdem gibt es Brillen mit wechselbaren Linsen, sodass man verschiedene Sichtverzerrungen ausprobieren kann. (ds)