Knüppel zwischen die Beine wegen Accessibility

In meinem aktuellen Projekt legt der Kunde sehr viel Wert auf die Barrierefreiheit der Seite. Das ist eine große Ausnahme innerhalb meines bisherigen beruflichen Lebens. Alle Projektbeteiligten sind für das Thema sensibilisiert. Das ist ein sehr gutes Erlebnis.

Umso schlimmer finde ich es, wenn mir als Entwickler im Namen der Barrierefreiheit Knüppel zwischen die Beine geworfen werden. Und dies nicht vom Kunden oder meinen Kollegen, sondern von den Browserherstellern.

Der Spass begann letztes Jahr, als bekannt wurde, dass Screenreader linearisierte Tabellen nicht mehr als Tabellen vorlesen. Die Lösung bestand dann in der Zugabe von WAI-ARIA. Allein dafür benötigte ich also JavaScript, denn schliesslich sollten in der nicht-linearisierten Variante nicht die falschen ARIA-Attribute an den Elementen hängen.

Nun wurde ich über Twitter auf ein weiteres Problem aufmerksam: die neueren Versionen des Safari (es widerstrebt mir, bei diesem Browser von „modern“ zu reden), verschweigen gegenüber VoiceOver die Semantik einer Liste, wenn im CSS ein list-style: none steht. Und so etwas schreiben wir schliesslich ständig. Keine Navigation sieht aus, wie eine Liste. Scott O’Hara schreibt darüber in „Fixing Lists„.

Aus dem Webkit-Projekt kommt als Argument für dieses Nicht-Ansagen, dass den Sehenden auch keine Liste angezeigt werden würde. Also wäre es wohl auch eine Liste. Und zudem hätten sich viele Nutzer über die „Listitis“ auf manchen Webseiten beschwert.

Bei diesem Argument musste ich ein wenig weinen. Ich erzähle in meinen Schulungen immer, dass HTML „nicht aussieht“. Das ist auch korrekt. Wenn eine Liste wie eine Liste aussieht, dann wegen CSS. Und mal ganz nebenbei: wie sieht denn eine Liste aus? Wer legt das denn fest? Offenbar der kommentierende Webkit-Entwickler. Ich möchte ihn gerne mal mit ein paar Designern zusammenbringen. Die werden ihm den Zahn schon ziehen.

Auch in der Kommunikation mit der die Barrierefreiheit testenden Agentur habe ich immer wieder den Kommentar gelesen, dass man davon ausgehe, dass Blinde und Sehbehinderte die gleiche Information bekommen sollten, wie Sehende. Das sehe ich nicht so. Manchmal kann es hilfreich sein, ihnen Zusatzinformationen zu geben, die sich mir als Sehendem aus dem Kontext erschliessen.

Auch die Semantik ist schliesslich eine Zusatzinformation, die ich als Sehender nicht habe und nicht benötige. Mir würde es nicht auffallen, wenn eine Seite nur aus DIV und SPAN bestünde. Einem Screenreadernutzer würde die fehlende Semantik sehr wohl auffallen. Semantische Webseiten mache ich also, damit mehr Menschen etwas mit meinen Seiten anfangen können. Wenn mir das egal ist, dann baue ich einen Button aus einem DIV und werfe ein wenig JavaScript drauf. Kein Sehender merkt den Unterschied. Das ist die zu Ende gedachte Konsequenz aus dem Argument des Webkit-Entwicklers.

Ich finde es erschreckend, dass uns Entwicklern, die wir guten Code und zugängliche Webseiten produzieren wollen, von den Browserherstellern Knüppel zwischen die Beine geworfen werden. Man kann sich natürlich aus der Sache herausstehlen, indem man den Safari erst gar nicht in die zu testende Browsermatrix aufnimmt. Dadurch ignoriert man aber einen Teil der potentiellen Nutzer. Auf der anderen Seite haben wir jahrelang alles Mögliche versucht, um den kaputten IE6 zu fixen. Das hat die Sachlage nicht verbessert. Wollen wir den Fehler beim neuen IE6 – nichts anderes ist der Safari wegen Apples Arroganz – wieder machen?

Die Safari-Eigenart, dass eine Liste nicht mehr als solche angekündigt wird, gibt es wohl schon seit Ende 2017. Erst jetzt habe ich davon mitbekommen. Vielen anderen Entwicklern war dies auch unbekannt, wie die Diskussionen auf Twitter belegen. Ich denke, ich werde diesen Umstand für die Zukunft ignorieren. Für den schlimmsten Fall – größere Nutzerbeschwerden – gibt es Lösungsansätze. Als Erstes würde ich die Nutzer allerdings darum bitten, sich bei Apple zu beschweren. Die haben diesen Fehler produziert. Solange ich diesen Fehler einfach und ohne Nebenwirkung für „gute“ Browser beheben kann, würde ich es tun. Ansonsten nicht.

1 Kommentar

  1. > Der Spass begann letztes Jahr, als bekannt wurde, dass Screenreader linearisierte Tabellen nicht mehr als Tabellen vorlesen. Die Lösung bestand dann in der Zugabe von WAI-ARIA.

    Das stimmt.

    > Allein dafür benötigte ich also JavaScript

    Das ist Quatsch, die aria-Attribute sind ausreichend, wie der verlinkte Artikel zeigt.

    > denn schliesslich sollten in der nicht-linearisierten Variante nicht die falschen ARIA-Attribute an den Elementen hängen.

    Da die ARIA-Attribute ja genau die impliziten ARIA-Rollen haben, den sie Tabellenelemente eh natürlicherweise haben (und nur behalten sollen), besteht diese Gefahr nicht.

    > Keine Navigation sieht aus, wie eine Liste.

    Gerade Navigationen sind da aber ein schlechtes Beispiel. Die Zusatzinfo, dass es sich bei einer Navigation um eine Liste handelt kann durchaus irrelevant sein. Das heißt nicht, dass ich finde, dass das überall eine gute Idee ist, aber bei Navigationen kann ich die Entscheidung eher nachvollziehen.

    > Aus dem Webkit-Projekt kommt als Argument für dieses Nicht-Ansagen, dass den Sehenden auch keine Liste angezeigt werden würde. Also wäre es wohl auch eine Liste. Und zudem hätten sich viele Nutzer über die „Listitis“ auf manchen Webseiten beschwert.

    Im zweiten Satz fehlt ein „k“. Zudem „Customers seems(!sic) much happier in the 3 years since this change went in.“

    > Und mal ganz nebenbei: wie sieht denn eine Liste aus? Wer legt das denn fest? Offenbar der kommentierende Webkit-Entwickler.

    Ich bezweifle, dass solche Entscheidungen von einzelnen Entwicklern getroffen werden. (Und Listen sind relativ charakteristisch, so mit Listenpunken und Text.)

    > Auch in der Kommunikation mit der die Barrierefreiheit testenden Agentur habe ich immer wieder den Kommentar gelesen, dass man davon ausgehe, dass Blinde und Sehbehinderte die gleiche Information bekommen sollten, wie Sehende. Das sehe ich nicht so. Manchmal kann es hilfreich sein, ihnen Zusatzinformationen zu geben, die sich mir als Sehendem aus dem Kontext erschliessen.

    Doch, ihr sagt beide das gleiche. Du als Sehender bekommst die Information was Überschriften sind visuell mitgeteilt, ein Screenreader-Nutzer über den Screenreader. Nur so haben Menschen mit und ohne Behinderung die gleiche Information.

    > Wenn mir das egal ist, dann baue ich einen Button aus einem DIV und werfe ein wenig JavaScript drauf. Kein Sehender merkt den Unterschied. Das ist die zu Ende gedachte Konsequenz aus dem Argument des Webkit-Entwicklers.

    Sehende Tastaturnutzer oder Spracheingabenutzer merken das sehrwohl. Und das ist nicht die Konsequenz des Arguments, sondern maximal eine hypothetische Überspitzung. Es argumentiert nämlich niemand für die Abschaffung von Schaltflächensemantik oder Funktionalität.

    > Ich finde es erschreckend, dass uns Entwicklern, die wir guten Code und zugängliche Webseiten produzieren wollen, von den Browserherstellern Knüppel zwischen die Beine geworfen werden

    Dein Code wird weder qualitativ schlechter dadurch, dass einzelne Informationen nicht genutzt werden, noch wirst du daran gehindert guten Code zu schreiben. Bei der Tabellensache finde ich die Zusatz-ARIA-Atteibute auch blöd und ich hoffe, dass es da bald Konsens gibt das nicht mehr zu tun. Aber letztlich müssen Browser und assistierende Technologien sehen wie sie Semantik interpretieren. So sagt zum Beispiel kein Screenreader standardmäßig strong und em an. Was bei Tabellen genau angesagt wird hängt schon im Standardmediathek extrem davon ab wie die Verbosity im Screen reader eingestellt ist.

    > Man kann sich natürlich aus der Sache herausstehlen, indem man den Safari erst gar nicht in die zu testende Browsermatrix aufnimmt. Dadurch ignoriert man aber einen Teil der potentiellen Nutzer. Auf der anderen Seite haben wir jahrelang alles Mögliche versucht, um den kaputten IE6 zu fixen. Das hat die Sachlage nicht verbessert. Wollen wir den Fehler beim neuen IE6 – nichts anderes ist der Safari wegen Apples Arroganz – wieder machen?

    > Für was argumentierst du hier eigentlich? Den Safari zu beachten um keine Nutzer auszuschließen oder nicht beachten, weil irgendwas mit IE6. (Was natürlich ein hinkender Vergleich ist weil Safari kontinuierlich weiterentwickelt wird und auch keine marktbeherrschende Stellung hat.)

    > Die Safari-Eigenart, dass eine Liste nicht mehr als solche angekündigt wird, gibt es wohl schon seit Ende 2017. Erst jetzt habe ich davon mitbekommen. Vielen anderen Entwicklern war dies auch unbekannt, wie die Diskussionen auf Twitter belegen. Ich denke, ich werde diesen Umstand für die Zukunft ignorieren.

    Ja. Das ist auch meine Empfehlung. Außerhalb einem kleinen Kreis hat es niemand bemerkt, offensichtlich vor allem nicht die Nutzer von VoiceOver und Safari. Und die haben sehrwohl zu viele Listen als störend empfunden. Alle sind glücklich.

    > Für den schlimmsten Fall – größere Nutzerbeschwerden – gibt es Lösungsansätze. Als Erstes würde ich die Nutzer allerdings darum bitten, sich bei Apple zu beschweren.

    Bitte berichte ob es eine (1) Beschwerde darüber gibt. Ich bin gespannt.

    > Die haben diesen Fehler produziert. Solange ich diesen Fehler einfach und ohne Nebenwirkung für „gute“ Browser beheben kann, würde ich es tun. Ansonsten nicht.

    Es ist kein Fehler und es gibt nichts was in (nach deiner Definition) „guten“ Browsern zu tun wäre.

    Solche Artikel und das aufbauschen von Barrierefreiheit als Stolperstein ist übrigens eine der Hauptgründe dafür, dass Entwickler Berührungsängste haben. Die Kontrolle, die es visuell nicht gibt über die Website soll aber für Screen Reader gelten. Nutzer wählen Hilfsmittel mit denen sie gut umgehen können. Alle haben ihre Eigenarten, weil sie eben mehr sind als nur ein Canvas auf das der Browser Bildchen malt. Sie sind dazu da die Inhalte so aufzubereiten, dass ihre Nutzer sie am Besten bedienen können. Wenn Apple aufgrund seiner Erfahrungen meint, das es besser für die blinden Nutzer ist (und ich gehe davon aus, dass es Nutzergetestet ist), dann ist das eine ungewöhnliche Entscheidung und man kann persönlich gerne anderer Meinung sein. Letztlich ist es aber nicht an mir zu bestimmen wie viele Meta-Informationen ein Screenreader-Nutzer gefälligst zu hören hat.

    (Und ich lasse mal diesen Screenshot aus den Einstellungen von JAWS hier, in denen Nutzer Listen abschalten können, wenn sie das wollen. https://doccenter.freedomscientific.com/doccenter/doccenter/rs11f929e9c511/2014-12-02_webpagetesting-l1/SettingsCenter-HTML-ListsAndTables.jpg Dann gehen natürlich auch alle anderen Listen flöten, nicht nur die, die wie Navigationen aussehen.)