Accessibility in der Praxis

Ein Screenreader ist eine assistive Technologie für blinde und sehbehinderte Personen, mit dem Bildschirminhalte per Sprachausgabe und/oder Braillezeile wiedergegeben werden. Die Schriftgröße können Nutzende in ihren Geräteeinstellungen anpassen und sollte nach den Web Content Accessibility Guidelines (WCAG) auf bis zu 200% vergrößert werden können.

Um Hürden zu beseitigen und Home Connect für blinde und seheingeschränkte User:innen nutzbar zu machen, starteten wir mit einer Analyse der App auf Basis der WCAG mit Fokus auf jene Kriterien, die sich auf seheingeschränkte Nutzende beziehen. Da die App noch nicht auf die Anpassung der Schriftgröße reagierte, definierten wir für die wichtigsten Komponenten das responsive Verhalten bei wachsender Schrift, sodass keine Texte abgeschnitten oder überlagert werden. Dies haben wir unter anderem erreicht, indem wir auf feste Höhen von Komponenten wie Buttons verzichten und sie flexibel je nach Schriftgröße wachsen lassen. Durch das Ausblenden von dekorativen Elementen bei größeren Textgrößen konnte außerdem Platz für den Text gewonnen und so die Lesbarkeit verbessert werden. Diese Verbesserungen wurden dann in einem umfangreichen Refactoring von den Softwareentwickler:innen umgesetzt.

Eine deutlich komplexere Thematik ist die Nutzung von Screenreadern, mit der sich die Interaktion mit dem Smartphone gänzlich verändert. Durch externe Audits und UX-Tests mit blinden User:innen konnten wir als nicht-blinde Designer:innen die Interaktionen und Anforderungen besser verstehen. In enger Zusammenarbeit mit den Softwareentwickler:innen erstellten wir erste Spezifikationen in Figma, die das angestrebte Screenreader-Verhalten beschreiben. Hierzu wurde für jedes Element eine Rolle (Typ des Elements, z.B. Button) und ein Label (z.B. der konkrete Button-Text) definiert. Auch die Reihenfolge, in der die Elemente vom Screenreader angesteuert werden, wurde für jeden Screen festgelegt. Da wir für iOS, Android und Web entwickeln und bestimmte Attribute auf den verschiedenen Plattformen teils unterschiedlich benannt werden, mussten auch diese Unterschiede in der Spezifikation abgebildet werden. Während ein Slider beispielsweise im Web auch so genannt wird, ist auf iOS „Adjustable“ die passende Rolle. Um den Dokumentationsaufwand möglichst gering zu halten, spezifizierten wir das Verhalten jeweils nur für iOS und definierten an anderer Stelle, wie dies für die anderen Plattformen zu übersetzen ist.

Um die Unterstützung von Textvergrößerung und Screenreader nicht nur für bestehende sondern auch für neue Features zu gewährleisten, wurde die Implementierung der Barrierefreiheit als festes Akzeptanzkriterium eines jeden Feature-Ticket festgelegt. Sowohl für Designer:innen als auch Entwickler:innen und Tester:innen hieß das, sich während der Umsetzung neues Wissen zum Thema digitale Barrierefreiheit anzueignen. Um alle Beteiligten dabei zu unterstützen, haben wir einen umfangreichen Guide erstellt, in dem die WCAG in verständlicher und projektspezifischer Form aufbereitet sind.

Wir arbeiten kontinuierlich weiter an der Verbesserung der Barrierefreiheit, indem wir beispielsweise die Screenreader-UX vereinfachen. Anhand der aktuellen App Store Reviews zum Thema Screenreader lässt sich jedoch sehen, dass unsere Bemühungen bereits Früchte tragen.