Barrierefreies Web ist gutes Handwerk

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 wäre dazu in der Lage, 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.
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.

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.