Liebe Webdeveloper,
ich spreche hier besonders diejenigen von Euch an, die sich nicht um Barrierefreiheit scheren. Die vielleicht schon beim Begriff Barrierefreiheit, dem Hashtag #a11y oder Accessibility zusammenzucken und die Augen verdrehen. Die möglicherweise denken „Was soll ich mich um die Behinderten scheren, ist eh nur ein geringer Prozentsatz aller User.“
Ich will Euch eine kleine Geschichte erzählen, gerade denen, die klammheimlich diesem letzten Gedanken zustimmen, es aber nie wirklich zugeben würden. Und natürlich denen, die ganz offen sagen, das sei ja auch richtig und würde sich nicht auszahlen. Also, wenn Ihr mal ein paar Minütchen für mich Zeit hättet…
Ich bin verheiratet. Das allein ist nichts besonderes. Ich bin es sogar sehr gern. Das ist vielleicht schon eher etwas besonderes. Und mein Mann ist blind. Das wiederum ist etwas sehr besonderes, wie ich den Reaktionen unserer Mitmenschen manchmal entnehmen kann. Mein Mann ist sogar von Geburt an blind und ich wusste das vor dem Ja-Wort, guck mal an!
Dieses kurze Geschreibsel soll aber nicht darüber gehen, wie mein Mann mit Webseiten umgeht (er ist übrigens höchstselbst Fachmann und großer #a11y-Evangelist, und damit gar ein Power-User). Nein, dies soll mal beschreiben, was Ihr, die Ihr die einfachsten Accessibility-Regeln im Web missachtet, den Familienmitgliedern, Freunden und Bekannten der Blinden und Behinderten antut.
Es ist ja nicht so, dass die Blinden dann einfach auf eine andere Seite surfen können oder wollen, weil sie die Infos bei Euch nicht kriegen. Meist ist das gar nicht möglich, weil sie etwa an einer Umfrage auf einer ganz bestimmten Webseite teilnehmen möchten, oder sich auf einer bestimmten Webseite registrieren wollen, oder einfach ein Hotel oder einen Flug buchen möchten.
Was glaubt Ihr, was dann passiert? Richtig, sie bitten ihre Familienmitglieder um Hilfe. Nicht, dass die nicht gern helfen (keine Sorge, ich sehe mich nicht als „dafür bin ich schließlich da“, aber immerhin als „ich liebe meinen Mann, also helfe ich ihm auch, wenn möglich“). Und ja, selbst ein Power-User und Mann vom Fach wie meiner stößt oft genug an diese Grenzen, und das will was heißen.
Könnt Ihr Euch vorstellen, wie scheiße es eigentlich ist, wenn man mitten in einer Sache steckt, sei es ein Buch lesen, selbst was arbeitet, Hausarbeit, vielleicht gerade auf einer Leiter steht und einen Nagel in eine Wand zimmern will, oder Gardinen aufhängt und plötzlich ertönt aus dem Büro ein entnervtes „Orrrr, warum können die das nicht einmal richtig… warum zur Hölle… Frau!! Ich brauch Deine Hilfe! Ich komm mit diesem Formular nicht klar!“
Und Ihr wollt ja sicher nicht sagen, dass der Blinde dann halt abzuwarten hat, bis das Familienmitglied Zeit hat. Oder die Computerzeit für den Blinden einteilen wollen, und sich dann ein Freund daneben setzt und auf Abruf da ist. Oder sowas. Wollt Ihr sicher nicht, oder? Nee, dachte ich mir. Zumal – ich bin mit einem geburtsblinden Mann verheiratet und wusste schon weit vor dem Ja-Wort von diesen Problemen, aber was, wenn Eure/r Partner/in langsam oder plötzlich durch einen Unfall erblindet? Dann seid Ihr selbst in dieser Situation.
Ganz ehrlich, mich nervt es mindestens genauso wie meinen Mann. Er ist frustriert, etwas nicht allein zu können, was eigentlich gehen sollte, ich bin genervt, weil ich in meiner Sache gestört werde. Das trägt nicht wirklich zum Familienfrieden bei. Und wer ist schuld? Ihr. Ihr Webdeveloper, die es ums verrecken nicht auf die Reihe kriegt, Eure Webseiten semantisch korrekt und barrierefrei zu gestalten.
Deshalb – setzt Euch bitte auf den Hosenboden und lernt, wie man semantisch korrekt eine Webseite aufzieht. Schaut Euch dann die Regeln zur Barrierefreiheit an, das ist nicht mehr so sehr viel obendrauf.
Danke.
P.S.: Und jetzt noch ein ganz dickes, sehr ehrlich gemeintes Danke an alle Webdeveloper da draußen, die sich die Barrierefreiheit auf die Fahnen geschrieben haben und dafür sorgen, dass die Webseiten zugänglich werden. Für alle. Weil es allen nutzt.
P.P.S.: Ein verspäteter Nachtrag, weil gerade erst fertig: Mein Herzensmann (also der, mit dem ich verheiratet bin), der hat mal was über die Basics geschrieben. Jetzt könnt Ihr nicht mehr sagen, Ihr hättet von nix gewusst!
P.P.P.S.: Nu gibt es ebendiesen Beitrag vom Herzensmann endlich auch auf deutsch! Da: https://www.zehe-edv.de/2016/01/08/die-grundregeln-zugaenglicher-webseiten/
Leander
So ein Link zu „alle Regeln zur Barrierefreiheit in Kürze“ wär hier jetzt schwer angesagt! (Es ist nämlich NICHT so einfach, sondern ein wilder Wust aus Infos verschiedener Jahre, die keineswegs heute alle relevant sind). Schon eine Info-Seite zu WordPress-Blogs würde vielen helfen.
Akshaya
Ich denke die ganze Zeit darüber nach, wie ich auf Deinen Kommentar antworten soll… Und ich werde es mal hierbei belassen: eine kurze Suche nach „semantisches HTML“ führt schon genau auf die richtigen Seiten. Semantisches HTML beinhaltet auch, die Uralt-Standards einfach umzusetzen wie Überschriften mit h1-h6 auszuzeichnen und in Formularen das korrekte Dings zu benutzen, wie Radio-Buttons für Radio-Buttons etc. Aber genau da hakt es einfach immer noch. Die Grundlagen fehlen. Guckst Du auch selfhtml.org etc.
Außerdem war das ja kein Hilfe-Beitrag, sondern ein Rant. Da darf sowas wie ein Link gern mal fehlen. Finde ich.
rhoio
Hallo, ich bin Web Developer. Und ja, ich würde Websites gerne barrierefrei gestalten. Aber das scheitert momentan an zwei Dingen:
1. http://webaim.org/techniques/css/invisiblecontent/ – 5 verschiedene Methoden, Content für Screenreader sichtbar und für andere unsichtbar zu machen (und ja, das ist manchmal nötig). Und jede dieser Methoden hat irgendwo anders einen Haken. Welche nehm ich jetzt? Und mit welchen unangenehmen Nebenwirkungen überfällt sie mich ein halbes Jahr später, wenn die Website auf arabisch lokalisiert wird…
Wenn ich über das Thema recherchiere, ertrinke ich in einer Flut von widersprüchlichen Hinweisen und so ziemlich das einzige, auf das sich alle einigen können ist, dass Bilder ein alt-Attribute haben sollen. Ach nein, reine Deko-Bilder dann doch lieber kein alt-Attribute. Oder doch? Blinde zum Fragen hab ich im Bekanntenkreis momentan nicht…
2. Kunde zahlt das nicht. Kunde kommt mit einem Layout von einer Grafikagentur, das bitte genau so umgesetzt werden soll. Und dann heißt es „Iiih, bei mir werden die Formularfelder so komisch blau umrandet, mach das weg“. Und dann macht man das seufzend weg, nachdem man den Kunden darüber aufgeklärt hat, dass das blaue „outline“ heißt und Nutzern, die mit der Tastatur navigieren, anzeigt, wo sie sich grade befinden. Ob ihn das wirklich so stört? Ja. wegmachen.
Akshaya
Erst mal grundsätzlich: das Wichtigste ist, dass Du semantisches HTML nutzt. Also h1-h6 für Überschriften und z.B. Radio-Buttons für Radio-Buttons und nicht irgendeinen schicken Firlefanz, der blinden Nutzern nicht ansagt, ob sie jetzt zugestimmt haben oder nicht (das war der eigentliche Aufhänger dieses Rants, zweimal an einem Tag auf zwei verschiedenen bekannten Websites so passiert). Dann hast Du schon mal mindestens 80-90% an Barrierefreiheit fertig. Out-of-the-box sozusagen, ohne Mehrarbeit.
Zu 1.: Eine gute Anlaufstelle ist z.B. https://marcozehe.de oder https://zehe-edv.de (die Seiten von meinem Mann), von dort kriegst Du mehr Infos und Links, er hat schon viel darüber gebloggt.
Zu 2.: Schwieriger Fall, und ich bin auch kein Berater für Accessibility. Aber da gibt es zwei, die so richtig gut sind und gute Argumente liefern. a) Kerstin Probiesch: http://barrierefreie-informationskultur.de und b) Jan-Eric Hellbusch: http://www.barrierefreies-webdesign.de/
Beide sind meines Erachtens *die* deutschsprachigen Koryphäen auf dem Gebiet (und haben auch ein Buch darüber geschrieben).
Kerstin Probiesch
Mal so generell und nicht direkt als Antwort: Vieles an der Accessibility ist eigentlich gar nicht Accessibility, sondern – ich bleib mal bei HTML, wird sowieso schon lang – HTML so einzusetzen, wie vorgesehen. Das bedeutet: Man schreibt sauberes HTML nicht wegen Accessibility, sondern weil es einen HTML-Standard gibt oder sollte es zumindest so machen. Werden z.B. Elemente nicht oder falsch eingesetzt, dann hat man sich nicht an diesen gehalten.
Ein Beispiel: Eine Seite mit einem H-Element. Der Rest Definitionslisten, viele mit nur einem Eintrag: Überschrift „Pressemeldungen“ als DT u.d. Liste der Meldungen in einem DD, die Überschrift „Links“ als DT und eine Liste mit Links in einem DD, die Überschrift „Publikationen“ als DT und die Liste als UL in einem DD. Die Auswirkung: Man kann in Screenreadern mit der H-Taste nur eine Überschrift erreichen, obwohl es mehrere Überschriften gibt und muss sehen, wie man sonst so durch die Seite kommt. Was ist die Ursache? Die ist nicht, dass Accessibility nicht umgesetzt wurde, sondern dass HTML nicht richtig umgesetzt wurde und sich das auf die Accessibility auswirkt.
„Der Kunde zahlt das aber nicht“ ist ein oft gehörtes Argument. Mir stellt sich da immer die Frage – das meine ich allgemein, rhoio, nicht persönlich und nicht bezogen auf dein Beispiel:
Was zahlt er nicht? Dass HTML so geschrieben wird, wie es gedacht ist? Und was bedeutet es umgekehrt: HTML schreiben wir nur richtig, wenn es accessible sein muss und sonst nicht? Ich glaube, was einige sehr interessiert – zumindest mich ;-) – ist, wie Kalkulationen zustande kommen? Dass oft genug für „Accessibility“ ein Aufschlag genommen wird, weiß man. Was man nicht weiß ist: Wofür und wie hoch die jeweiligen einzelnen Posten sind? Dafür, dass HTML standardkonform geschrieben wird, dürfte eigentlich keiner genommen werden. Sonst muss man ja fragen: Wie viel kostet es pro (richtiges) H-Element, Label-Element, richtige Liste usw. und kostet es auch extra, wenn man pro Absatz ein P verwendet und nicht für drei zusammen ein P? Das würden sicher viele verneinen und sich über die dumme Frage wundern. Wenn jetzt aber richtige P-Elemente nichts extra kosten, warum sollte denn dann anderes aus dem HTML-Standard zu einem Aufschlag führen? Natürlich. Nicht nur schlechtes HTML kann zu Accessibility-Problemen führen. Das ist klar. Nur: Wenn alle schon mal HTML richtig umsetzen würden, dann wäre viel gewonnen. Mal abgesehen, dass Accessibility selber ja nicht „dieses ganz andere ist“, sondern ebenfalls ein Webstandard.
Grafiken: Ich vermute, Alternativtexte sind gemeint und nicht das alt-Attribut selber? Reine Deko-Grafiken bekommen keine Alternativtexte, aber ein alt-Attribut und zwar ein leeres. Dann können sie von Screenreadern ignoriert werden. Das Beispiel mit den Eingabefeldern habe ich nicht verstanden, fürchte ich. Man sieht doch viele Formulare, wo ein Farbwechsel für den Rahmen beim Reinklicken mit der Maus stattfindet. Wenn das bei Reintabben mit der Tastatur passiert, ist es nur konsequent. Warum sollte sich ein Kunde über etwas wundern, das mit der Maus den gleichen Effekt hat? Der geeignete Punkt für solche visuellen Aspekte ist ohnehin die Layout-Phase; hier müssen die richtigen Weichen gestellt werden; gerade auch, damit so etwas nicht passiert.
@Akshaya: Sorry, dass das so lang wurde. Ich habe mich bemüht. Ehrlich…
Daniel Rehbein
Im Jahr 2001 habe ich einen Text verfasst über den Textbrowser Lynx als Werkzeug zum Test von Webseiten auf Barrierefreiheit. Ich glaube, der Text ist weiterhin aktuell. http://www.mein-dortmund.de/browser-lynx.html