Warum nehmen Entwickler Barrierefreiheit nicht ernst?

Kennen Sie diesen Witz: „Zwei Frontend-Entwickler gehen in eine Bar und stellen fest, dass sie nichts gemeinsam haben“? Er ist lustig und doch frustrierend, weil er wahr ist.

Dieser Artikel wird drei verschiedene Perspektiven auf Barrierefreiheit im Webdesign und in der Webentwicklung vorstellen. Drei Perspektiven, die uns helfen könnten, die große Kluft zwischen Nutzern und Designern/Entwicklern zu überbrücken. Er könnte uns helfen, eine gemeinsame Basis für den Aufbau eines besseren Webs und einer besseren Zukunft zu finden.

Akt 1

„Ich verstehe einfach nicht, wie Entwickler nicht an Barrierefreiheit denken.“

Das sagte mir mal jemand. Lassen Sie uns kurz innehalten und darüber nachdenken. Vielleicht gibt es eine Perspektive dazu.

Denken Sie darüber nach, wie viele Dinge ein Entwickler wissen muss, um eine Website erfolgreich zu erstellen. An jedem beliebigen Tag, für jede beliebige Position in der Webentwicklung, tauchen die anderen Details der Webentwicklung auf. Das bedeutet, es ist mehr als „nur“ HTML, CSS, ARIA und JavaScript zu kennen. Entwickler lernen im Laufe ihrer Karriere auch andere Dinge, basierend auf dem, was sie tun müssen.

Dies kann Paketverwaltung, Workspaces, Codegeneratoren, Kollaborationstools, Asset-Laden, Asset-Management, CDN-Optimierungen, Bundle-Optimierungen, Unit-Tests, Integrationstests, visuelle Regressionstests, Browser-Integrationstests, Code-Reviews, Linting, Formatierung, Kommunikation durch Beispiele, Changelogs, Dokumentation, semantische Versionierung, Sicherheit, App-Deployment, Paket-Releases, Rollbacks, inkrementelle Verbesserungen, inkrementelles Testen, kontinuierliche Deployments, Merge-Management, Benutzererfahrung, User-Interaction-Design, Typografie-Skalen, Seitenverhältnisse für responsives Design, Datenmanagement und... nun ja, die Liste könnte weitergehen, aber Sie verstehen, worauf ich hinauswill.

Als Entwickler halte ich mich für ziemlich verdammt schlau, weil ich weiß, wie man die meisten dieser Dinge tut! Halten Sie kurz inne und bedenken Sie dies: Wenn Sie darüber nachdenken, wie viele Menschen es auf der Welt gibt, und das vergleichen mit der Anzahl der Menschen, die Websites erstellen können, ist es prozentual ein sehr kleiner Anteil. Das ist irgendwie... cool. Unglaublich, sogar. Denken Sie darüber hinaus daran, wann Sie das letzte Mal Code ausgeliefert haben und wie gut sich das angefühlt hat. „Ich habe eine schwierige Sache herausgefunden und es zum Laufen gebracht! Ahhhhh! Ich fühle mich großartig!“

Diese Art von emotionalem Hochgefühl ist ziemlich großartig, nicht wahr? Es bringt mich zum Lächeln, nur daran zu denken.

Stellen Sie sich nun vor, ein Experte für Barrierefreiheit kommt vorbei und sagt Ihnen im Wesentlichen, dass Sie nicht nur nicht besonders schlau sind, sondern die Dinge auch noch falsch gemacht haben, und das schon seit langer Zeit.

Autsch. Plötzlich fühlen Sie sich nicht mehr sehr gut. Falsch? Ich?? Was??? Ihr Adrenalin kann sogar einsetzen und Sie fangen an, sich defensiv zu fühlen. Zeit, sich selbst zu verteidigen... richtig? Zeit, auf die Zähne zu beißen.

Die kognitive Dissonanz kann sogar wirklich überwältigend sein. Es fühlt sich schlecht an zu erfahren, dass man nicht nur nicht gut in dem ist, was man für seine Stärke hielt, sondern auch noch gesagt hat: „Leck mich am Arsch, wen interessiert’s eh“, zu einer ganzen Reihe von Leuten, die die Websites, bei deren Erstellung Sie geholfen haben, nicht nutzen können, weil Sie (versehentlich oder anders) ignoriert haben, dass sie überhaupt existieren, dass Sie Nutzer ignoriert haben, die etwas mehr brauchten als die Cleverness, die Sie all die Jahre geliefert haben. Autsch.

Alles in allem ist es für mich durchaus verständlich, dass ein Entwickler seine Finger in die Ohren stecken und so tun möchte, als wäre nichts von alldem passiert, dass er immer noch sehr schlau und großartig ist. Dass der eine „Experte“, der Ihnen sagt, Sie hätten es falsch gemacht, nur eine Person ist. Und eine Person ist leicht zu ignorieren.

- Ende der Szene.

Akt 2

„Ich habe das Gefühl, ich spiele überhaupt keine Rolle.“

Das ist ein häufiges wiederkehrendes Thema, das ich von Menschen höre, die assistierende Technologien benötigen, um Websites zu nutzen, diese aber oft aus unzähligen Gründen als unbenutzbar empfinden. Vielleicht können sie den Text nicht lesen, weil das Design der Website den Farbkontrast ignoriert hat. Vielleicht gibt es verschachtelte interaktive Elemente, sodass sie sich nicht einmal einloggen können, um Dinge wie Stromrechnungen zu bezahlen oder wichtige Artikel selbst zu kaufen. Vielleicht hat ihr Lieblingssänger endlich einen Online-Shop eingerichtet, aber der Nutzer mit assistierender Technologie kann die Website nicht einmal navigieren, weil, obwohl sie aus Sicht eines sehenden Nutzers interaktiv erscheinen mag, alle Buttons Divs sind und überhaupt nicht mit der Tastatur interagieren...

Diese Frustration kann überkochen und sich ausbreiten; die Hauptlast dieser Frustration tragen oft diejenigen, die versuchen, inklusivere Produkte anzubieten. Das Ergebnis ist ein negativer Rückkopplungskreis; einige Tech-Leute ziehen sich vom Zuhören zurück, weil es „unhöflich“ ist (und die Ironie dieser Aussage völlig verfehlen). Andere Tech-Leute kämpfen mit der emotionalen Last, die oft mit der Arbeit im Bereich barrierefreies Design und Entwicklung einhergeht.

Die Sache ist, dass diese Nutzer so lange ignoriert wurden, dass es sich anfühlen kann, als würden sie in eine Leere schreien. Hört denn niemand zu? Kümmert sich denn niemand? Es scheint, dass die einzige Möglichkeit, überhaupt anerkannt zu werden, die Behandlung zu fordern ist, die ihnen das Gesetz gewährt! Selbst dann fühlen sie sich oft ignoriert und vergessen. Sind Klagen der einzige Ausweg?

Es scheint zunehmend, dass lautes und militantes Auftreten der einzige Weg ist, gehört zu werden, und selbst dann kann es lange dauern, bis etwas geschieht.

- Ende der Szene.

Akt 3

„Ich weiß, dass es den Farbkontrast nicht besteht, aber ich habe das Gefühl, es schränkt meine Kreativität als Designerin einfach so stark ein. Ich mag, wie das alles aussieht, überhaupt nicht.“

Das habe ich im Laufe meiner Karriere oft gehört. Für manche ist inklusives Design kein notwendiger Leitplanke, um sicherzustellen, dass unsere Websites von allen genutzt werden können, sondern eher ein Dämpfer für ihre kreative Freiheit.

Wenn Sie ein Designer sind, der so denkt, bitte bedenken Sie Folgendes: Sie entwerfen nicht für sich selbst. Das ist keine physische Kunst; auch wenn Ihr visuelles Design künstlerisch sein kann, es ist immer noch im Web. Es ist immer noch für das Web. Webdesigner haben eine höhere Herausforderung – ihre künstlerische Vision muss für alle nutzbar sein. Fordern Sie sich selbst heraus, die Unterhaltung in einen anderen Raum zu verlagern: Sie haben das richtige Design noch nicht gefunden. Es ist eine falsche Wahl zu glauben, dass ein Design entweder schön oder zugänglich sein kann; fallen Sie nicht in diese Falle.

- Ende der Szene.

Lassen Sie uns das Gespräch neu gestalten

Dies sind nur drei der Perspektiven, die wir im Hinblick auf digitale Barrierefreiheit betrachten könnten.

Wir könnten über den Projektmanager sprechen, der „einfach nur Features releasen möchte“ und sagt: „Wir können uns später um Barrierefreiheit kümmern.“ Wir könnten über den Entwickler sprechen, der scherzt, dass er „das Internet ohnehin nicht nutzen würde, wenn er blind wäre“, oder derjenige, der sagt, er werde sich erst dann um Barrierefreiheit kümmern, „wenn die Browser ihn dazu zwingen.“

Wir könnten, aber wir müssen es nicht wirklich. Wir wissen, wie diese Gespräche verlaufen, denn viele von uns haben diese Erfahrungen gemacht. Das Projekt wird nie nachgerüstet. Das Unternehmen zahlt einmal für die Entwicklung des Produkts, zahlt dann für eine Barrierefreiheitsprüfung, zahlt dann für die Neufassung, nachdem die Prüfung zeigt, dass eine Nachrüstung kostspieliger sein wird als etwas Neues zu bauen. Wir kennen den Entwickler, der darauf besteht, dass er nur dann dazu gezwungen werden sollte, etwas zu tun, wenn der Browser es andernfalls verbietet, und dass es unwahrscheinlich ist, dass er davon überzeugt wird, dass die inklusive Architektur seines Codes nicht nur vorteilhaft, sondern notwendig ist.

Worüber sollten wir also reden?

Wir müssen anerkennen, dass Designer und Entwickler viel früher in ihrer Karriere über Barrierefreiheit lernen müssen. Ich denke dabei an diese Analogie: Stellen Sie sich vor, Sie hätten eine Fremdsprache gelernt, aber nur den Slang dieser Sprache. Ihre Wörter sind technisch korrekt, aber es gibt viele Muttersprachler dieser Sprache, die Sie nie verstehen werden. JavaScript-first Webentwickler sind oft technisch korrekt aus JavaScript-Sicht, aber sie erstellen auch häufig Lösungen, die am Ende eine ganze Menge Leute ausschließen.

Wie korrigieren wir das? Ich werde hier entschlossen sein, wie wir es alle sein müssen. Wir müssen sicherstellen, dass jede Dokumentation, die wir erstellen, zugängliche Codebeispiele enthält. Designs müssen zugängliche Anmerkungen enthalten. Unsere Konferenzvorträge müssen Barrierefreiheit beinhalten. Die coolen, lustigen Spielzeuge, die wir machen, um uns das Leben leichter zu machen? Sie müssen zugänglich sein, und es darf keine Entschuldigung für etwas weniger geben. Das wird unser neues Minimum-Viable Product für alles, was mit dem Web zu tun hat.

Aber was ist mit dem Code, der bereits existiert? Was ist mit den Tausenden von bereits geschriebenen Artikeln, gehaltenen Vorträgen, produzierten Bibliotheken? Wie kommen wir darüber hinweg? Selbst während ich diesen Artikel für CSS-Tricks schreibe, denke ich an all die Artikel, die ich gelesen habe, und an die Enttäuschung, die ich gefühlt habe, als ich wusste, dass das Endergebnis nicht zugänglich war. Oder die wirklich lustigen Codegenerator-Tools, die keinen zugänglichen Code erzeugen. Oder die beliebten CSS-Frameworks, die die Tabulatorreihenfolge oder den Farbkontrast nicht berücksichtigen. Möchte ich, dass all diese Leute sich schlecht fühlen oder irgendwie bestraft werden?

Nein. Nicht einmal im Entferntesten. Nichts Gutes kommt aus dieser Art von Denken. Das Gute kommt aus den Bereichen, die wir bereits kennen – Mitgefühl und Neugier.

Wir nähern uns dem mit Mitgefühl und Neugier, denn das sind nachhaltige Wege zur Verbesserung. Wir werden uns niemals verbessern, wenn wir im Schuldgefühl vergangener Taten schwelgen und uns selbst oder andere dafür beschimpfen, dass wir die Barrierefreiheit all die Jahre ignoriert haben. Ehrlich gesagt, wir würden nichts tun, wenn wir irgendwie für vergangene unwissende Taten bezahlen müssten; denn ja, wir haben es ignoriert. In vielerlei Hinsicht ignorieren wir es immer noch.

Reale Beispiele: Das Google Developer Training lehrt viele Dinge, aber es lehrt nichts mehr als die super grundlegenden Teile der Barrierefreiheit. JavaScript-Frameworks sind so sehr in der Cleverness und Komplexität von JavaScript gefangen, dass sie völlig vergessen, dass HTML bereits existiert. Selbst dann kann Barrierefreiheit immer noch zurücktreten. Ember existierte etwa acht Jahre, bevor eine auf Barrierefreiheit fokussierte Community-Gruppe hinzugefügt wurde (auch wenn sie seitdem große Fortschritte gemacht haben). React benötigte eine völlig andere Router-Lösung. Vue hat noch nicht einmal begonnen, Barrierefreiheit im Kern-Framework öffentlich anzugehen (obwohl es Community-Bemühungen gibt). Barrierefreiheitsingenieure betteln darum, dass inert nativ in Browsern implementiert wird, aber es ist oft unterfinanziert und wird heruntergestuft.

Aber wir sind Technologen und Künstler, also gewinnt unsere Neugier, wenn wir interessante Artikel darüber lesen, wie das Accessibility Object Model funktioniert und wie unser Code von Betriebssystemen übersetzt und an assistierende Technologien weitergegeben werden kann. Das ist ziemlich cool. Schließlich ist es wahrscheinlich eher das, was wir uns vorgestellt haben, Maschinencode zu schreiben, damit er mit einer anderen Maschine sprechen kann, oder?

Die Sache ist, wir können nur dann anfangen, Mitgefühl für andere Menschen zu haben, wenn wir Mitgefühl für uns selbst haben können. Klar, wir haben Mist gebaut – aber wir müssen nicht unwissend bleiben. Denken Sie an die Zeit, als Sie Ihren Code stundenlang debuggt haben und es sich am Ende um einen Tippfehler oder ein fehlendes Semikolon handelte. Machen Sie sich deswegen immer noch Vorwürfe? Nein, Sie haben durch logisches Denken Mitgefühl entwickelt. Denken Sie an den Junior-Entwickler, der entmutigt wurde, und wie Sie ihn motiviert haben, weiterzumachen, und dass wir alle gute und schlechte Tage haben. Das ist Mitgefühl.

Hier ist das Coole: Wir haben nicht nur die Technologie, wir sind buchstäblich diejenigen, die sie reparieren können. Wir können aufstehen und versuchen, morgen besser zu werden. Wir können uns Zeit nehmen, um über Barrierefreiheit zu lesen, und jeden Tag weiter darüber lesen, bis wir sie genauso gut kennen wie andere Dinge. Es wird anfangs schwer sein, genau wie beim ersten Mal, als wir versucht haben… Tests zu schreiben. CSS zu schreiben. Mit dieser einen API zu arbeiten, die sich für immer in unser Gedächtnis eingebrannt hat. Aber mit Wiederholung und Übung wurden wir besser. Es wurde einfacher.

Logischerweise wissen wir, dass wir schwierige Dinge lernen können; wir haben bereits schwierige Dinge gelernt, immer und immer wieder. Das ist das Leben und der Beruf, für den wir uns entschieden haben. Das bringt uns jeden Morgen aus dem Bett. Wir lieben Herausforderungen und wir lieben es, sie zu lösen. Wir sind absolut dafür.

Was können wir tun? Hier sind einige Handlungsschritte.

Vielleicht habe ich an dieser Stelle einige Leser verloren. Aber wenn Sie bis hierher gekommen sind, fragen Sie sich vielleicht: „Melanie, du hast mich überzeugt, aber was kann ich jetzt tun?“ Ich gebe Ihnen zwei Listen, um Sie zu befähigen, zu handeln, indem ich Ihnen einen Startpunkt gebe.

Verbessern Sie sich mit Mitgefühl

1. Beginnen Sie, einigen Menschen mit Behinderungen zu folgen, die in den sozialen Medien aktiv sind, mit dem Ziel, von ihren Erfahrungen zu lernen. Hören Sie zu, was sie zu sagen haben. Diskutieren Sie nicht mit ihnen. Zensieren Sie ihre Sprache nicht. Hören Sie zu, was sie Ihnen sagen wollen. Vielleicht kommt es nicht immer so heraus, wie Sie es sich wünschen, aber hören Sie trotzdem zu.
2. Rüsten Sie Ihr Wissen nach. Versuchen Sie, Ihre nächste Komponente mit HTML zu schreiben, und fügen Sie dann Funktionalität mit JavaScript hinzu. Lernen Sie, was Sie kostenlos erhalten von HTML und dem Browser. Nehmen Sie einige Kurse, die sich auf Barrierefreiheit für Ingenieure konzentrieren. Investieren Sie in Ihre eigene Verbesserung, um Ihr Handwerk zu verbessern.
3. Schalten Sie einen Screenreader ein. Lernen Sie, wie er funktioniert. Finden Sie die Einstellungen heraus – wie schaltet man eine reine Textversion ein? Wie ändert man die Stimme? Wie bringt man ihn zum Schweigen oder zum schnelleren Sprechen? Wie navigiert man nach Überschriften? Wie erhält man eine Liste von Links? Was sind die Tastenkombinationen?

Bonuschallenge: Versuchen Sie sich am Bau von Werkzeugen zur Barrierefreiheit. Schauen Sie sich A11y Automation Tracker an, ein Open-Source-Projekt, das verfolgen soll, welche Automatisierungen existieren könnten, aber noch nicht erstellt wurden.

Verbessern Sie Ihren Code schrittweise

Es gibt kritische Blocker, die Menschen daran hindern, Ihre Website zu nutzen. Bleiben Sie nicht stehen und fühlen Sie sich schlecht deswegen; treiben Sie sich zu Handlungen an und machen Sie Ihren Code noch besser als zuvor.

Hier sind einige der schlimmsten:

1. Verschachtelte interaktive Elemente. So etwas wie einen Button in einen Link einfügen. Oder einen weiteren Button in einen Button.
2. Fehlende Labels für Eingabefelder (oder nicht zugeordnete Labels)
3. Tastaturfallen halten Ihre Benutzer auf. Lernen Sie, was sie sind und wie man sie vermeidet.
4. Sind die Bilder auf Ihrer Website für Benutzer wichtig? Haben sie das alt-Attribut mit einem aussagekräftigen Wert?
5. Gibt es leere Links auf Ihrer Website? Haben Sie einen Link verwendet, wenn Sie einen Button hätten verwenden sollen?

Vorschlag: Lesen Sie die Checkliste des A11y Projects. Sie ist keineswegs erschöpfend, aber sie wird Ihnen den Einstieg erleichtern.

Und wissen Sie was? Ein guter Ort, um anzufangen, ist genau dort, wo Sie gerade sind. Eine gute Zeit, um anzufangen? Heute.

---

Headerbild von Scott Rodgerson auf Unsplash