Die Grundregeln zugänglicher Webseiten

Ich werde immer wieder gefragt, was denn die absolut grundlegenden Dinge sind, die man als Webentwicklerin und Webentwickler kennen sollte, um Webseiten so zu schreiben, dass sie möglichst zugänglich sind.

Ich hatte eigentlich angenommen, dass es hierzu schon zahlreiches Material im Web gibt und dass es nicht schwierig sein dürfte, dieses auch zu finden. Da die Frage aber immer und immer wieder aufkommt, habe ich nun beschlossen, meine eigene Sicht dieser absoluten Grundlagen aufzuschreiben. Hier ist sie also nun, meine persönliche Liste der Grundlegenden Dinge für zugängliche Webseiten.

Alternativtexte für Bilder 🔗

Eine der häufigsten Fragen, die mir gestellt wird, ist, welche Bilder auf Webseiten Alternativtext brauchen. Zu dieser Frage gibt es eine dreiteilige Antwort:

  1. Jeder auf einer Seite verwendete img Tag benötigt ein alt-Attribut. Diese Regel gilt ohne Ausnahme. Alles andere ist ein Fehler. Wenn ihr also einen img Tag auf eurer Seite hat, der kein alt-Attribut hat, fügt es jetzt hinzu.
  2. Jedes alt-Attribut benötigt einen Wert. Und hier wird es spannend! Wenn der img Tag z. B. Teil eines a tags ist, muss er eine Bedeutung haben, weil sonst der Sinn des Links nicht verstanden werden kann. Auch wenn eine Grafik zum Verständnis von Fließtext beiträgt, muss der Alternativtext eine Bedeutung haben. Was der beste Alternativtext ist, ist immer noch Gegenstand manchmal hitziger Debatten. Meine Faustregel lautet: Nutzt den gesunden Menschenverstand. Beschreibt das Bild kurz, vermeidet aber die Worte „Grafik von“ oder „Bild von“, da Screen Reader bereits wissen, dass es sich um ein Bild bzw. eine Grafik handelt. Hat das Bild auf der anderen Seite einen rein dekorativen Zweck, ist also lediglich schmückendes Beiwerk, für das Verständnis der Seite aber nicht von Bedeutung, muss der Alternativtext aus zwei aufeinanderfolgenden Anführungszeichen bestehen, also „“. Diese dürfen nicht fehlen oder das alt-Attribut nicht weggelassen werden.
  3. Es heißt alt-Attribut, Alternativtext, alternativer Text, aber niemals Alt-Tag. alt ist das Attribut des img Tags, kein eigener HTML-Tag.

All diese Regeln gelten ohne Ausnahme auch für SVGs, hier dargestellt durch den title, und bei Verwendung des picture Elements.

Die korrekte Implementierung von Alternativtexten hilft übrigens nicht nur Blinden und Sehbehinderten mit Screen Readern, sondern auch z. B. auf Mobilgeräten mit schlechter Internetverbindung, über die Bilder vielleicht nicht korrekt geladen werden können. Ein guter Alternativtext hilft also viel mehr Besuchern eurer Webseiten, als ihr es euch zunächst vorstellen könnt!

Formularfelder korrekt beschriften 🔗

Eine weitere sehr häufige Frage betrifft das korrekte Beschriften von Formularfeldern. Dies ist auch einer der weitaus häufigsten Fehler, die mir auf Webseiten selbst im Jahr 2016 beim täglichen Surfen über den Weg laufen. Wenn ich mit Webentwicklern zu tun habe, denen solche Fehler passiert sind, ist es schon häufig vorgekommen, dass diesen überhaupt nicht bekannt war, dass es das label Element überhaupt gibt.

Hier kommen nun die wichtigsten Regeln für das korrekte Auszeichnen von Formularfeldern:

  1. Die meisten input Elemente, das select und das textarea Element benötigen ein zugehöriges label Element, das deren Zweck angibt. Lediglich diejenigen Typen des input Elements, die Schaltflächen produzieren, bekommen eine Beschriftung durch ein weiteres Attribut oder inneren Text, also button, reset und submit. Alle anderen Typen wie text, checkbox, password, radio, search usw. benötigen eine Beschriftung durch ein label Element.
  2. Die Zuordnung des label Elements zum input, select oder textarea Elements erfolgt, indem man letzteren eine eindeutige ID durch das id-Attribut gibt und diese dann in das for-Attribut des label Elements einträgt. Um zu testen, ob die Zuordnung auch tatsächlich geklappt hat, klickt man auf die Beschriftung, nicht das input Element. Erhält das input Element den Tastaturfokus? Wenn ja, hat die Zuordnung geklappt, und zukünftig werden Screen Reader eindeutig identifizieren können, wofür ein Feld gedacht ist. Außerdem erhöht dies die Größe des Klick-Bereiches. Das hilft nicht nur auf Mobilgeräten, wo die Bereiche zum Berühren eines Feldes eh verkleinert sind, sondern auch Menschen mit motorischen Einschränkungen, die die Maus vielleicht nicht millimetergenau steuern können.
  3. Nutzt unter gar keinen Umständen das placeholder-Attribut als Ersatz für ein richtiges label! Dieser englischsprachige Artikel erklärt ausführlich, dass dieses Attribut nicht unproblematisch ist. Die wichtigsten Punkte sind, dass zum einen der Kontrast viel zu niedrig sein kann und man umständlich mit CSS nacharbeiten muss. Außerdem verschwindet die Beschriftung, sobald man Text in das Feld eingibt, so dass der Kontext verloren geht. Menschen mit Leseschwäche oder anderen kognitiven Einschränkungen werden hier große Schwierigkeiten bekommen, da sie nicht mehr wissen, was in welches Feld gehört. Oder stellt euch einfach vor, ihr habt ein Formularfeld mit 30 Eingabefeldern, aus denen die Beschriftungen verschwinden. Na, wisst ihr nach einer Minute noch, was ins 11. Feld gehört? Weiterhin ist die Unterstützung in den Browsern sehr inkonsistent. Bei manchen taucht die Beschriftung wieder auf, wenn man den Text ganz rauslöscht, bei anderen nicht, und die Spezifikation ist hier nicht eindeutig. Dies ist auch der Grund, weswegen die Unterstützung für Screen Reader variieren kann. Während ein Platzhalter also eine Hilfestellung sein kann, sollte es niemals die primäre Quelle einer Beschriftung für ein Eingabefeld sein!
  4. Gebt button Elementen inneren Text, oder wenn es eine Grafik sein muss, gebt dieser einen Alternativtext, der einer sichtbaren Textbeschriftung entsprechen würde. Siehe auch die Sektion zum Beschriften von Grafiken weiter oben. Und wie auch im MDN-Artikel angeraten, nutzt das button Element lieber als ein input mit typ „button“, da dieses besser mit Styles versehen werden kann. Außerdem ist dies dasjenige Element, an das ihr euch immer vertrauensvoll wenden solltet, wenn ihr eigentlich vorhattet, ein div oder span Element mit hunderten Kilobytes JavaScript anklickbar zu machen. Nehmt stattdessen das button Element, das kann nämlich automatisch angeklickt werden, hat Tastaturnavigierbarkeit und auch sonst alles, was ihr braucht.
  5. Eine zusammengehörige Gruppe von radio buttons gehören in ein fieldset Element. Das erste Element innerhalb des fieldset Elements ist das legend Element, welches die eigentliche Frage zu den gruppierten radio buttons enthält.
  6. fieldset und legend werden auch verwendet, um in einem komplexeren Formular Untergruppen zu bilden. Dies macht das Formular übersichtlicher und gibt ihm eine logische Struktur. Das fieldset Element kann mehr als nur radio buttons aufnehmen.
  7. Zeichnet erforderliche Felder mit dem required-Attribut aus HTML5 aus und gebt zusätzlich der Beschriftung das Wort „erforderlich“ mit oder fügt am Beginn eures Formulars eine Legende ein, die besagt, dass z. B. mit einem Sternchen „*“ markierte Felder erforderlich sind. Zeichnet erforderliche Felder nicht nur durch eine andere Farbgebung aus. Screen-Reader-Nutzer können diese nicht erfassen, und Menschen mit einer Farbfehlsichtigkeit ebensowenig, und das sind immerhin 8 Prozent der männlichen Bevölkerung weltweit.
  8. Gebt für E-Mail-Adressen, URLs, Telefonnummern usw. die richtigen type-Attributwerte aus dem HTML5-Standard an. Nutzer mobiler Geräte werden es euch danken, denn diese erzeugen automatisch die richtige Tastatur für die Eingabe des geforderten Wertes. Außerdem macht es euch die Auswertung leichter, da der Browser automatisch weiß, ob ein gültiger Wert eingegeben wurde. Alle modernen Browser können das. Solltet ihr noch ältere Browser unterstützen müssen, fallen diese automatisch auf den Typ „text“ zurück, und der ist für all diese Fälle der korrekte Fallback.
  9. Stellt sicher, dass der Tastaturfokus immer sichtbar ist. Wenn ihr einen Rahmen um euer input erscheinen seht, wenn ihr mit der Maus hineinklickt, muss dieser Rahmen auch erscheinen, wenn ihr mit der Tab-Taste durch euer Formular wandert. Taucht der Rahmen nicht auf, müsst ihr die CSS-Auszeichnungen für :focus und :active für diese Elemente überprüfen und korrigieren.

Braucht ihr etwas, das etwas anspruchsvoller aussieht als es die Standard-Stylings der input Elemente hergeben, fallt bitte nicht darauf zurück, divs und spans klickbar zu machen. Wenn ihr das nämlich tut, müsst ihr Rollen, Zustände, Tabstops, das Reagieren auf Tastatureingaben usw. alles selbst mit JavaScript implementieren. Nutzt stattdessen lieber Dinge wie span Elemente innerhalb eurer labels, um ein besseres Styling hinzubekommen. Dies garantiert, dass die Zugänglichkeit euch gleich mit geschenkt wird und erspart eine Menge Arbeit.

Dokumentstruktur 🔗

Es ist kaum zu glauben, aber im Kern basiert das Web auf einer Dokumentenstruktur. Selbst wenn wir also schöne komplexe Webanwendungen wie Gmail bauen, liegt diesen doch immer ein Dokument zu Grunde. Und es gibt viel, das ihr semantisch für die Struktur eurer Dokumente tun könnt, das euch im Normalfall zwischen 80 und 90 Prozent der Zugänglichkeit frei Haus liefert. Zum Beispiel:

Überschriften 🔗

Sind euch die verschiedenen Überschriften in diesem Blogbeitrag aufgefallen? Dafür gibt es Elemente, nämlich die heading Elemente. Diese stellen eine sechsstufige Überschriftenstruktur zur Verfügung. Es gibt eine Hauptüberschrift auf Ebene 1, Unterüberschriften auf Ebene 2, und weitere Unterüberschriften für Abschnitte wie diesen hier zum Beispiel. Die richtige Anwendung dieser Elemente gibt euren Dokumenten eine logische, einfach zu folgende Struktur. Habt ihr euch nie gefragt, wie Wikipedia in seinen Artikeln die verschachtelten Inhaltsverzeichnisse zusammenbaut? Sie nutzen dafür genau diese Abstufungen. Die richtige Überschriftenstruktur hilft Screen Readern, Suchmaschinen und anderen Technologien, die Struktur eurer Webseiten zu verstehen und richtig zu indizieren. Vermischt die Stufen nur, wenn die Struktur es erfordert, und lasst wenn irgendmöglich keine Überschriftenebene aus. Und schreibt bitte *nie,*nie wieder so etwas wie ein div Element mit einer Klasse „heading1“ in euren Code! Damit können weder Screen Reader noch Suchmaschinen etwas anfangen! Sie werden aber genau wissen, was sie mit eurer Überschriftenstruktur anfangen können!

Landmarks (Wegmarkierungen) 🔗

Eine weitere Möglichkeit, eurem Dokument strukturelle Merkmale zu geben, sind sogenannte Landmark-Elemente. Diese sind article, aside, footer, header, nav und main. Richtig angewandt verleihen diese Elemente euren Dokumenten deutlich mehr Möglichkeiten zur Navigation.

Listen 🔗

HTML kennt verschiedene Arten von Listen. Es gibt unsortierte und sortierte (numerierte) Listen. Man kann das Aufzählungs- bzw. Numerierungsmuster angeben, sie verschachteln, und der Browser übernimmt den Rest. Man kann das visuelle Layout weiter anpassen und dem Dokument dadurch noch mehr Bedeutung und Struktur geben. In diesem Blogbeitrag sind bereits zwei numerierte Listen vorgekommen.

Es gibt noch einen weiteren Listentyp, nämlich sogenannte Definitionslisten, die dazu geeignet sind, Gruppen aus Begriffen und deren Erklärung zu bilden. Der MDN-Artikel zum dl Element enthält eine Reihe sehr guter Beispiele für deren Einsatz.

Weitere 🔗

Wusstet ihr schon, dass es ein Element in HTML gibt, mit dem man Absätze kennzeichnet? Es heißt p. Zitate, die einen eigenen Absatz benötigen, zeichnet man mit dem blockquote Element aus. Kurze Zitatschnipsel, die man in seinen Fließtext einbettet, werden hingegen mit dem q Element ausgezeichnet. Horizontale Trennlinien werden mit dem hr Element erzeugt.

All diese Elemente werden dann mit CSS weiter gestaltet, wie z. B. deren Einrückung und Abstände definiert usw. Dies beeinflusst dann nicht die Semantik, gibt euren Dokumenten aber ein individuelles und optisch ansprechendes Layout, das euren Vorstellungen oder denen eures Auftraggebers entspricht.

Tabellen 🔗

HTML-Tabellen sind eine eigene Kategorie von Elementen. Sie sind sehr nützlich, um strukturierte Daten semantisch korrekt darzustellen. Produktdetails, Preislisten, Warenkörbe mit Zwischen- und Endsummen sind nur einige Beispiele von strukturierten Daten, für deren Einsatz das table Element vorgesehen ist.

Historisch bedingt gibt es jedoch auch viele Fälle, in denen das arme table Element dazu missbraucht wurde, um das Layout für eine Seite zu erzeugen. Diese Unsitte stammt noch aus der zeit vor HTML 4 und dem Siegeszug von CSS, hält sich aber hartnäckig sogar bis ins Jahr 2016. Ich finde noch heute Formulare, die mit Hilfe von sogenannten Layouttabellen gestaltet wurden, um Label und deren Formularfelder optisch auszurichten. Hört BITTE damit auf! Danke!

Hier sind nun einige Tipps zum richtigen Einsatz von Datentabellen:

  1. Fügt als erstes ein caption Element in eure Tabelle ein, um ihr eine Überschrift oder Zusammenfassung von deren Inhalt zu geben.
  2. Nutzt das th Element, um Zeilen- und Spaltenüberschriften auszuzeichnen, und nutzt dessen Attribute wie scope, um genau festzulegen, welche Überschrift wofür gilt.
  3. Nutzt die weiteren im Abschnitt „Siehe auch“ des table Elements angegebenen Elemente, um eure Tabelle weiter zu strukturieren.
  4. Sollte eine Tabelle zu komplex werden oder aus mehreren Abschnitten bestehen, die nicht direkt zusammen gehören, spaltet diese in mehrere Tabellen auf.

Für weiterführende Informationen möchte ich euch gern die Benimmregeln für Datentabellen von Tomas Caspers, veröffentlicht auf den Seiten von Jan Eric Hellbusch, ans Herz legen.

Ein paar weitere Quickies 🔗

Hier sind noch ein paar weitere Dinge, die ihr leicht prüfen könnt, wenn ihr HTML, CSS und JavaScript schreibt:

Trennt die Konzepte voneinander 🔗

HTML definiert die Struktur eures Inhalts. Dies ist es, was Screen Reader und andere Hilfstechnologien auswerten, um ihren Anwendern eine Repräsentation eurer Seite anzubieten.

CSS definiert, wie sich dieser Inhalt optisch präsentiert. Durch Einrückungen, Abstände, Ränder, Farbgebungen usw. wird dies festgelegt. Diese Attribute haben bis auf wenige Ausnahmen keinen Einfluss darauf, wie der Inhalt von Hilfstechnologien präsentiert wird. Die Ausnahmen sind die Benutzung von display: none; bzw. visiblity:hidden; welche tatsächlich dafür sorgen, dass auch Hilfstechnologien diese Inhalte nicht anzeigen werden. Siehe hierzu auch meinen Beitrag „Verstecken von Inhalten entwirrt„. Außerdem wird der CSS-Text :before und :after ausgewertet. Seid also achtsam, was ihr da hineinschreibt!

JavaScript fügt eurer Seite dynamische Funktionen hinzu. Seine Ausgabe muss ebenfalls semantisches HTML und CSS sein, wenn es das DOM verändert. JavaScript selbst ist kein Problem für die Zugänglichkeit, nur bestimmte Verhaltensweisen, die daraus resultieren, können es sein, wie z. B. der Verlust des Tastaturfokus oder Popups, die keine vernünftige Steuerung haben.

Je besser ihr die drei Konzepte voneinander trennt, desto wartbarer wird euer Code sein. Packt CSS in seine eigenen Dateien und bettet es nicht ins HTML ein. Genauso gehören JS-Module in eigene Dateien und nicht in den HTML-Code „hineingeschmiert“. Diese klare Trennung erinnert euch dann auch daran, dass die Konzepte ganz klar getrennt gehören und lediglich zusammenarbeiten, anstatt eine undurchdringliche Masse zu bilden.

Farbkontraste 🔗

Habt ihr schon mal im grellen Sonnenlicht gestanden und euch gewundert, warum ihr etwas auf einer Webseite nicht auf eurem Smartphone oder Tablet lesen konntet, das ihr in der Hand hieltet? Ihr wurdet das Opfer von einem zu geringem Kontrast zwischen der Vorder- und Hintergrundfarbe. Zu geringe Farbkontraste führen in starkem Umgebungslicht zu einer schlechten Lesbarkeit. Für die immer älter werdende Bevölkerung, aber auch für Sehbehinderte, bedeuten zu geringe Kontraste eine fast unüberwindbare Hürde. Die Richtlinien zur Zugänglichkeit von Webinhalten des W3C (WCAG 2.0) verlangen als Erfolgskriterium ein Kontrastverhältnis von 4,5:1. Ihr könnt Tools wie den Colour Contrast Analyser verwenden, um zu ermitteln, ob eure visuelle Darstellung dieses Kriterium erfüllt. Selbst wenn ihr nicht für die Erfüllung der WCAG- oder BITV2-Kriterien entwickelt, ist es eine gute Idee, dieses Kontrastverhältnis einzuhalten. Eure Augen und die vieler anderer Besucher eurer Webseite werden es euch danken!

Rettet die Ziehen-zum-Zoomen-Geste 🔗

Wenn ihr für Mobilgeräte entwickelt – und heute ist dies sehr wahrscheinlich -, bitte behaltet die Ziehen-zum-Zoomen-Geste bei! Wenn ihr diese nämlich abklemmt, wird dies Lesbarkeitsprobleme für viel mehr eurer Besucher nach sich ziehen, als ihr es euch vorstellen könnt! Das betrifft nicht nur ältere Besucher oder solche mit einer Sehbehinderung. Fast jeder wird im Laufe seines oder ihres Lebens eine Webseite zoomen wollen, weil die Schrift zu klein ist oder die Lichtverhältnisse es erfordern. Sollte euer jetziges Layout mit dem Zoomen nicht zurechtkommen, verwendet bitte die Zeit darauf, diese Probleme zu beheben und euer Layout echt responsive zu machen.

OK, aber was ist mit Widgets für Fortgeschrittene? 🔗

Wenn ihr tatsächlich Widgets bauen müsst, die es in HTML noch nicht gibt, müsst ihr Sorge dafür tragen, dass ihr sämtliche Rollen, Zustände, Tastaturnavigation und sonstige Kriterien für diese Widgets implementiert. Für die folgenden Themen gibt es weiterführende, allerdings englischsprachige, Materialien im Web:

Es liegt alles an der Semantik 🔗

Wie inzwischen klar geworden sein sollte, bringt schon der richtige Einsatz der vorhandenen HTML-Elemente die Zugänglichkeit auf über 80, wenn nicht sogar über 90 Prozent. Alles weitere ist dann noch ein bisschen Styling und JavaScript, wenn es irgendwo hakt.

Nur wenn es tatsächlich darum geht, sehr angereicherte Widgets zur Verfügung zu stellen, die nicht Teil des HTML-Standards sind, müsst ihr euch mit weiterführenden Standards wie WAI-ARIA beschäftigen. Aber selbst dessen erste Regel ist: Verwendet es nicht, wenn ihr nicht unbedingt müsst. Einfach alles mit WAI-ARIA-Attributen, die man per Zufall bei Google findet, zu übergießen, macht mehr kaputt als es hilft. Versprochen!

Schlussbemerkungen 🔗

Wenn es eines gibt, das ich mir für 2016 von der Webentwickler-Gemeinde wünsche, ist es dieses: Seid gute Bewohner des Web und lernt ordentliches HTML und CSS, bevor ihr überhaupt daran denkt, eines der vielen JavaScript-Frameworks anzufassen! Diese Frameworks sind alle ohne Zweifel sehr mächtig und bieten tolle Funktionen; bevor ihr aber hunderte Kilobytes an JavaScript-Code einbindet, um ein Element klickbar zu machen, prüft doch lieber, ob ein einfaches button Element es nicht auch genauso gut oder sogar besser kann!

Verwendet die richtige Semantik und erspart euch so jede Menge Arbeit! Denn alle Standardelemente liefern die Zugänglichkeit schon frei Haus mit!

Gebt euer Wissen weiter! Wenn ihr gutes HTML und CSS sprecht, teilt euer Wissen mit anderen! Bringt euch ein, teilt euer Wissen und eure Erfahrung! Ihr werdet mit jeder Beteiligung an einem Projekt oder einer Diskussion immer mindestens zwei mehr Leuten helfen als denen, die offensichtlich sind.

Und wenn ihr wirklich ganz tief in die Materie einsteigen wollt, empfehle ich euch noch dieses Buch von Jan Eric Hellbusch und Kerstin Probiesch: Barrierefreiheit verstehen und umsetzen: Webstandards für ein zugängliches und nutzbares Internet (Amazon Partnerlink), oder auch in unseren Kreisen gern „die Bibel“ genannt. 😉 Da steht wirklich so ziemlich alles drin, was man übers Thema lernen kann.

Ich hoffe, dass dieser Artikel zeigen konnte, wie einfach es ist, über 80, wenn nicht sogar über 90 Prozent Zugänglichkeit von Webseiten allein dadurch zu erreichen, dass man semantische Regeln und Webstandards einhält. Ihr seid herzlich eingeladen, eure Gedanken hierzu in den Kommentaren unten zu teilen! Und sollte ich etwas übersehen haben, was eurer Meinung nach unbedingt in diese Liste gehört, lasst es mich gern wissen, und ich füge es hinzu.

Vielen Dank!

Updates 🔗

  • Autoren für den Artikel „Benimmregeln für Datentabellen“ korrigiert.
  • Den Aufzählungspunkt zum placeholder-Attribut abgeschwächt und ergänzt.