Direkt zum Inhalt
UX und Barrierefreiheit

Einblicke in eine inspirierende Zusammenarbeit

Unser Kollege Dominik Hertlein aus dem UX-Team arbeitet seit einigen Monaten mit einem Kollegen zusammen, der bereits blind mit leichter Lichtwahrnehmung auf die Welt kam. In unserem neuesten Blogbeitrag teilt Simon mit uns Erfahrungen und Einblicke aus seinem Arbeitsalltag als blinder Softwareentwickler.

Braillezeile

Nach dem Behindertengleichstellungsgesetz (BGG) spricht man von Barrierefreiheit, wenn Menschen mit und ohne Behinderung eine von Menschen gestaltete Umwelt gleichermaßen nutzen können. In der heutigen Zeit wird das Thema Inklusion und damit verbunden auch die Barrierefreiheit immer wichtiger, um Menschen mit Behinderung einen gleichwertigen Zugang zum Leben zu ermöglichen wie Menschen ohne Behinderung. 

Für unseren Kollegen Dominik ist das Thema Barrierefreiheit ein präsentes Thema, denn er arbeitet seit einer Weile mit Simon Bienlein zusammen. Simon ist Softwareentwickler und von Geburt an blind mit leichter Lichtwahrnehmung. Im Interview erzählt er uns, wie er seinen Berufsalltag bestreitet und welche Herausforderungen sich ihm dabei stellen.

Simon Bienlein / Barrierefreiheit


Hallo Simon. Schön, dass Du Dir die Zeit genommen hast, uns ein wenig über Deinen Berufsalltag zu berichten. Wieso hast Du Dich denn für den Job als Softwareentwickler entschieden und welche Herausforderungen begleiten Dich, bzw. erwarten dich vielleicht nach wie vor?

Ich bin ein Kind der 80er und so hielt neben anderen Erscheinungen der damaligen Zeit natürlich auch das Internet Mitte der 90er-Jahre in unseren Haushalt Einzug. Schon damals hat mich interessiert, wie Internetseiten funktionieren und wie diese aufgebaut sind, bzw. wie sie dargestellt werden. Und im nächsten Schritt interessierte mich natürlich auch, wie man Webseiten so erstellen kann, dass auch blinde Computernutzer Spaß im Umgang damit verspüren können.

Bereits in den Sommerschulferien begann ich mich mit der Programmierung von Webseiten zu beschäftigen, um zu den Hintergründen und Zusammenhängen durchdringen zu können. Während meiner Ausbildung zum Informatikkaufmann im Bildungszentrum für Blinde und Sehbehinderte und auch im weiteren Verlauf während meines Praktikums bei einem Internetprovider konnte ich Erfahrungen im Umgang mit den Web Content Accessibility Guidelines (WCAG) sammeln, meine Erkenntnisse vertiefen und natürlich auch Teammitglieder für das Thema sensibilisieren.

Bereits zu diesem frühen Zeitpunkt in der Geschichte des Internets und der Webseiten wurde mir dadurch klar, dass es bezüglich der Zugänglichkeit eine große Bandbreite zwischen guten und schlechten Umsetzungen gab. Die Herausforderung bestand also in der Schlussfolgerung, welche Aspekte die guten von den schlechten Realisierungen unterscheiden.

Früher waren Internetseiten sehr statisch, wenig dynamisiert und nicht auf für die Darstellung auf unterschiedlichen Endgeräten ausgelegt. In den heutigen, modernen Systemen wird der Fokus wesentlich stärker auf dynamische Multimediainhalte und optimierte Darstellungen auf sämtlichen möglichen Ausgabegeräten gelegt. Dadurch wurden auch die Anforderungen an die Zugänglichkeit moderner Systeme komplexer und vielschichtiger. Die Einhaltung dieser Anforderungen ist eine wesentliche Herausforderung meines Jobs und mittlerweile auch zu einer persönlichen Mission für mich geworden – alle Nutzergruppen sollen die bestmögliche Erfahrung in ihrem (digitalen) Alltag erfahren.

Dieser Herausforderung gehe ich auch aktuell in meiner Arbeit bei einer Bundesbehörde nach. Über meine aktuelle Tätigkeit bin ich auch mit dem Kollegen Dominik Hertlein von ASTRUM IT in Kontakt gekommen. Ausgehend von unserer Zusammenarbeit in diesem Kontext konnten wir zuletzt auch einen ersten Aibility Workshop als Kickoff beim UX-Team von ASTRUM IT durchführen, um ein breiteres Bewusstsein für das Thema inklusives Design zu schaffen.

Wie kann man sich denn Deinen Arbeitsalltag vorstellen?

Die Anforderungen an die Benutzeroberfläche werden in enger Abstimmung mit den Experten für die gesetzlichen Anforderungen und dem UX-Team festgelegt. Dabei bin ich ein Teil der Schnittstelle zwischen technischer Machbarkeit und spezifischen Nutzungsanforderungen der Fachanwender. Die Software betrachte ich aus zwei unterschiedlichen Perspektiven: Einerseits als Nutzer, der auf besondere technische Anforderungen angewiesen ist und andererseits als Entwickler, der genau diese Anforderungen versteht und natürlich auch umsetzen kann.

Im Mittelpunkt meiner Arbeit steht die Signalkette aus Betriebssystem, Internet-Browser und Screenreader. Der Screenreader fungiert dabei als Ausgabesystem der Benutzeroberfläche via Audiospur, Brailleschrift oder stark vergrößerten Darstellungsformen – sprich: Der Screenreader ersetzt für blinde und sehbehinderte Anwender den Bildschirm als zentrales Ausgabeelement.

Natürlich beschränkt sich die Signalkette dabei nicht nur auf die spezialisierten Werkzeuge der Blinden und Sehbehinderten. So gibt es beispielsweise für motorisch eingeschränkte Anwender auch spezielle Tastaturen oder adaptierte Zeigegeräte. Sämtliche Assistenzsysteme bieten dann eine zugängliche Nutzungserfahrung, wenn die damit aus- bzw. wiedergegebenen Anwendungen bzw. Websites die notwendigen, semantischen Grundlagen erfüllen, zum Beispiel durch die Verwendung von korrekten HTML-Standards in der Webprogrammierung. Sind diese Grundlagen erfüllt, können die Assistenzsysteme digitale Inhalte so interpretieren, dass für alle Nutzergruppen eine in einem hohen Maße barrierefreie Benutzung ermöglicht wird.

In meinem gegenwärtigen Arbeitsalltag unterstütze ich das Projektteam unter anderem durch das entwicklungsbegleitende Reviewen, verschiedene Qualitätssicherungstätigkeiten, die Erstellung sowie das Reviewen von Pull Requests, das Einarbeiten von Änderungen am HTML-Code oder auch das Koordinieren interner und externer Barrierefreiheitsaudits.

Wie ist die Zusammenarbeit mit den Kolleg*innen, wie klappt das denn?

Gerne umschreibe ich meine Zusammenarbeitserfahrung mit dem folgenden, pointierten Satz: „Kopierte Fehlermeldungstexte sind leichtere Kost als angehängte Screenshots.“

Klar ist nämlich: Die Integration in einen Entwicklerpool kann nie reibungslos ablaufen. Auch die Gegenseite muss sich daran gewöhnen, dass für die Kollaboration notwendige Informationen für blinde Teammitglieder in zugänglichen Formaten bereitgestellt werden müssen. Und, um beim Beispiel zu bleiben, dabei ist eben ein Screenshot einer Fehlermeldung keine geeignete Wahl😊

Es ist also weniger eine Frage der Zusammenarbeit, sondern eher eine Frage der dabei eingesetzten Werkzeuge. Hält man sich vor Augen, mit welchen gängigen Tools insbesondere seit der Umstellung auf das verteilte Arbeiten gearbeitet wird, wird deutlich, wie wichtig das präzise Formulieren von Inhalten in Zeiten von stark visuell geprägten Tools wie Screensharings oder Collaboration Boards ist. Als Beispiel: „Auf den blauen Button am rechten Rand klicken“ ist für mich eine abstrakte Beschreibung, der ich aufgrund der abweichenden Darstellung nicht folgen kann – hilfreicher wäre es, die zugrundeliegende Funktion zu beschreiben oder den angezeigten Text bzw. Tooltip zu benennen.

Was machst Du anders in Deinem Daily Business als Sehende?

Ich gehe nicht anders vor als Sehende. Auch hier ist es eine Frage der Werkzeuge: Der Erledigung einiger Aufgaben gehe ich lieber mit dem Linux-Werkzeugkasten, insbesondere der Konsole, nach als mit anderen, UI-lastigen Lösungen.

Ansonsten arbeite ich mit den exakt gleichen Inhalten und an vielen Stellen auch gleichen Werkzeugen, nur die Form der Darstellung und der Interaktion mit dem System ist abweichend.

Erzähle uns doch mal, wie dein Arbeitsplatz aussieht. Welche Hilfsmittel benutzt/benötigst Du, um arbeiten zu können.

Mein Arbeitsplatz umfasst die folgenden Geräte:

  • Eine 80-stellige Braillezeile.
    Dient der taktilen Ausgabe von kleinen Bildschirmausschnitten in Brailleschrift (Blindenschrift), gibt es auch als 40-stellige Version.
  • Ein Headset.
    Gibt in Verbindung mit Screenreader via Sprachausgabe mit der Tastatur angesteuerte Inhalte aus.
  • Reguläre Tastatur.
    Eingesetzt für die reguläre, übliche Eingabe – wie es auch Sehende tun und Steuerung des Screenreaders
  • Computer mit installierter Screenreader-Software

Vielen Dank Simon für Deine Zeit und das ausführliche Interview! 

News-Kategorie: Blogbeitrag