Die Kluft zwischen Barrierefreiheits-Spezialist:Innen und Betroffenen

In den letzten Jahren beobachte ich, dass die Kluft zwischen Betroffenen und Barrierefreiheits-Spezialist:Innen weiter auseinander geht. In diesem Beitrag möchte ich das an einigen konkreten Beispielen zeigen. Ich lasse mal den Fakt außen vor, dass es auch betroffene Spezialist:Innen gibt.

Inhalt

Nicht-barrierefreie PDFs

PDF können ebenso barrierefrei sein wie barrierefreie Webseiten. Die Betonung liegt auf können. Es ist kein Zufall, dass HTML die Referenz für barrierefreie PDF ist und nicht umgekehrt. In meiner langen Karriere habe ich wenige PDFs gesehen, welche die Qualität einer mittelmäßig barrierefreien Webseite erreicht hatten – bei vergleichbarer Komplexität versteht sich.
Das Problem lässt sich sehr einfach zusammenfassen: PDF ist nicht für Barrierefreiheit ausgelegt und im übrigen auch nicht für Responsivität. Neben Cookie-Bannern sind PDFs eine der nervigsten Usability-Bugs auf Webseiten. Man setzt am falschen Ende an: Statt bereits im Produktions-Prozess das Thema Barrierefreiheit vorzusehen, wird zunächst ein für den Druck optimiertes PDF erzeugt, das hinterher barrierefrei gemacht und ins Internet gestellt wird. Ein teurer und blödsinniger Prozess. Aber alle sind glücklich. Die Anbieter:In muss ihre Prozesse nicht optimieren und die Spezialist:In verdient an jedem Fehler, den die Gestalter:Innen im PDF gemacht haben. Der Betroffene kommt in dieser Geschichte leider nicht vor. Wäre die Barrierefreiheit ein Whodunit-Krimi, wäre der Betroffene das Mordopfer, über ihn wird gesprochen, aber nicht mit ihm.
Den Wenigen, die es hören wollen sage ich, dass ich eine Webseite oder ein Office-Format jedem barrierefreien PDF vorziehe.
Aus User:Innen–Perspektive ist es im übrigen egal, ob es an der assistiven Technologie, am Lese-Programm oder am PDF liegt. Als Nutzer:In möchte man ein Dokument lesen oder damit arbeiten, nicht sich mit Standards und deren Problemen herumschlagen.

Das Language-Attribut

Das Language-Attribut dient dazu, dem Screenreader oder anderen Vorlese-Tools mitzuteilen, in welcher Sprache ein Inhalt vorgelesen werden möchte. Die meisten fortgeschrittenen Sprachausgaben-Nutzer:Innen, die ich dazu befragt habe, schalten den automatischen Sprachwechsel ab. Den Hintergrund habe ich an anderer Stelle ausführlich dargestellt. Sicherlich gibt es Blinde, die mehrsprachig unterwegs sind und denen es nichts ausmacht, wenn der Screenreader ständig die Sprache ändert. Das ist allerdings eine Minderheit. Jeder mir bekannte Screenreader erlaubt das manuelle Umschalten der Synthesizer-Sprache, aber nicht alle erlauben die Abschaltung des automatischen Sprachwechsels.
Bei den Spezialist:Innen, etwa bei den Verantwortlichen des BITV-Tests, geht das in einem Ohr rein und zum anderen raus. Sie verlangen, dass jedes Fremdwort mit der entsprechenden Sprache ausgezeichnet wird.

Alternativtexte

Die meisten Diskurse mit Spezialist:Innen habe ich bezüglich Bild-Beschreibungen. Die Seite X erzeugt aus dynamischen Daten Diagramme. Das verwendete Framework erzeugt automatisch eine Bild-Beschreibung, in welche etwa die Zahl der Säulen oder Balken und deren Werte zusammengefasst werden. Dazu auch noch auf Englisch auf einer deutschen Webseite.
Ich sage, hier ist eine – vorhandene – CSV tatsächlich die bessere Alternative. Es mag Fälle geben, in denen die Form des Diagramms und deren visuelles Aussehen für einen Blinden relevant ist – mir fällt allerdings keiner ein. Der Spezialist sagt mir aber, die Richtlinie XY schreibt einen Alternativtext vor.

Barrierefrei, aber eine Usability-Katastrophe

Viele Anwendungen sind auf dem Papier barrierefrei, aber eine reine Katastrophe, was die Usability angeht. Mein Lieblings-Beispiel ist hier Microsoft Teams sowohl auf dem Desktop als auch auf dem Browser. Microsoft hat hier das schlechteste aus zwei Welten – Desktop und Mobil – zusammengenommen und daraus eine schicke Anwendung für Sehende gemacht. Für Blinde ist die Anwendung eine reine Katastrophe. Das schnelle Bewegen innerhalb der App erofrdert das Auswendig-Lernen zahlloser Tasten-Kombinationen. Die App ist dermaßen verschachtelt, dass man häufig 10 mal klicken muss, um einen gewünschten Bereich zu erreichen.
Und das gilt auch für zahlreiche andere Anwendungen. Sollte sich, wie absehbar, ein großer Teil der Software in den Browser oder halbe Web-Apps verlagern wird es immer schwieriger.
Mir graut ein wenig vor der Zukunft, in der wir solche Programme nutzen müssen. Wenn sich nicht drastisch etwas in der Software-Entwicklung oder in den assistiven Technologien ändert, sehe ich für Blinde mit IT-Bezug keine effiziente Arbeits-Möglichkeit mehr.

Fazit

Ich bin ja eigentlich ein lösungs-orientierter Mensch. Leider kann ich in diesem Fall keine Lösung anbieten. Vielleicht gehört es auch zum Spezialistennentum,, sich für allwissend zu halten und sich für die Meinung Betroffener nicht mehr zu interessieren. Es ist ja auch interessant, dass man Millionen für formale Tests aufwendet, aber Nutzer:Innen-Tests angeblich zu teuer sind.
Für mich persönlich habe ich die Konsequenz gezogen, mich mit vielen Spezialist:Innen gar nicht mehr zu unterhalten. Ich setze auf Personen, die neu in das Thema einsteigen bzw. sich nicht hauptsächlich mit Barrierefreiheit beschäftigen. Dort bin ich auf deutlich mehr Offenheit gestoßen.