sprungmarker testet

Schlagwort: JAWS

Mit Screenreadern testen (1): Zitatauszeichnung

veröffentlicht am

Semantik in HTML ist ja etwas Wunderbares, interessant wird es, wenn man sich die Interpretation durch Screenreader genauer ansieht. Bei meiner Recherche zur Technikwürze zum Thema Formulare hatte ich schon an der einen oder anderen Stelle aufgehorcht. Immer mal wieder war mir nicht klar, habe ich die Semantik in HTML unzureichend gesetzt oder liegt es an der Kombination von Screenreader und / oder Browser / System. Daher werde ich jetzt in loser Folge semantische Auszeichnungen in Screenreadern testen. Den Anfang macht die Auszeichnung von Langzitaten – blockquote -, von Kurzzitaten mit Hilfe des q-Elementes und die jeweilige Zuordnung zur zitierten Quelle – cite.

Screenreader und Zitate: das Gesamtergebnis

Um gleich mit der argumentativen Tür ins Haus zu fallen: Es sieht durchwachsen aus mit der Ausgabe von Zitaten – nur Langzitate werden standardmäßig vorgelesen – aber auch nicht immer. Leider muss man sagen, die gesamte Semantik eines Artikels geht dann doch verloren. Der Weg kann nicht sein, jedes Zitat als blockquote-Element umzusetzen . Vor allem wenn man bedenkt, wie alt die semantische Auszeichnung von Zitaten ist. Die Verwendung reicht quasi ins HTML-Urgestein zurück: Kleine Geschichte des blockquote-Elements anhand der Spezifikationen.

Weiterlesen „Mit Screenreadern testen (1): Zitatauszeichnung“

Kurz kommentiert: Einfach-teilhaben.de im Usability-Test mit Menschen mit Behinderungen

veröffentlicht am

Die Agentur Aperto hat für das Bundesministerium für Arbeit und Soziales einen Usability-Test mit Menschen mit Behinderungen durchgeführt und die Webseite einfach-teilhaben.de aufgabenorientiert benutzen und bewerten lassen. Die Ergebnisse wurden nun online präsentiert: Einfach-teilhaben.de im Usability-Test mit Menschen mit Behinderungen.

In unserer barrierefreien Arbeit fehlen uns immer praktische Daten. Der herkömmliche Kontext ist ja, dass wir als Entwickler die ersten Nutzer sind, dann geht noch der Controller ran, danach der Kunde und irgendwann nach Launch der eigentliche Nutzer. Hat der Kunde noch Feedbackschleifen eingebaut, erhalten wir wieder von den Nutzern Rückmeldungen, wenn sie mit der Benutzung der Webseite Schwierigkeiten haben. Das hört sich oftmals dann eher sehr allgemein an, unsere Aufgabe ist es dann, diese allgemeinen Aussagen zu überprüfen, die Schwierigkeiten zu finden – das heißt immer so schön debuggen -, den Aufwand zu schätzen und dann wieder in die Entwicklungsschleife einzubinden. Das ist quasi der 08/15 Prozess bei den meisten Agenturen.

Weiterlesen „Kurz kommentiert: Einfach-teilhaben.de im Usability-Test mit Menschen mit Behinderungen“

[extern] Technikwürze – Formulare total 1+ 2

veröffentlicht am

Sascha Postner und Daniel Jagszent formulieren es treffend: Auf jeder Webseite sind sie zu finden – Formulare. Und so ist eine richtige Technikwürze daraus geworden: In der ersten Sendung Formulare total 1 geht es vor allem um Usabililty und Design von Formularen, in der zweiten Sendung Formulare total 2 (Barrierefreie Formulare) haben wir uns die Formulare mal ausführlich aus der barrierefreien Perspektive angesehen.

Sascha Postner sprach mich vor einiger Zeit an, ob wir nicht eine Spezialsendung zu Formularen machen sollten. Daniel Jagszent hat sich spontan dazugesellt. Für mich diesmal – weil bald klar war, dass das Thema für eine Sendung zu umfangreich ist – recht intensive Vorarbeit für zwei Sendungen. Für Sendung 1 zur Usability von Formularen hatten wir uns vor allem auf die drei in den letzten zwei Jahren erschienen Bücher von Luke Wroblewski (Web Form Design), Jarrett und Gaffney (Forms that work) und Featherstone, Connell und Bolton (Fancy Form Design) konzentriert. Für Sendung 2 zur Barrierefreiheit von Formularen habe ich mir einen zugleich festen und offenen Rahmen vorgenommen: Es sollten die klassischen Standards für barrierefreie Formulare abgehandelt werden, aber auch – weil mir das immer wichtig ist, einen Schritt über meinen eigenen Tellerrand zu gehen – Aktuelles und Neues einzuarbeiten wie das WCAG 2, einen Ausblick auf HTML 5 und WAI–ARIA zu machen. Selbst für mich war das mitunter halb Neuland und halb Glaskugel. Um dem auditiven Medium gerecht zu werden und weil Beispiele ja unterstützen, habe ich einige Screenreader-Beispiele mit JAWS und NVDA erstellt.

Weiterlesen „[extern] Technikwürze – Formulare total 1+ 2“

Sprachauszeichnung auch hinfällig?

veröffentlicht am

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?“

Screenreader: Tastaturkürzel

veröffentlicht am

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.

Weiterlesen „Screenreader: Tastaturkürzel“

Wie soll in Formularen das LEGEND-Element optimiert werden? – Web Access Centre Blog

veröffentlicht am

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.

Webumfrage zu JAWS

veröffentlicht am

Michael Vogt initiiert eine Umfrage (via Access for all) zu JAWS und anderer assistiver Technologie.

Zum einen wird befragt, welche assistive Technologie man benutzt und auf JAWS bezogen, wie man ihn nutzt und wie es mit der Anwendbarkeit aussieht. Im Grunde ein gutes Anliegen – ich fürchte auch, Umfragen zu diesem Thema sind eher selten – aber: warum ist die Umfrage selbst so nutzerunfreundlich gestaltet, nicht mal der Tabindex funktioniert. Die Umfrage ist wohl mit dem Programm Microsoft SharePoint entwickelt und, wenn man in den Quellcode geht, die Formulare bestehen nur aus Skripten. Aber vielleicht kommen ja andere damit besser zurecht. 🙂

Wie lang kann ein ALT-Attribut sein?

veröffentlicht am

Wie lang kann ein ALT-Attribut sein?

Eine interesante Frage. HTML selbst macht hier wohl keine Einschränkungen, aber aus Sicht der Barrierefreiheit wirft das Probleme auf: So lässt etwa der Screenreader JAWS 6.x nur jeweils Pakete von 125 Zeichen zu, die werden dann auch einzeln vorgelesen, was inhaltlich zu Verwirrung führen kann. Im Grunde sollte das ALT-Attribut ohnehin so knapp wie möglich gehalten werden und nur eine Alternative für das Bild bieten. (Quelle: How long can an „alt“ attribute be? – Access IT)