Was ist ein guter Standard?
Google-Anzeigen
Zugänglichkeit
Der Begriff »Zugänglichkeit« beschreibt hauptsächlich das Maß, inwiefern etwas zugänglich für Menschen mit Behinderungen ist, aber im weitesten Sinne bemisst er ebenfalls die Beständigkeit gegenüber externen oder temporären Behinderungen, wie zum Beispiel eine laute Umgebung oder schlechte Beleuchtung.
Die beste Methode, Zugänglichkeit zu gewährleisten, ist, Daten in der höchstmöglichen Abstraktionsstufe zu kodieren, aber darüber hinaus ist es ebenfalls wichtig, auf bereits existierende Zugänglichkeits-Technologien zu setzen.
Die Aufteilung in Struktur und Styling ist ein gutes Beispiel: statt einfach nur zu beschreiben, dass etwas rot ist, erlauben W3C-Formate einem Autor (und sie legen es ihm auch nahe), zunächst zu beschreiben, warum etwas rot ist. Die Färbung an sich ist der nächste Schritt. In HTML zum Beispiel schreibt ein vorsichtiger Autor eher <em class="warning"> als <font color="red"> und definiert in einem Stylesheet, dass Warnungen rot dargestellt werden sollen. Wenn nun jemand keine Möglichkeit hat, Rot darzustellen (oder zu sehen), hat er zumindest eine Chance, sich auf eine andere Art und Weise warnen zu lassen (zum Beispiel durch ein entsprechendes Geräusch).
In XML-basierten Formaten, vor allem in wohlgeformten, sollte das Problem geringer als bei HTML ausfallen. Im Gegensatz zu einigen HTML-Versionen verfügen die meisten XML-Formate über keine Styling-Elemente. In solchen Formaten sieht man vielleicht Elemente wie <warning>, nicht jedoch <font>, daher ist ein Stylesheet obligatorisch.
Manchmal kann eine gesamte Technologie als Einrichtung zum Zweck der Zugänglichkeit betrachtet werden. SVG hat viele Vorteile gegenüber Rastergrafiken, aber ein besonders wichtiger Punkt ist, dass die Grafik auseinander genommen und als eine Hierarchie von Objekten durchlaufen werden kann, eher als eine Zusammenstellung von farbigen Pixeln. Man kann eine SVG-Grafik lesen, und zwar umso besser, je mehr Beschreibungen zu jedem Objekt der Autor eingefügt hat.
Macht es nicht mehr Arbeit, zugängliche Ressourcen zu erstellen? Werden Menschen nicht faul sein und sich Struktur und Kommentare sparen? Nicht immer. Einige wollen gute Arbeit abliefern. Einige werden dazu verpflichtet (gesetzlich oder durch das öffentliche Image ihres Arbeitgebers). Aber ein weiterer Grund ist, dass korrekt strukturierter und kommentierter Code einfacher zu warten ist; Zugänglichkeit ist manchmal eine Investition mit anfänglich großen Kosten, aber letzten Endes profitiert man davon. In wohldurchdachten Formaten stellen die Funktionalitäten der Zugänglichkeit keine nachträglichen Ergänzungen dar, sondern sind Teil der Funktionen für die Wartbarkeit und der Struktur des Quelltextes. Eine SVG-Grafik kann analysiert und deren Bestandteile dazu wiederverwendet werden, um eine neue Grafik zu erzeugen. Bei einer PNG-Grafik hingegen ist das Ende der Fahnenstange erreicht.
Die Attribute alt und longdesc des HTML-Elements img waren eine nachträgliche Ergänzung. Deswegen hat man das Gefühl, es bedeutet zusätzliche Arbeit, an ein alt-Attribut (= alternatives Attribut) zu denken. Und wenn man sich ein gutes Attribut überlegt hat, ist es aufgrund der Beschränkungen von HTML-Attributen vielleicht nicht möglich, es umzusetzen: keine Möglichkeit, ein Wort innerhalb des alternativen Attributes zu betonen, keine Möglichkeit, eine Liste oder Tabelle anzugeben und so weiter.
Das img-Element wurde in HTML eingeführt, ohne über Zugänglichkeit (oder, wenn wir schon dabei sind, über Dinge wie zum Beispiel Ausweichlösungen und Bildüberschriften) nachzudenken, und die Alternativen, die vorgeschlagen wurden, fig und object, kamen einfach zu spät und haben sich niemals wirklich durchgesetzt. Funktionalitäten der Zugänglichkeit müssen von Beginn an integriert werden, sowohl in den Spezifikationen als auch in den Werkzeugen, die sie implementieren.
Siehe auch
- [ATAG1.0]
- Treviranus, Jutta; McCathieNevile, Charles; Jacobs, Ian; Richards, Jan. Authoring tool accessibility guidelines 1.0. 3. Feb 2000. W3C Recommendation. URL: http://www.w3.org/TR/2000/REC-ATAG10-20000203/
- [UAAG1.0]
- Gunderson, Jon; Jacobs, Ian. User agent accessibility guidelines 1.0. 10 Mar 2000. W3C Proposed Recommendation (draft). URL: http://www.w3.org/TR/2000/PR-UAAG10-20000310/
- [WCAG1.0]
- Chisholm, Wendy; Vanderheiden, Gregg; Jacobs, Ian. Web content accessibility guidelines 1.0. 5 May 2000. W3C Recommendation. URL: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/
- [XMLGL]
- Dardailler, Daniel. XML accessibility guidelines. 17 Feb 2000. W3C Note (draft). URL: http://www.w3.org/2000/02/NOTE-xmlgl-20000217.html
- Vorherige Seite: Modularität
- Nächste Seite: Redundanz
Übersicht
Warum enthält HTML keine Tags fürs das Styling? Warum kann man in SMIL keinen Text einfügen? Warum enthält CSS keine Befehle zur Transformation eines Dokuments? Warum, kurz gesagt, modularisiert das W3C seine Spezifikationen und warum auf genau diese Art und Weise? Dieser Essay versucht, zu erläutern, was die Entwickler in den verschiedenen W3C-Arbeitsgruppen meinen, wenn sie von Begriffen wie Effizienz, Wartbarkeit, Zugänglichkeit, Erweiterbarkeit, Erlernbarkeit, Einfachheit oder Langlebigkeit reden.