Kompromisslosigkeit für die User schädigt letztlich nur die User...

[Gunnar Bittersmann]

@@dedlfix

Dass es wenig Aufwand bedeutet, Barrierefreiheit bei der Konzeption und Implementierung mitzubedenken, es aber ziemlich aufwendig und teuer ist, bei einer Anwendung nachträglich Barrierefreiheit nachzurüsten, hatten wir hier schon desöfteren thematisiert.

Kleines Gedankenspiel: Angenommen, du bist der Chef mit Personalverantwortung. Aus dem Bewerbungsprozess sind zwei Kandidaten übrig geblieben:

• A ist fachlich ganz OK, hat ein paar Lücken, die sich aber sicher durch das Team füllen lassen. Menschlich passt’s auch.

• B ist A fachlich weit überlegen, bringt Wissen mit, das im Team noch nicht vorhanden ist, eine echte Bereicherung. Menschlich passt’s auch. Hat bloß einen Haken: B ist blind.

Zwei Szenarien:

1. Die Webanwendung wurde nach bestem Gewissen so implementiert, dass sie vermutlich weitgehend auch für Blinde bedienbar sein sollte. Semantisches Markup, Interaktive Schaltflächen sind Buttons und haben aussagekräftige Beschriftungen, ARIA-Attribute sollten deren Zustandänderungen eigentlich wiederspiegeln. Es wurde aber noch nie mit Screenreader getestet, ob dem wirklich so ist, das müsste die Praxis zeigen. Eventuell wäre da noch Nacharbeiten nötig.

   Wen stellst du ein: A oder B? Und warum?

2. Bei der Implentierung der Webanwendung wurde nur darauf geachtet, wie es auf dem Bildschirm aussieht. Schaltflächen sind Icons, realisiert als divs. Du fragst die Entwickler, wie lange es wohl dauen würde, die Anwendung anzupassen, und erhältst als Antwort: na so vier, fünf Wochen bestimmt. Und die in der Zeit eigentlich geplanten Projekte müssten dementsprechend nach hinten verschoben werden.

   Wen stellst du ein: A oder B? Und warum?

[Ergänzung: 3. Szenario]

LLAP 🖖