Gerade entdeckt die Chrome-Erweiterung „Barrierefreiheits-Persona simulieren“. Entwickelt vom DigitalService des Bundes simuliert diese Erweiterung Nutzungserfahrungen von Personas mit etwa starker Sehschwäche oder mit Legasthenie. Ja, das gibt es auch schon in anderen Optionen und Erweiterungen. Aber die Anwendung ist spannend und die Erweiterung ist gut und standardkonform (! – ich habe das mal debugged …) erstellt.
Und da ist noch ein Barrierefreiheits-Score: der Wave Aim Score oder Wave Accessibility IMpact (AIM). WebAIM hat sein Barrierefreiheits-Tool WAVE im Oktober aktualisiert und zeigt nun auf der Registerkarte „Details“ den AIM-Score der getesteten Seite an. Beispielhaft für Seiten wie das W3C oder WebAIM selbst ist das dann ein Score von 10 von 10, aber für die Startseite des Spiegel-Magazins dann nur noch 4 von 10.
Dank der immer wieder interessanten Leseliste von Bruce Lawson (Leseliste 337) bin ich auf die neuen, noch experimentellen HTML-Attribute commandfor und command gestossen. Die beiden Attribute werden auf lange Sicht etwa beim Aufklappen von Inhalten durch ein Bedienelement (button) aria-controls und aria-expanded ablösen.
Um die Überschriften-Hierarchie auf einer Webseite zu testen, kann man die Browser-Erweiterung HeadingsMap (beispielhaft Erweiterung für den Browser Chrome) als zusätzliches Werkzeug nutzen. In den Einstellungen finden sich interessante Optionen.
Quelle: Screenshot Firefox Version 121 – Option „Links immer unterstreichen“
Ab der Version 121 (aktuelle Version ist 120) können Nutzer:innen in Firefox in den allgemeinen Einstellungen im Bereich „Surfen“ die Option aktivieren, dass Links immer unterstrichen werden – unabhängig vom CSS der jeweiligen Seite.
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.
Gerade weil ich täglich mit vielen externen Tools (Bookmarklets, Browsererweiterungen) arbeite, fand ich spannend, die Möglichkeiten der Browser näher in Augenschein zu nehmen. Und es ist doch überraschend, wie viele unterschiedliche Möglichkeiten die Browser bieten, um etwa die Bedienung mit Tastatur zu testen oder sich die Kontraste von Texten genauer anzusehen. Klar – mit der Dev-Tools sollte man schon ein wenig gewöhnt sein zu arbeiten. Die meisten Optionen und Tools zum Testen von Barrierefreiheit in den Browsern finden sich in den Dev-Tools.
Auch nach dem Vortrag finde ich es spannend, auszuloten, welche Prüfschritte lassen sich nur mit Hilfe des Browsers testen oder wo brauche ich dann doch ein ausführliches Tools (Bookmarklet, Browsererweiterung). Es wäre auch mal interessant, eine Geschichte der Browser Dev-Tools im Hinblick auf die Barrierefreiheit zu formulieren.
Das BookmarkletWAI-ARIA Usage von TPGi analysiert den Einsatz von WAI-ARIA in HTML gemäß der Spezifikation ARIA in HTML (W3C Recommendation, 9.12. 2021). Es nutzt die Inhalte der Tabelle „Roles of ARIA Attribute usage by HTML elment“. In dieser Tabelle wird jedem HTML Element (Spalte 1) zuerst die implizite WAI-ARIA Semantik (Spalte 2) zugeordnet und dann die Möglichkeit, noch weitere WAI-ARIA Roles (Rollen), States (Zustände) und Properties (Eigenschaften) (Spalte 3) für dieses Element zu integrieren.
In Köln-Ehrenfeld lassen sich interessante Bilder finden (Photo: Sylvia Egger)
Irgendwie sind sie nun doch verflogen – die letzten Jahre. Mein Blog „sprungmarker“ ist mehr als in die Jahre gekommen – in vielerlei Hinsicht war ein Relaunch fällig. Ich habe versucht, auch neben meiner Arbeit als Frontend-Entwicklerin meinen Blog weiter mit dem zu füllen, was mir wichtig ist. Aber irgendwie hat die Arbeit in der Agentur viel von meiner Energie – vor allem im Thema „Barrierefreiheit“ – beansprucht.
Im Laufe meines Blog-Relaunches bin ich wieder in WordPress auf Probleme im Hinblick auf Barrierefreiheit gestoßen. Im Default-Editor von WordPress (Gutenberg) gibt es nach wie vor keine Möglichkeit, den Sprachwechsel im Text entsprechend auszuzeichnen – außer man macht das per Hand im Quellcode.
In GitHub lässt sich dazu auch ein entsprechendes Issue aus dem Jahre 2019 (!) finden, das bis heute nicht aufgearbeitet worden ist. Joe Dolson hat als letzter darauf hingewiesen, dass es etwas mehr Bewegung im Thema Sprachwechsel geben sollte. Die Debatte dazu enthält die üblichen Missverständnisse. Zu sehr wird der Sprachwechsel im Text mit Hilfe des HTML-Attributs lang auf die allgemeine Möglichkeit, Sprache im Webauftritt festzulegen, reduziert. Deswegen dreht sich die Diskussion fast nur um die Option, einen ganzen Absatz – oder wie es in WordPress korrekt lautet – eines ganzen Blocks – mit einem Sprachwechsel zu versehen.