sprungmarker testet
Ja, gut. Man kann auch alles in die Hand nehmen und auf Brauchbarkeit prüfen. So jetzt – unterstützt von Einfach für Alle – hatt es auch das LONGDESC-Attribut erwischt: The longdesc lottery.
Ja, sicherlich, ich habe dieses Attribut auch noch nie verwendet aber ….
Weiterlesen „LONGDESC-Attribut oder warum schaffen wir nicht HTML ganz ab“
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.
Luke Wroblewski & Etre haben eine kleine Studie gemacht: Primary & Secondary Actions in Web Forms. Die Fragestellung war, wie positioniert man am besten für den Nutzer die Buttons in Formularen.
Wichtig dabei ist der Unterschied zwischen primären und sekundären Buttons oder Aktionen. Als primäre Buttons werden jene bezeichnet, die zum Absenden, zum Vollenden des Formulars genutzt werden. Als sekundäre Aktion gelten Buttons wie etwa der Zurück-Button. Gerade die sekundären Aktionen bergen eine gewisse Gefahr ins sich, dass sie den Nutzer verwirren. Um die Positionierung dieser beiden Buttonsvarianten zu testen, wurde ein Test mit Eye-Tracking durchgeführt.
Weiterlesen „Formulare: wie werden Buttons optimal positioniert“
Ein interessantes Projekt, dass das CSSDOC-Team da aus der Taufe gehoben hat.
Mit Hilfe des PHP Dokumentationsstandards soll für CSS das Konzept des DocBlocks (Documentations Blocks, Kommentarblöcke) nutzbar gemacht werden, um damit eine bessere Strukturierung und Dokumentation – vor allem eine standardisiertere – zu erreichen.
Grundsätzlich ist das eine gute und interessante Sache, weil sie auf vorhandende Dokumentationstechniken aufbaut. Natürlich könnte man diese Blöcke, was die meisten ohnehin schon machen, mit CSS Kommentaren erreichen. Damit ist jedoch immer noch nicht die Problematik der Organisation von grossen CSS Dateien gelöst oder würde sich diese Problematik auch mit dem Konzept des DocBlocks angehen lassen?
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.
In Drop-down menues; no thanks! werden hinreichende Gründe aufgeführt, warum man keine Drop-down Menüs einsetzen sollte.
Abgesehen davon, dass die meisten Menüs dieser Art anstrengend zu bedienen, nicht immer standardkonform zu bewerkstelligen und noch schwerer barrierefrei zu erstellen sind, finde ich den Hinweis am wichtigsten, dass bei Anwendung von Drop-down Menüs das Navigationskonzept an sich hinkt. Mein Verdacht ist dabei, dass der Kunde das schlicht toll findet, sich aber sonst keine Gedanken zur Navigation gemacht hat.
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.