João Santos hat in AppleVis angekündigt, dass er einen Screenreader auf MacOS entwickelt mit dem Namen „Vosh“. Das Ziel ist, auf dem Mac einen Screenreader wie NVDA auf Windows zu haben.
Weiterlesen „Screenreader für den Mac – Vosh“
Schriftersetzung ist noch immer aktuell, wenn es sich um Lizenz- oder Darstellungsfragen dreht. Leider möchte man aus mehreren Gründen sagen: Zum einen sind mit dem verstärkten Einsatz von font-face alternative Schriftersetzungs-Lösungen fast obsolet geworden und, entwickelt man im Hinblick auf Barrierefreiheit, waren diese alternativen Lösungen nie wirklich eine Option.
War früher in Sachen Schriftersetzung sIFR Marktführer, übernahmen später Javaskript-basierte Lösungen die Führung. Die bekanntesten sehen wir uns nun im Hinblick auf Barrierefreiheit genauer an: cufón, typeface.js und eine Methode der Schriftmanipulation – lettering.js.
Weiterlesen „Was ist mit cufón, typeface.js oder lettering.js?“
Seit kurzem habe ich die Möglichkeit, turnusmäßig und dann geblockt Einführungsvorträge zur Barrierefreiheit zu halten. Das ist ziemlich spannend. 🙂
Es war zwar ein kleines Hauruck-Unternehmen, weil der erste Vortrag sehr knapp terminiert war, aber da die Vorträge ja nun turnusmäßig stattfinden, kann ich die Präsentation Schritt für Schritt ausbauen und entlang der Erfahrungen optimieren. Die jeweils aktuelle Präsentation packe ich dann auf Slideshare.
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.
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“
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.
Alexander Farkas versucht in seinem Artikel WAI-ARIA – Epic Fail (Too much accessibility – good intentions, badly implemented) und vor allem in seiner Serie WAI–ARIA Epic Fail zu ergründen, warum in der Implementierung von WAI-ARIA doch noch einiges unrund ist.
Kurz kommentiert: Die Implementierung von WAI–ARIA ist ohne Screenreader-Test zwar machbar, aber wenig sinnvoll. Abgesehen davon zeichnet sich barrierefreie Entwicklung großteils durch das Testen mit Screenreadern aus. WAI-ARIA ist ein aktueller Standard, der von Elementen und Attributen her unterschiedlich gut schon von assistiven Technologien unterstützt wird – das konnte ich vor kurzem bei den Attributen für Formulare feststellen. Es war nicht immer einfach zu entscheiden, liegt es am gewählten Screenreader, Browser oder an einer Kombination von beidem, dass das WAI-ARIA-Attribut nicht vorgelesen wurde. Man hat sich also immer auf dem Laufenden zu halten, was die Implementierungstiefe betrifft, insofern muss man auch mit den aktuellsten Updates arbeiten.
Weiterlesen „Kurz kommentiert: Die "Gestandenheit" des barrierefreien Entwicklers“
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.
Bei meiner Reise durch das barrierefreie Netz stoße ich immer wieder auf Kurioses, Interessantes und weniger Spannendes. Daher gibt es jetzt eine unregelmäßige Rubrik Fundstücke, in der ich eher knapp und kursorisch ein barrierefreies Reisetagebuch führe.
Die Stadt Herford hat barrierefrei gerelauncht: Barrierefrei, übersichtlicher, offen für Kritik. Der Anspruch auf Barrierefreiheit wird eingeschränkt, es sei nur weitgehend barrierefrei. Und es würden vor allem Sehbehinderte und Blinde davon profitieren. Das mag sein, ein Tastaturnutzer hat aber wenig Freude mit den realisierten Sprungmarken.
Wie so vieles in der Barrierefreiheit, wenn wir uns die gesetzlichen oder testbaren Rahmenbedingungen ansehen, wird unterschiedlich gewichtet. Da ich mich derzeit verstärkt mit der Tastaturbedienbarkeit auseinandersetze (Stichwort: A-Tag), habe ich mir die Anforderungen zur Tastaturbedienbarkeit von WCAG 2, BIENE und dem BITV-Test der BIK vorgenommen.
Für den BITV-Test habe ich auch schon die Neuentwürfe des Tests berücksichtigt, auch wenn diese noch nicht in Kraft getreten sind. Leider konnte ich die BITV 2 immer noch nicht einbeziehen, weil es ja bis dato noch nicht zur Verfügung steht.
Freilich sind es oft nur Nuancen in den Anforderungen zur Tastaturbedienbarkeit, aber ich war schon etwas überrascht darüber – denn auch Nuancen können im Entwickleralltag entscheidend sein.
Weiterlesen „Tastaturbedienbarkeit: ein Vergleich (WCAG 2, BIENE, BITV-Test)“
WebAIM hat heute auf ein sehr interessantes Problem hingewiesen: Hiding content for screen readers. Gängige Praxis ist es ja, Inhalte für Screenreader zu verstecken, sie aus dem sichtbaren Bereich der Webseite zu schieben.
Per CSS wird der Bereich dafür gemeinhin nach links (left: - 1000px) und nach oben in den Minusbereich (top: -1000px) verschoben. Enthält dieser versteckte Bereich etwa einen Link, wird dieser angesprungen, wenn man mit der Tastatur navigiert. Das bewirkt dann jedoch, dass der Browser bei jedem versteckten Link, der den Fokus erhält, wieder ganz nach oben springt.
Weiterlesen „WebAIM: Inhalt vor Screenreadern verstecken: Update“