sprungmarker testet

Sprachauszeichnung auch hinfällig?

Wir leben in barrierefreien Zeiten mit immer weniger Todos, möchte man meinen. Nun ist die Sprachauszeichnung an der Reihe.

Acess for all wirft die Frage in Sprachwechsel im Web auf, ob es sinnvoll ist, jeden Wechsel der Sprache im Text auszuzeichnen. Es werden zwei Beispieldateien eines Textausschnittes angeführt, der mit JAWS vorgelesen wird, mal schneller mal langsamer. Abgesehen davon, dass die schnelle Geschwindigkeit für mich keinerlei Verständnis erzeugt, was, wie ich glaube, nicht an der gehäuften Sprachauszeichnung liegt – es ist schlicht zu schnell, finde ich das langsamere Beispiel völlig im Rahmen.

Weiterlesen „Sprachauszeichnung auch hinfällig?“

Barrierefreie PowerPoint-Dateien: Web Access Centre Blog

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.

Formulare: wie werden Buttons optimal positioniert

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“

CSS-Dateien richtig dokumentieren: CSSDOC

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?

WYSIWYG Editoren im Barrierefreiheits-Test (Standards Schmandards)

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.

Was sie schon immer über Drop-down Menüs wissen wollten (Message Web Design)

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.

Welche Ausreden lassen sich noch finden …

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. 😉