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.
- ← Previous
Linkfutter 961 - JavaScript - Next →
Linkfutter 962