contao
Screenreader-Usability der Chosen-Dropdowns
Aus dem aktuellen Barrierefreiheit-Test, den Heiko Kunert und ich mit der aktuellsten Contao 4-Version durchgeführt haben:
Screenreader-Nutzer haben erhebliche Probleme mit den Elementen, die für sehende Nutzer aussehen als wären es SELECT-Elemente, dies aber real gar nicht sind. Ein Beispiel hierfür ist beim Bearbeiten eines Inhaltselements das erste Feld "Typ". Es simuliert optisch ein SELECT-Element, aber tatsächlich ist es ein Link, gefolgt von einem leeren B (für sehende Nutzer der Pfeil nach unten/oben), gefolgt von einem ungelabelten Input-Feld und dann einer elendig langen Liste (in der die rein visuellen Gruppenüberschriften für Screenreader auch nicht von den anderen Listenpunkten unterscheidbar sind).
Dieses Konstrukt stellt für Screenreader-Nutzer ein extrem großes Problem dar. Ich habe vor kurzem beim Deutschen Blinden- und Sehbehindertenverband eine große Schulung speziell für stark sehbehinderte / blinde Redakteure/-innen gemacht. An diesem Punkt scheiterten sie alle. Selbst Heiko, der wirklich enorm erfahren und versiert im Umgang mit Software/Screenreadern ist, hatte massive Probleme damit. Ich musste ihm genau erklären, was da geschieht und nur deswegen war er dann unter meiner Anleitung in der Lage das überhaupt halbwegs zu nutzen. Alleine hätte er keine Chance gehabt (wie die anderen Redakteure in der Schulung).
Da mir schon mal signalisiert wurde, dass die Contao-Devs den Aufbau (bzw. die dahinter steckenden Features für sehende Nutzer) beibehalten wollen, möchten wir versuchen zumindest hier möglichst zeitnah ein paar Verbesserungen für sehbehinderte und blinde Nutzer reinzubekommen, damit Contao in diesem essentiellen Punkt für sie halbwegs sinnvoll bedienbar ist.
Hier ein paar konkrete Vorschläge in diesem Sinne:
Im Link sollten für Screenreader ergänzende Infos stehen.
Bisher:
<a href="javascript:void(0)" class="chzn-single chzn-single-with-drop" tabindex="-1"><span>Text</span><div><b></b></div></a>
Etwas besser:
<a href="javascript:void(0)" class="chzn-single chzn-single-with-drop" tabindex="-1"><span><span class="invisible">Gewählter Typ des Inhaltselements:</span> Text</span><div><b></b></div></a>
Dieser Link wurde mit tabindex="-1" aus der Tab-Reihenfolge entfernt. Das mag für blinde Nutzer vielleicht noch Sinn machen, da das Aus-/Einklappen der Liste sowieso rein visuell ist und keine Relevanz für blinde Nutzer hat. Allerdings setzen nicht nur blinde Nutzer Screenreader ein! Auch viele sehbehinderte Nutzer arbeiten ergänzend mit Screenreadern. Sie wollen also potentiell schon auch die aufgeklappte Liste sehen. Deshalb halte ich hier das tabindex="-1" eher für kontraproduktiv. Darüber könnte man aber ggf. diskutieren.
Das Suchfeld ist ungelabelt. Es sollte unbedingt ein sinnvolles Label haben, nach dem Schema:
<div class="chzn-search"><label for="suchfeld-x">Verfügbare Typenliste filtern/durchsuchen</label"><input id="suchfeld-x" type="text" autocomplete="off" tabindex="0" style="width: 100%;"></div>
Die Liste ist für blinde Nutzer wie gesagt ziemlich irritierend und nicht selbsterklärend. Es wäre sinnvoll, die UL zumindest mit einem ARIA-Label zu versehen, also beispielsweise so:
<ul class="chzn-results" aria-label="Verfügbare Listentypen - Gewünschten Typ anklicken zum Ändern des Elementtyps">
In der Liste sind bestimmte Einträge als unklickbare Überschriften gedacht, die die verfügbaren Typen inhaltlich unterteilen. Für Screenreader ist nicht erkennbar, was ein anklickbarer Typ ist und was nur der inhaltlichen Strukturierung der Liste dient.
Hier wäre es sinnvoll, diese Einträge tatsächlich als Überschriften (Hx) zu markieren. Das hätte den Vorteil, dass Screenreader-Nutzer diese ewig lange Liste auch über die Überschriften navigieren könnten.
<li id="ctrl_type_chzn_g_8" class="group-result" style="display: block;"><h4>Akkordeon<span lang="invisible">-Inhaltselemente</span></h4></li>
Das wären zumindest einige wichtige Verbesserungen, die im Rahmen des eingebauten HTML die Sache etwas zugänglicher machen. Die sehbehinderten und blinden Nutzer bräuchten dennoch am besten eine Schulung/Doku die ihnen erklärt, was hier geschieht, aber zumindest können sie danach damit arbeiten.
Das Dropdown-Menü basiert auf einem externen Script (Chosen wenn ich mich richtig erinnere, oder war's zumindest mal). Wir müssten also einen barrierefreien Ersatz dafür finden…
Wir sollten stattdessen einfach das normale Select-Feld anzeigen, das ja auch noch im Quelltext vorhanden ist. Die Frage ist nur, wie wir herausfinden, ob wir es mit einem Screenreader oder einem Browser zu tun haben?
Man kann Screenreader nicht zuverlässig von einem Browser unterscheiden. Dazu gab es imho gerade kürzlich wieder eine interessante Diskussion im W3C-Umfeld, die das klargestellt hat. Das hat wohl auch damit zu tun, dass die Nutzer mit ganz normalen Browsern arbeiten und der Screenreader dann eben nur die Ausgabe (das Vorlesen) übernimmt.
Sofern du in der Lage bist beide Varianten (Chosen und Select) gleichzeitig anzugeben, ohne dass sich irgendwelche IDs in die Quere kommen, wäre das möglich:
Chosen-Variante mit Attribut aria-hidden="true" (wodurch es vor Screenreadern verborgen wird, aber für sehende Nutzer sichtbar ist) Select-Variante mit Klasse invisible (wodurch es für sehende Nutzer verborgen ist, aber für Screenreader zugänglich bleibt)
Das ist auch nicht perfekt (es gibt teil-sehende Screenreader-Nutzer die damit nicht „abgedeckt“ wären), aber zumindest schon eine deutliche Verbesserung für sehr viele Nutzer. Am besten ist aber natürlich immer das Original, sprich ein Select-Feld.