Anlässlich des Global Accessibility Awareness Day am 17. Mai hatte ich verschiedene Tweets zum Thema barrierefreie Webgestaltung abgesetzt. Unter anderem schrieb ich sinngemäß: „Barrierefreie Webseiten sind keine Extra-Leistung, sondern gutes Handwerk. Hohe Preisaufschläge sind also nicht gerechtfertigt“. Für diese Aussage habe ich ein paar kritische Nachrichten bekommen. Deshalb möchte ich das kurz erklären.

Ein Button ist ein Button ist ein Button

Wenn etwas so aussieht wie ein Button und wenn es sich verhält wie ein Button, dann sollte es auch in HTML ein Button sein.
Kurz zur Erklärung: Man kann design-technisch etwas erstellen, was wie ein Button aussieht und so funktioniert, aber im Code einfach nur JavaScript ist, der hinter eine Grafik gelegt wurde, die wie ein Button aussieht. Warum macht man so was? Weil man entweder faul, doof oder beides ist. Der Aufwand, einen echten Button in HTML zu basteln ist exakt 0 Prozent höher als eine Grafik mit JavaScript zu unterlegen. Doof, weil man offensichtlich keine Ahnung hat, wie man vernünftigen Code schreibt und wahrscheinlich irgendeine Anwendung verwendet, mit der man sich die Elemente zusammenklickt. Ich als absoluter Laie könnte so etwas in HTML anzulegen. Wer sich Webentwickler nennt, sollte das hinbekommen, das ist sozusagen das kleine Ein-Mal-Eins des Webdesigns.
Das Gleiche gilt natürlich für alle anderen Bereiche. Wer HTML und CSS ihrem Zweck gemäß einsetzt, hat bereits einen Großteil der Anforderungen von Barrierefreiheit erfüllt. Aber das ist nun wirklich kein Kunststück. Wer aber seine Website heute noch mit div id=“navigation“ verschandelt, hat keine Ahnung von seinem Handwerk.
Nun kann man argumentieren, dass der Spaghetti-Code niemanden interessiert, schließlich soll es gut aussehen und funktionieren. Aber nein, es bringt massive Nachteile mit sich. Ein Programm kann hingehen und den Container „Content“ in eine lesefreundliche Variante umwandeln. Google kann den Content sauber von der Navigation oder der Fußzeile unterscheiden. Wer also nicht sauber codet, verschlechtert neben der Barrierefreiheit unter anderem seine Position bei Google.
Und natürlich der Screen Reader: Er kann erkennen, dass etwas ein Button ist und der Blinde kann gezielt alle Buttons einer Website anspringen. „Anklickbar, anklickbar, anklickbar“ hingegen ist für Blinde nicht hilfreich. Aber wenn interessiert schon Usability für Blinde, Hauptsache, die Box hat abgerundete Ecken und einen coolen Effekt.
Umso schlimmer ist es, dass wir uns immer noch über solche Themen unterhalten müssen, dass wir immer noch auf nicht-gelabelte Formularelemente und ähnliche Dinge stoßen.

Barrierefreie Lösungen finden

Was ist aber mit komplexen dynamischen Anwendungen wie Kalender-Widgets oder Lightboxen.
Tatsächlich gibt es für die meisten komplexen Anwendungsfälle frei verfügbare Patterns oder Lösungen, die sich übernehmen oder zumindest nachbauen lassen. Es wäre heute also kein Problem mehr, dem Kunden barrierefreie Webseiten sozusagen unterzuschieben, ob er sie will oder nicht.
Eine barrierefreie Lösung zu recherchieren und einzubauen kostet eben so viel Zeit wie eine nicht-barrierefreie Lösung einzubauen.

Design-Kriterium: Sieht besser aus

Wenn ein Thema in der Barrierefreiheit nicht ernst genommen wird, dann ist es der Kontrast. Das gilt vor allem für Text und Bedien-Elemente. Wir haben uns so sehr daran gewöhnt, dass wir Dinge zoomen müssen, dass es uns nicht weiter auffällt.
Das Argument der Designer: Es sieht so besser aus. Wenn Design darin besteht, Dinge gut aussehen zu lassen, dann ist die Mission erfüllt.
Aber eigentlich dachten wir ja, wir sollten die Website oder Anwendung benutzen. Gewiss braucht man manchmal einen gewissen ästhetischen Anreiz. Aber darf es wirklich anstrengend sein, etwas zu erkennen, bedienen oder lesen zu können? Ist schön machen das einzige Berufsziel von Designer:Innen?

Wann Kostenaufschläge gerechtfertigt sind

Natürlich gibt es noch weitere Anforderungen der Barrierefreiheit, die durchaus komplexer sind. Das Anpassen der Patterns an die eigenen Erfordernisse etwa erfordert zusätzlichen Aufwand, wenn sich der Entwickler einarbeiten muss. Doch müssen Patterns immer angepasst werden, etwa aus Design-Gründen.
Eine Ausnahme gilt auch dann, wenn externe Barrierefreiheits-Experten eingeschaltet werden. Die wollen natürlich separat bezahlt werden.
Eine weitere Ausnahme gilt dann, wenn spezifische Tests mit behinderten Menschen zusätzlich durchgeführt werden. Diese Tests sind aufwendig und teuer. Eventuell wird auch ein Honorar oder eine Aufwandsentschädigung an die Testpersonen gezahlt.
Zudem können im Rahmen der Barrierefreiheit zusätzliche Absprachen mit dem Auftraggeber notwendig sein. Es muss etwa ein Konsens darüber erreicht werden, welcher Standard erfüllt werden soll und welche zusätzlichen Anforderungen es gibt.
Über besondere Anforderungen wie Leichte Sprache oder Gebärdensprache spreche ich hier nicht. Hier sind die Kostenaufwände natürlich erheblich. Das hat aber mit der Web-Agentur nichts zu tun.
Doch für den ganz normalen Programmier-Alltag sind hohe Kostenaufschläge für Barrierefreiheit selten gerechtfertigt. Viele Diskussionen und Probleme würden sich erübrigen, wenn Web-Entwickler einfach sauberen und bestimmungsgemäßen Code schreiben würden. Analoges gilt für native Apps. Einfach die Guidelines der OS-Anbieter lesen und sich daran halten, das scheint so manchen Entwickler zu überfordern. Es grenzt an Arbeitsverweigerung oder Unfähigkeit.
Meines Erachtens fehlt es an mehreren entscheidenden Aspekten:

• Das Thema Barrierefreiheit wird in der Ausbildung vernachlässigt.
• Es fehlt die Sensibilität bei den Verantwortlichen, und zwar sowohl bei Entwicklern, Designern als auch bei Auftraggebern.
• Es fehlt an grundlegenden handwerklichen Fähigkeiten. Das stelle ich in meiner Arbeit mit Entwicklern immer wieder fest. Da saßen bei mir tatsächlich Leute in Entwickler-Schulungen, die kein HTML konnten. Ihre Fähigkeiten erschöpfen sich darin, Kästen hin- und herzuschieben.

Die ganzen Argumente wie Zeitdruck können nicht überzeugen. Wenn man eine Sache zwei Mal machen muss, einmal falsch, einmal richtig, sind mehr Zeit und Ressourcen verbraucht worden als wenn man es einmal richtig macht. Und leider machen es allzuviele Leute gleich zwei Mal falsch.
Why every Developer should know how to make Websites accessible