Websupporter

Vor allem über WordPress.

Barrierefreiheit in Gutenberg

Während der Entwicklung des neuen Blockeditors in WordPress erklärten die Vertreterïnnen des Accessibility-Teams wiederholt, dass Gutenberg im Wesentlichen nicht benutzbar ist, wenn die Benutzerïn Computer nur eingeschränkt benutzen kann, also beispielsweise blind ist oder die Maus nicht bedienen kann.

Barrierefreiheit und Publishing zu demokratisieren gehen Hand in Hand. Für WordPress gehört die gute Bedienbarkeit der Software deshalb zu einem der zentralen Leitsätze an denen entlang die Software entwickelt werden soll. Tatsächlich hat sich WordPress sogar Regeln gegeben, nach denen kein Code in die Software kommen darf, welcher schwer zugänglich ist:

All new or updated code released in WordPress must conform with the WCAG 2.0 guidelines at level AA.

https://make.wordpress.org/core/handbook/best-practices/coding-standards/accessibility-coding-standards/

Um so verblüffender war es, dass Gutenberg dennoch schon im Dezember 2018 veröffentlicht wurde. Im Zuge der Kontroverse trat unter anderem Rian Rietveld von ihrer Leadrolle des Accessbility-Teams zurück. Das Urteil des Teams viel letztlich vernichtend aus:

However, based on its current status, we cannot recommend that anybody who has a need for assistive technology allow it to be in use on any sites they need to use at this time.

https://make.wordpress.org/accessibility/2018/10/29/report-on-the-accessibility-status-of-gutenberg/

WP Campus gibt Studie in Auftrag

Barrierefreiheit ist nicht einfach „nur“ eine gute Sache. Barrierefreiheit ist auch nicht einfach nur eine Maßgabe, welche sich WordPress selbst gegeben hat. Für viele Seitenbetreiberïnnen stellt Barrierefreiheit eine juristische Hürde dar. Bezieht eine Institution beispielsweise in den USA staatliche Mittel, so müssen Webseiten zugänglich sein. Dies gilt insbesondere für Universitäten und andere Bildungseinrichtungen.

Auch die Friedrich-Alexander Universität Erlangen-Nürnberg verzichtete unter anderem wegen der mangelhaften Barrierefreiheit vorläufig auf den Einsatz von Gutenberg:

Der Gutenberg-Editor weist leider noch einige Probleme auf, die eine Inbetriebnahme verhindern: Insbesondere ist neue Version nicht ausreichend barrierefrei. Bei einer zwangsweisen Nutzung des Gutenberg Editors würden daher Menschen mit Behinderungen auf einige Nutzungsbarrieren treffen. Dies ist für das RRZE-Webteam keine Option. Da die bisherige Version des TinyMCE Editors hingegen keine derartigen Barrieren aufweist, werden wir diesen weiter in Betrieb lassen.

WP Campus ist eine Community, welche sich ganz speziell um die Bedürfnisse von Universitäten und anderer Bildungseinrichtungen kümmert. Das große Gruppen von Studentïnnen und Lehrenden ab WordPress 5.0 eventuell keine Beiträge mehr auf ihren Webseiten verfassen könnten (wenn nicht mit Hilfe von Plugins wie Classic Editor Abhilfe geschaffen wurde) war für WP Campus natürlich ein zentrales Thema.

Doch es fehlte ein fundierter Einblick in die Mängel, der nicht auf einzelnen Twitterstorms oder wütenden Blogposts basierte. Rachel Cherry begann daraufhin für eine umfassende Studie zu trommeln, welche sich dem Thema Barrierefreiheit in Gutenberg annehmen sollte. Das Team holte einige Angebote ein und es wurde schnell klar, dass ein ausführlicher Test von Gutenberg um die 30.000 US-Dollar kosten würde.

Etwa 10.000 US-Dollar kamen durch die WordPress Community zusammen. Kurz vor dem WordCamp US sagte Automattic zu, den noch ausstehenden Betrag zu bezahlen, so dass Tenon schließlich den Auftrag erhielt. Die Ergebnisse der Tests sind nun veröffentlicht worden.

Die Ergebnisse der Untersuchung

Ist Gutenberg barrierefrei? Um es kurz zu machen: Zum jetzigen Zeitpunkt nicht:

Tweet from @RianRietveld

Click the button below to load the content from Twitter.

Always allow Twitter

Tenon testete mit WordPress 5.0.3. Seither wurden zwar ein paar Probleme behoben, das grundsätzliche Resultat bleibt jedoch unverändert. Die Studie teilt sich in eine 34seitige Executive Summary, ein PDF, welches den Testplan erläutert, einen neunseitige Zusammenfassung der Methode und Ergebnisse, und einem über 300 Seiten langen technischen Report, welcher sämtliche Probleme darstellt:

Overall, Gutenberg’s user experience is consistently poor.

Groves et.al, Usability Report: Gutenberg Accessibility Audit, S. 9

Wirklich überraschend kam das Ergebnis natürlich nicht, wenn die konsistente Kritik in Betracht gezogen wird, welche vom Accessibility Team immer wieder vorgebracht wurde. Größere Aufmerksamkeit wurde in der Debatte um den Report deshalb auch dem technischen Teil gewidmet.

Letztlich ist der technische Report eine Liste von 90 Issues, welche nach Problemart sortiert sind:

  • Farben (12 Probleme)
  • Dokumentenstruktur (11 Probleme)
  • Sich verändernde Inhalte (6 Probleme)
  • Formulare (9 Probleme)
  • Frames (1 Problem)
  • Medien (3 Probleme)
  • Bedienung mit der Tastatur und Fokus (22 Probleme)
  • Navigation und Links (1 Problem)
  • Name, Status, Rolle und Wert (3 Probleme)
  • Parsing (1 Problem)
  • Text und Typographie (11 Probleme)
  • Weitere Probleme: 10

Manche Probleme, wie mangelnde Farbkontraste, dürften relativ einfach zu beheben sein:

Beispiel eines zu geringen Farbkontrasts.
Beispiel eines zu geringen Farbkontrasts in Gutenberg

Sämtliche Issues wurden in Github eingestellt, so dass deren Verlauf leicht nachzuvollziehen ist. So konnten von den 90 Issues mittlerweile schon 38 geschlossen werden, so dass wir durchaus davon ausgehen können, dass einige Barrieren in Gutenberg demnächst fallen werden.

Schlussendlich gibt es einige größere Probleme über welche das Accessibility-Team noch diskutiert, die nicht wirklich in ein Github Issue gepackt werden können, aber wenn wir es schaffen, diese 90 Probleme zu beheben, so wird das Gutenberg ein ganzes Stück weiter bringen.

Rachel Cherry in einer Diskussion

Dieser Bericht ist Lehrmaterial

Wenn Du eine Webentwicklerïn bist, ist dieser Bericht Gold wert. Nicht um zu sehen, was Gutenberg alles falsch macht, sondern um zu sehen was wir alle falsch machen.

Zumindest von meiner bescheidenen Warte aus; Sicherlich kenne ich ein paar Regeln bezüglich Barrierefreiheit. Das Bilder ein alt-Attribut besitzen sollten; geschenkt.

Aber dieser Bericht gibt mir erstmals eine komplette a11y Analyse für eine Webapplikation die ich kenne. Er führt mir auch zum ersten Mal mit Hilfe von Screenshots oder Beschreibungstexten plastisch vor Augen: Hier ist das Problem!

Selbst wenn Du Dich nicht zu sehr für die Benutzerïnnenfreundlichkeit in Gutenberg oder WordPress interessierst (das soll es ja geben): Wenn Du bemüht bist benutzerïnnenfreundliche Webseiten herzustellen, dieser Bericht stellt eine praxisnahe Ergänzung zu den doch relativ trockenen Dokumenten, wie der WCAG Richtlinie, dar.

Mich hatte zum Beispiel überrascht, dass Menschen häufig natürlich den Zoom benutzen. Gerade auch, weil ich selbst zu diesen Menschen gehöre. Ich mache das eigentlich ständig, dass ich mir längere Texte heranzoome. Mich stört es dabei oft genug, wenn plötzlich irgendwelche Sidebars über dem Text hängen und ich nicht mehr weiter lesen kann. Dass ich damit nicht alleine bin, sondern im Gegenteil, dass unter dem Aspekt der Barrierefreiheit genau das eigentlich gewährleistet sein sollte war für mich ein neuer Blick auf „Was mich im Alltag stört“. Und so betrachtet wird Barrierefreiheit ein größeres Thema als gemeinhin angenommen.

Bezüglich des Zooms wurde in Gutenberg unter anderem die obere Toolbar moniert. Verwendet die Benutzerïn einen hohen Zoom, können die Buttons für weitere Optionen und Einstellungen verschwinden:

Screenshot der zeigt, wie ein Button, der eigentlich zu sehen sein sollte, nicht mehr da ist.
Der Button für „Weitere Werkzeuge“ ist nicht mehr zu sehen.

Ich werde den Report jedenfalls immer mal wieder aufschlagen und ein wenig darin blättern. Sozusagen als kleines Nachschlagewerk 🙂


Nachtrag 11. Mai: 25 der 38 geschlossenen Tickets auf Github wurden geschlossen, weil es sich um Probleme handelt, die nicht speziell Gutenberg betreffen, sondern andere Bereiche von WordPress. Diese wurden im Gutenberg Repository geschlossen um im WordPress Trac behandelt zu werden.

Über den Autoren

Seine erste Webseite hat David Remer 1998 in HTML verfasst. Wenig später war er fasziniert von DHTML und JavaScript. Heute konzentriert sich vor allem auf das Entwickeln von WordPress Themes und Plugins für Inpsyde. Außerdem hat er das Buch "WordPress für Entwickler" verfasst.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.