Webdesigner haben eine Vision, und Webentwickler setzen sie um. Sie sind zwei Seiten derselben Medaille. Alle sind sich einig, dass eine erstklassige Benutzererfahrung die Barrierefreiheit für alle gewährleisten muss – warum tun wir uns dann immer noch so schwer damit, diese Absicht vom Design bis zur Entwicklung klar zu kommunizieren? Natürlich gibt es viele Gründe dafür, aber es beginnt mit einem verständlichen Mangel an Wissen über Barrierefreiheit. Barrierefreiheit wirkt kompliziert – offensichtlich zu kompliziert, um sich damit auseinanderzusetzen, ohne ein Experte zu sein. Hinzu kommt ein Mangel an Tools, die den Aufwand vereinfachen könnten, und … ich kann schon sehen, wie die Panik ausbricht.
Geh einfach… ein Stück… weg.
Doch 67 % der Probleme bei der Barrierefreiheit haben ihre Ursache im Design
Das stimmt. Meine Kollegen haben bereits 2020eine Fallstudie dazu mit einem Kundenerstellt, und nun ja, seitdem hat sich die Lage nicht wesentlich verbessert. Design-Systemen mangelt es nach wie vor kläglich an nativen Barrierefreiheitsfunktionen; sie sind weiterhin auf Plugins von Drittanbietern angewiesen, die größtenteils nur begrenzte Möglichkeiten bieten. Designer können nun Aspekte wie Farbkontrast, Größe der Touch-Zielbereiche und definierte Überschriften überprüfen, sodass der Anteil der Probleme, die ihren Ursprung im Design haben, zurückgegangen ist. Das ist ein Fortschritt. Deque bietet sogar ein Figma-Plugin an, das dabei hilft. Aber was ist mit Problemen, die zwischen Design und Entwicklung entstehen? Wie überbrücken wir diese Kluft?
Designer entwickeln Produkte nicht im Alleingang. Sie müssen mit vielen Beteiligten zusammenarbeiten – am engsten mit den Entwicklern, um Probleme hinsichtlich der Benutzerfreundlichkeit und technischer Aspekte bereits in einer frühen Phase des Prozesses zu lösen. Doch Missverständnisse kommen häufig vor, verursachen viele Reibungspunkte und Missverständnisse und führen zu Nacharbeiten, Stress und angespannten Beziehungen.
Es kommt ganz auf die Absicht an
Zunächst wollen wir den Begriff „Intent“ definieren. Es geht nicht darum, wie der Designer sich vorstellt, dass der Endnutzer die Seite erlebt. Das ist natürlich entscheidend, wird aber in der Regel in Designsystemen gut abgedeckt. In diesem Fall bedeutet „Intent“, wie und warum der Designer beabsichtigt, dass der Entwickler die Barrierefreiheit der Seitenkomponenten, der gesamten Seite und der gesamten Website verwaltet. Die Designer haben eine Vision davon, wie Ebenen gruppiert, Komponenten beschriftet und Aktionen definiert werden sollten und wie die verschiedenen Elemente ihres Designs einzeln und zusammenwirken, um die gewünschten Ergebnisse für die Nutzer zu erzielen. Es ist entscheidend, dass Entwickler diese Vision verstehen.
Wenn sie das nicht tun, können sie kein erfolgreiches Produkt entwickeln.
For instance, it’s easy to see what may appear to be an obvious component and think, “It looks like a button, it acts like a button, therefore, it’s a button.” Label it <button> and move on. And that makes sense…if you can see and touch the button. But what if the user is blind or disabled and uses assistive technology to help them navigate your page?
Ohne zu sehr ins Detail zu gehen: Wenn die Schaltfläche nicht mit visuell verborgenem beschreibendem Text, „aria-label“, entsprechenden Attributen usw. versehen ist, kann der Nutzer nicht verstehen, was sie darstellt oder wie er sie bedienen soll. Deshalb sind klare, vollständige Barrierefreiheitsangaben so wichtig. Sie bilden die Brücke, die Designern und Entwicklern hilft, eine gemeinsame Vision zu verfolgen. Das ist die Absicht.
Die Kluft überbrücken
Aber Sie und Ihre Entwicklerteams sprechen eigentlich unterschiedliche Sprachen. Und keiner von Ihnen beherrscht das Thema Barrierefreiheit fließend. Wie können Sie als Designer diese Absicht also klar vermitteln? Sie müssen Komponenten, Elemente, Organismen, Vorlagen usw. ordnungsgemäß mit Anmerkungen versehen und beschriften. Das mag einfach klingen, aber es gibt einige Hürden zu überwinden.
- Viele Designsysteme enthalten keine Anmerkungen
- Anmerkungen sollten am besten in einer Sprache verfasst werden, die Entwickler verstehen (z. B. Codeausschnitte)
- Anmerkungen zur Barrierefreiheit sind in KEINEM Designsystem enthalten (aber Verstöße gegen die Barrierefreiheit können ein digitales Produkt zum Scheitern bringen)
Automatisierung von Barrierefreiheits-Anmerkungen mit KI/ML
Mit dem richtigen Tool müssen Sie kein Programmiergenie oder Barrierefreiheitsexperte sein, um Barrierefreiheitsanforderungen zu ermitteln und Ihre Absichten Ihren Entwicklern klar zu vermitteln. Axe for Designers (Beta) bietet Funktionen zur automatischen Annotation mit kurzen Code-Schnipseln, sodass:
- Sie müssen sich nicht erst intensiv mit den komplexen WCAG*- oder WAI-ARIA*-Anforderungen auseinandersetzen und diese auswendig lernen, um bei Ihren Entwürfen mit der Barrierefreiheit zu beginnen.
- Entwickler müssen Ihre Absicht nicht durch das Schreiben ihres eigenen Codes interpretieren. Diese ist für sie bereits vorhanden. Selbst wenn sie den Code anpassen müssen, haben sie eine klare Ausgangsbasis.
Und da es auf KI/ML basiert, lernt es mit Ihnen mit und passt sich immer besser an Ihre spezifische Umgebung, Ihre Anforderungen und Ihre Bedürfnisse an.
Natürlich ersetzt dies nicht die Notwendigkeit, insgesamt eine hervorragende Beziehung und eine effektive Kommunikation zwischen Designern und Entwicklern zu pflegen. Wir sind jedoch der Meinung, dass es sich lohnt, eine Brücke zu schlagen, um Verständnislücken leichter zu schließen.
Erfahren Sie mehr über „axe for Designers“ (Beta).
