Curb Cut hat eine kleine Liste erarbeitet: Where to Discuss Accessbility.
An wende ich mich, wenn ich dringende Fragen zur Barrierefreiht habe? Curb Cut hat eine Liste für den englischsprachigen Bereich erarbeitet. Aber auch ich nutze einige dieser genannten Quellen, wie etwa das Accessify Forum.
In Reading and presenting with PowerPoint if you are a screen reader user zeigt der Web Access Centre Blog (via Accessify), wie man seine PowerPoint Dateien barrierfrei gestaltet.
Dort treten die bekannten Probleme auf: Bilder müssen mit Captions versehen, Text muss innerhalb eines Auto-Layouts (?) verwendet und Listen speziell formatiert – z.B. Listenelemente am Ende mit einem Punkt beendet werden.
Standards Schmandards testet für 2007 WYSIWYG Editoren auf Barrierefreiheit und Webstandards.
Erfreut stelle ich fest, dass TinyMCE nicht so schlecht abgeschnitten hat. Die Problematik mit verschachtelten Listen (denen man im übrigen auch keine wirkliche CSS-Klasse zuordnen kann) ist bekannt, ebenso das Manko, den Sprachwechsel nicht wirklich integriert zu haben. Interessant fand ich den Editor XStandard, der wohl alle Test bestanden hat. Seine Featureliste liest sich denn auch sehr auf den Bereich der Barrierefreiheit zugeschnitten. Interessant, werde ich mir mal ansehen.
Immer wieder schön zu lesen, dass andere vor ähnlichen Ausreden und Argumenten stehen: Top 5 Most Annoying Accessibility Excuses.
Am häufigsten sind die Aussagen zu hören, dass die Webseite ja nur im Intranet zu erreichen ist und dass sich bis dato niemand über die Webseite beschwert hätte. 😉 Auch sehr gut das Missverständnis aus einem Kommentar dazu: Der Kunde dachte, Erreichbarkeit bedeutet, dass die Webseite online erreichbar sei. 😉
Ein wenig klingt das ja noch wie aus dem Mittelalter: Barrierefreiheit und CMS. Hier das Beispiel – Joomla:
Dieser als Komponente installierbare Hack verändert die Ausgabe der wichtigsten Frontend-Dateien von Joomla! hinsichtlich eines semantisch korrekten Markups und sorgt damit für einen tabellenlosen HTML-Output.
Quelle: Teil 2 der Artikelserie „Access all Areas – Barrierefreies Webdesign“
Joe Dolson wirft wieder die Frage auf, wie vermittelt man dem Kunden das Thema Barrierefreiheit: Accessibility and Client Expectations. Selling Accessibility
Er zieht sich auf den Standpunkt zurück, dass Barrierefreiheit kein Zusatzmodul sei, dass man quasi als Add-on dazukaufen könne. Barrierefreiheit sei eine grundsätzliche Herangehensweise an eine Webseite.
Da ich Screenreader häufig sehr kurzfristig einsetze, verwechsle ich oft die je unterschiedlichen Tastaturkürzel.
Daher habe ich eine Liste erarbeitet mit Links und Informationen zu den häufigsten Screenreadern und deren Tastaturkürzeln bzw. auch deren Handbüchern.
Des Guten zu viel: in Too much accessibility – FIELDSET LEGENDS wird erklärt, warum Screenreader eine gut austarierte LEGEND in Formularen benötigen.
Auch welche Dinge sollte man achten und warum, wenn man in Formularen das LEGEND-Element befüllt. Weil Screenreader wie JAWS den Inhalt der LEGEND vor JEDEM LABEL-Element vorlesen, kann es, wie der Artikel gut an Beispielen erläutert, durchaus zu unsinnigen oder missverständlichen Inhalten kommen. Daher sollte der Inhalt der LEGEND vor allem knapp, relevant für jedes einzelne LABEL und im Textfluss immer noch verständlich sein.
Am besten, so der Vorschlag, sollte man sich schlicht den Inhalt der LEGEND am Schluss noch einmal laut vorlesen. Dann kann man rasch Fehler und Unstimmigkeiten erkennen. Bis dato ist mir nicht aufgefallen, dass JAWS das im Default-Fall nicht deaktiviert hat.
RAMsey startet eine neue Reihe und sieht sich Wahlkampfseiten auf ihre Zugänglichkeit an.
Bis dato sind das zwar nur schmale Tests, aber man sieht trotzdem schon schöne Ergebnisse wie eine fast leere Variante von Hillary Clintons Wahlkampfseite, sobald man die Bilder ausschaltet. 😉 Eine Reihe, die man verfolgen sollte.
Ja, zugegegeben. Die WCAG 1.0 Richtlinien und im Anschluss das BITV in ein Webprojekt umzusetzen, kann auch sehr viel Handarbeit erfordern. Es sich jedoch dadurch leichter zu machen, dass man einfach mal alle Punkte, die umstritten sind und meist auch noch zusätzliche Arbeit machen, wegzulassen, ist der falsche Ansatz.
Das Korrekturen-Papier der WCAG Samurai macht aber genau das.
Weiterlesen „WCAG Samurai machen es sich schlicht zu einfach“