Zum Neuen Jahr haben viele Menschen bekanntlich eine Menge guter Vorsätze. Ich auch. Mein neuester guter Vorsatz ist, endlich nicht mehr nur über Barrierefreiheit zu schreiben, sondern diese Seiten hier endlich selbst barrierefrei zu gestalten. Oder zumindest weitgehend barrerefrei. Oder zumindest so weit es möglich ist, ohne meine Blogsoftware (Expression Engine) umzuschreiben. Der beste Anfang scheint mir eine kleine Bestandsaufnahme: was ist schon barrierefrei an diesen Seiten und wo muss ich noch nachbessern.
Ich richte mich dabei nach den Richtlinien der BITV, der Barrierefreien Informationstechnik Verordnung, niedergelegt in der »Anlage 1« und am einfachsten nachzulesen bei »Barrierefreies Webdesign«. Leider verwendet diese Verordnung nicht immer die eigentlich geforderte Leichte Sprache
, so dass noch einiges an Recherche und Rätselraten angesagt ist. Aber eines nach dem anderen, zuerst die komplette Übersicht. Die Bereiche, in denen ich aktiv werden muss, haben einen gelben Hintergrund.
| Rubrik | Beschreibung der Anforderungen | Derzeitiger Ist-Zustand meiner Seiten | |
|---|---|---|---|
| 1. | Kategorie 1: Äquivalente Inhalte | ||
| 1.1 | Äquivalenter oder alternativer Text für Bilder, Platzhalter und so weiter. | OK, verwende ich durchgehend. | |
| 1.2 | Redundante Links für Serverseitige Imagemaps | OK, Imagemaps verwende ich nicht. | |
| 1.3 | Audio-Beschreibungen für Videospuren | Ich biete keine Videos an; falls doch irgendwann, dann wäre das aber schwer bis unmöglich zu erfüllen. | |
| 1.4 | Untertitel / Audiobeschreibungen für Animationen | OK, ich biete keine Animationen an. Bei Animationen sind Untertitel eher zu realisieren als bei Videos, aber ein Problem wäre es schon. | |
| 1.5 | Redundante Hyperlinks für Clientseitige Imagemaps. | OK, Imagemaps verwende ich nicht. | |
| 2 | Kategorie 2: Farbe und Kontrast | ||
| 2.1 | Alle Informationen müssen auch ohne Farbe verständlich sein. | OK, ein Test über eine S/W-Darstellung zeigt, dass alle Informationen noch vorhanden sind. | |
| 2.2 | Ausreichender Farbkontrast bei Bildern. | OK, das ist kein Problem. Bilder sind bei mir kein wesentliches Informationsmedium. | |
| 2.3 | Ausreichender Farbkontrast bei Texten | Der Kontrast zwischen grünem Text und hellgrünem Hintergrund ist vermutlich problematisch. Bei S/W Darstellung ist alles aber noch ganz gut lesbar. | |
| 3 | Kategorie 3: Verwendung von korrektem Markup und CSS | ||
| 3.1 | Angemessene Markupsprache | OK, die Seiten validieren zu XHTML 1.0 Transitional (wenn ich keine Fehler bei der Eingabe des Inhalts mache, heisst das …). Das CSS validiert auch. | |
| 3.2 | Markup muss validieren | OK, ist der Fall, zumindest bei den meisten Einträgen. HTML-Fehler kommen allerdings manchmal in den Beiträgen vor. | |
| 3.3 | Gestaltung durch Stylesheets | OK, was anderes verwende ich in der Regel nicht mehr. | |
| 3.4 | Relative Größenangaben | OK, die Seiten sind in allen Browsern zoombar. | |
| 3.5 | Semantisches Markup | OK, mache ich konsequent, schon wegen der Suchmaschinen. | |
| 3.6 | Listenelemente verwenden. | OK, setze ich konsequent ein. | |
| 3.7 | Zitate durch korrektes Markup kennzeichnen. | FEHLT. Das muss ich nachbessern; bisher beschränke ich mich auf Anführungen, das reicht nicht. | |
| 4 | Kategorie 4: Sprachliche Besonderheiten kennzeichnen | ||
| 4.1 | Wechsel der Sprache kennzeichnen | FEHLT. Darauf habe ich bisher nicht geachtet; das ist viel Arbeit, und man muss beim Erstellen des Inhaltes auf immer mehr achten. | |
| 4.2 | Abkürzungen und Akronyme kennzeichnen | FEHLT. Aber es gibt für Expression Engine eine Erweiterung, die das anbietet. Muss ich testen. | |
| 4.3 | Standardsprache kennzeichnen | OK, das passiert ja über das Markup schon. | |
| 5. | Kategorie 5: Korrekte Behandlung von Tabellen | ||
| 5.1 | Für Zeilen- und Spaltenüberschriften korrektes Markup verwenden. | OK, das mache ich immer schon. | |
| 5.2 | Tabellen mit zwei oder mehr logischen Ebenen: Verknüpfung von Tabellenzellen und Tabellenüberschriften mit den entsprechenden Attributen. | Verwende ich derzeit nicht – falls es irgendwann fällig wird, wartet mächtig viel Arbeit auf mich. | |
| 5.3 | Tabellen nicht für die Text- und Bildgestaltung verwenden. | OK, das ist eh klar. | |
| 5.4 | Keine Strukturelemente für visuelle Formatierungen verwenden | Heisst, man soll das HTML-Markup nicht für reine visuelle Darstellung missbrauchen. Das ist seit CSS auch nicht mehr nötig. | |
| 5.5 | Zusammenfassungen zur Verfügung stellen. | OK, das ist über das summary-Attribut im table-Tag ohne weiteres möglich. | |
| 5.6 | Für Überschriftenzellen Abkürzungen zur Verfügung stellen. | OK, das ist sinnvoll und ohne Aufwand möglich. | |
| 6. | Kategorie 6: Nutzbarkeit mit älteren Technologien | ||
| 6.1 | Lesbarkeit ohne Stylesheets | OK. Das ist bei korrektem Markup ohnehin gegeben. | |
| 6.2 | Äquivalente Texte für dynamischen Inhalt müssen mit dem Inhalt wechseln. | OK, ich biete keinen dynamischen Inhalt. | |
| 6.3 | Verwendbarkeit, auch wenn Skripts und Applets nicht aktiv sind | OK, das ist aus Sicht der Usability schon selbstverständlich. | |
| 6.4 | Eingabebehandlung bei Skripts oder Applets muss von Eingabegerät unabhängig sein. | OK, verwende ich ohnehin nicht. | |
| 6.5 | Dynamische Inhalte müssen zugänglich sein. | OK, biete ich eh nicht an. Falls ich das doch irgendwann mache, wird es wieder sehr aufwändig, da gerade dynamische Inhalte sehr schwer zugänglich zu machen sind. | |
| 7. | Kategorie 7: Zeitgesteuerte Inhalte müssen durch den Nutzer steuerbar sein. | ||
| 7.1 | Kein Bildschirmflackern | OK, das nervt eh. | |
| 7.2 | Kein blinkender Inhalt. | OK. | |
| 7.3 | Bewegung ist zu vermeiden, oder es sind Hilfsmittel zum Beenden der Bewegung anzubieten. | OK. Allerdings gibt es genügend Browser oder Browser-Plugins, die das mittlerweile anbieten, so dass das eigentlich keine wichtige Forderung mehr ist. | |
| 7.4 | Keine automatischen oder periodischen Aktualisierungen der Seiten | OK, in meinem Fall kein Problem. Manchmal aber ist gerade das erwünscht … | |
| 7.5 | Keine automatischen Weiterleitungen | OK, schon wegen den Suchmaschinen nicht. | |
| 8. | Eingebettete Objekte müssen zugänglich sein. | ||
| 8.1 | Applets müssen zugänglich sein. | OK, verwende ich eh nicht. Mag ich persönlich nicht. | |
| 9. | Alle Funktionen müssen unabhängig vom Ein- oder Ausgabegerät nutzbar sein. | ||
| 9.1 | Clientseitige Imagemaps verwenden statt serverseitige. | OK, ich verwende keine Imagemaps. (Ich verstehe nicht so ganz, warum sie da mehrmals darauf hinweisen. ) | |
| 9.2 | Jedes eingebettete Element muss geräteunabhängig bedient werden können. | OK (was auch immer das heisst … das muss ich genauer recherchieren. ) | |
| 9.3 | In Skripts logische statt geräteabhängige Eventhandler verwenden | OK, ich verwende keine Skripts. Ganz klar ist mir der Punkt allerdings noch nicht. | |
| 9.4 | Logische Tabulatorreihenfolge für Links und Formularfelder. | Darauf verzichte ich, gemäß den Empfehlungen bei www.einfach-fuer-alle.de. Die Standardreihenfolge des Tabulators funktioniert in Safari perfekt. In Firefox nicht, er erkennt die Links nicht bzw. springt nur auf die Formularfelder. Was kann man hier machen? | |
| 9.5 | Tastenkürzel für Links und Formularfelder zur Verfügung stellen. | Darauf verzichte ich, gemäß den Empfehlungen bei www.einfach-fuer-alle.de. | |
| 10. | Kategorie 10: Unterstützung veralteter assistiver Techniken | ||
| 10.1 | Keine Popup-Fenster verwenden. Bei einem Wechsel der Ansicht ist der Benutzer zu informieren. | Popup-Fenster verwende ich nur für Bilder, hier sind sie nicht zu vermeiden. Allerdings sollte ich im title-Attribut darauf hinweisen. | |
| 10.2 | Korrekt positionierte Beschriftungen von Formularfelder | OK, das ist selbstverständlich. Allerdings verwende ich das label-Tag noch nicht immer korrekt. Das muss ich noch ausbessern. | |
| 10.3 | Bei Tabellen mit Text in parallelen Spalten mit Zeilenumbruch ist alternativ linearer Text zur Verfügung zu stellen. | Das verstehe ich nicht … (Wo ist die einfache Sprache in der BITV?) | |
| 10.4 | Platzhalterzeichen in Eingabefeldern | Das halte ich für problematisch – würde ich nur machen, wenn ein JavaScript das Feld entleert, sobald es den Fokus bekommt. Sonst wird dieser Text eher zu einem Hindernis, als dass er hilft. | |
| 10.5 | Hyperlinks durch druckbare Zeichen trennen. | Noch nicht der Fall. Ich möchte meine Links und Menüs noch nach den Richtlinien von www.einfach-fuer-alle.de ausbauen. | |
| 11. | Kategorie 11: Dokumentierte Technologien verwenden | ||
| 11.1 | Öffentlich zugängliche und dokumentierte Technologien verwenden. | OK, das ist über XHTML und CSS automatisch gegeben. | |
| 11.2 | Veraltete Technologien vermeiden | OK, kein Problem. | |
| 11.3 | Wenn nicht anders möglich, dann als Alternative zusätzlich eine barrierefreie Seite anbieten. | Hier sicher nicht nötig. | |
| 11.4 | Die Benutzer sollten die Möglichkeit bekommen, Dokumente nach seinen Präferenzen zu erhalten. | Wäre generell wünschenswert, aber hier würde ich für barrierfreie Angebote nicht mehr Aufwand treiben als für das Standardangebot. Es muss reichen, die Möglichkeiten der Browser und Lesegeräte zu unterstützen und vor allem nichts zu verhindern, oder durch ein Übermaß zu komplizieren. Jeder Benutzer richtet sich seine Software von vorneherein so ein, wie er sie braucht. | |
| 12. | Informationen zur Orientierung | ||
| 12.1 | Jeder Frame muss mit einem Titel versehen werden. | OK, ich verwende keine Frames, schon wegen der Suchmaschinen. | |
| 12.2 | Zweck der Frames muss beschrieben werden. | OK, ergibt sich dann … | |
| 12.3 | Große Informationsblöcke sind mittels Markup in kleine Einheiten zu unterteilen. | OK, das mache ich wohl in ausreichendem Maße. | |
| 12.4 | Beschriftungen sind genau den Kontrollelementen zuzuordnen. | Insgesamt kein Problem, aber damit sind auch die label in Formularen gemeint. Das setze ich noch nicht konsequent um. | |
| 13. | Kategorie 13: Navigationen sind übersichtlich zu gestalten | ||
| 13.1 | Ziel eines Links muss eindeutig identifizierbar sein. | OK, entweder über den Linktext oder über das title-Attribut mache ich das bereits. | |
| 13.2 | Meta-Daten anbieten für semantische Informationen. | OK, zum Beispiel über META-Tag, title-Attribute etc. Ich denke, das mache ich in ausreichendem Maße. | |
| 13.3 | Inhaltsverzeichnis oder Sitemap anbieten. | Das fehlt noch. Ist natürlich generell eine gute Idee, aber viel Arbeit. | |
| 13.4 | Schlüssige und nachvollziehbare Navigation | OK, das stimmt glaube ich. | |
| 13.5 | Hervorgehobene Navigationsleisten zur Verfügung stellen | Noch nicht richtig, da die Hervorhebung derzeit ausschließlich visuell erfolgt. Aber wenn ich die Barrierefreien Menüs umsetze, wird sich das von alleine ergeben. | |
| 13.6 | Links in Gruppen zusammenfassen und einen Mechanismus anbieten, mit dem die Gruppen übersprungen werden können. | Noch nicht vorhanden; wird aber mit den barrierefreien Menüs erfolgen. | |
| 13.7 | Soweit eine Suche vorhanden ist, sollte diese unterschiedliche Zugänge erlauben. | Derzeit biete ich keine Suche – insofern betrifft es mich (noch) nicht. Wobei ich auch hier nicht so ganz verstehe, was damit gemeint ist. | |
| 13.8 | Aussagekräftige Informationen am Anfang von inhaltlich zusammenhängenden Informationsblöcken zur Verfügung stellen. | Mir ist unklar, was damit gemeint ist. Vermutlich sollte eine kurze Zusammenfassung vor dem eigentlichen Artikel stehen. Das ist bei den meisten Blog-Beiträgen ja der Fall. Solche Forderungen sind schon problematisch – unter einem idealen Blickwinkel schon wichtig, aber oft nicht mir vertretbarem Aufwand zu leisten. | |
| 13.9 | Wenn zusammengehörige Informationen auf mehreren Seiten angeboten werden, muss eine Zusammenstellung angeboten werden. | Damit sind wohl Themenlisten und Verlinkungen gemeint. OK, das versuche ich zu realisieren, obwohl Expression Engine leider keinerlei Hilfen dazu anbietet, wenn man mehrere Blogeinträge in einer Übersicht beziehungsweise zu einer Artikelfolge zusammenfassen will. | |
| 13.10 | Mechanismen zum Umgehen von ASCII-Zeichnungen müssen bereitgestellt werden. | OK (etwas kuriose Forderung … aber für Screenreader sind ASCII-Zeichnungen wohl ziemlich tödlich.) | |
| 14. | Allgemeines Verständnis fördern | ||
| 14.1 | Klarste und einfachste Sprache | Ich gebe mir Mühe … Aber es ist nicht immer möglich und manchmal auch nicht sinnvoll. | |
| 14.2 | Text sollte mit audiovisuellen Präsentationen ergänzt werden, soweit dies das Verständnis fördert. | Ziemlich idealistischer Wunsch … aber soweit es mir möglich ist, versuche ich das. | |
| 14.3 | Der Präsentationsstil ist durchgängig durchzuhalten | OK, das ist wieder kein Problem. | |
Von Peter am 29.12 um 18:47 Uhr. Kategorie: HTML-CSS | Barrierefreiheit | Lisardo-intern
Trackback-URL: http://www.lisardo.biz/trackback/153/idX4oUIe/