ARIA ist Spachtelmasse, kein Bewehrungsstahl

Ähnlich wie ihre physischen Gegenstücke haben die Materialien, die wir zum Erstellen von Websites verwenden, einen Zweck. Sie ohne Verständnis ihrer Stärken und Grenzen einzusetzen, ist unverantwortlich. Niemand möchte in einem schlecht gebauten Haus leben. Warum sind also schlecht gebaute Websites akzeptabel?

In diesem Beitrag werde ich WAI-ARIA behandeln und wie dessen falsche Anwendung mehr schaden als nutzen kann.

Materialien als Technologie

Im Bauwesen wird Spachtelmasse verwendet, um kleinere Mängel an Innenräumen zu beheben. Es ist eine dicke Paste, die zu einer festen Oberfläche trocknet, die geschliffen und übermalt werden kann. Die meisten Mieter lernen sie kennen, wenn sie versuchen, ihre Kaution zurückzubekommen.

Bewehrungsstahl ist ein Gitter aus Stahlstäben, das zur Verstärkung von Beton verwendet wird. Jedes moderne Gebäude verwendet ihn – die Wahrscheinlichkeit ist groß, dass Sie ihn sehen, wenn Sie an einer Baustelle von einiger Größe vorbeigehen.

Technologie als Materialien

HTML ist der mit Bewehrungsstahl verstärkte Beton des Webs. Um die Metapher zu dehnen: CSS sind die Innen- und Außendekoration, und JavaScript sind die Verkabelung und Sanitärinstallation.

Jedes Tag in HTML hat sogenannte native Semantik. Die Erstellung eines HTML-Elements kommuniziert dem Browser programmatisch, was dieses Tag darstellt. Das Schreiben eines button-Tags teilt dem Browser explizit mit: „Dies ist ein Button. Er tut Button-Dinge.“

Der Grund, warum dies so wichtig ist, liegt darin, dass assistive Technologien auf native Semantiken zugreifen und diese nutzen, um eine Navigationsschnittstelle zu erstellen. Eine Seite, die nicht semantisch beschrieben ist, ist sehr ähnlich wie ein Gebäude ohne Räume oder Fenster: Menschen, die über einen Screenreader navigieren, müssen ziellos im Dunkeln umherirren und hoffen, zufällig auf das zu stoßen, was sie brauchen.

ARIA steht für Accessible Rich Internet Applications und ist eine relativ neue Spezifikation, die entwickelt wurde, um assistive Technologien dabei zu helfen, besser mit dynamischen, JavaScript-gesteuerten Inhalten zu kommunizieren. Sie soll bestehende semantische Attribute ergänzen, indem sie Screenreadern und anderen assistiven Technologien erweiterte Interaktivität und Kontext bietet.

Spachtelmasse zum Mauern verwenden

Ein besorgniserregender Trend, den ich in letzter Zeit beobachte, ist die blinde, massenhafte Anwendung von ARIA. Es fühlt sich an wie der Versuch von Entwicklern, die Barrierefreiheit per Schrotflinte zu erreichen – genug von etwas auf ein Ziel werfen und darauf vertrauen, dass man es irgendwann trifft.

Leider birgt dieser Ansatz eine sehr reale Gefahr. Falsch angewendetes ARIA kann mehr schaden als nutzen.

Die in ARIA inhärente Semantik bedeutet, dass es bei unsachgemäßer Anwendung ein dissonantes, widersprüchliches Durcheinander erzeugen kann, wenn es über einen Screenreader gelesen wird. Anstatt zu hören: „Dies ist ein Button. Er tut Button-Dinge.“, beginnen die Leute Dinge zu hören wie: „Dies ist nichts, aber auch ein Button. Aber es ist auch eine deaktivierte Checkbox, die deaktiviert ist und das ständig schreien muss.“

Wenn Sie ein natives HTML-Element oder Attribut verwenden können, das die von Ihnen benötigten Semantiken und Verhaltensweisen bereits integriert hat, anstatt ein Element umzufunktionieren und eine ARIA-Rolle, einen Status oder eine Eigenschaft hinzuzufügen, um es zugänglich zu machen, dann tun Sie das.
– Erste Regel der ARIA-Nutzung

Außerdem ist ARIA eine neue Technologie. Das bedeutet, dass die Browserunterstützung und das Verhalten variieren. Obwohl ich optimistisch bin, dass die großen Browser in Zukunft eine vollständige und einheitliche Unterstützung haben werden, hat die aktuelle Landschaft Lücken und Fehler.

Eine weitere wichtige Überlegung ist, wer die Technologie tatsächlich nutzt. Compliance ist keine rein akademische Eitelkeitsmetrik, die wir anstreben. Wir bauen robuste Systeme für echte Menschen, die es ihnen ermöglichen, das zu bekommen, was sie wollen oder brauchen, mit so wenig Komplikationen wie möglich. Viele Menschen, die assistive Technologien nutzen, zögern, Upgrades durchzuführen, aus Angst, die Funktionalität zu beeinträchtigen. Haben Sie sich jemals geärgert, wenn Ihr Lieblingsprogramm neu gestaltet wird und Sie es neu lernen müssen? Ja.

Die Stärke des Webs liegt in seiner Universalität. Zugang für alle, unabhängig von Behinderungen, ist ein wesentlicher Aspekt.
– Tim Berners-Lee

Es fühlt sich unehrlich an, die Vorteile des DRY-Prinzips von massiven JavaScript-Frameworks zu sehen und gleichzeitig redundante und falsch angewendete Attribute in ihren Markup zu schmierieren. Das Web ist standardmäßig zugänglich. Zum Guten oder Schlechten sind wir frei, danach zu tun, was wir wollen.

Die Lösung

Das soll nicht heißen, dass wir ARIA komplett vermeiden sollten. Wenn es mit Geschick und Präzision angewendet wird, kann es eine verwirrende oder frustrierende Benutzererfahrung in eine intuitive und mühelose Erfahrung verwandeln, mit weitaus weniger brüchigen Hacks und Workarounds.

Wenig reicht weit. Bevor Sie andere Optionen in Betracht ziehen, beginnen Sie mit Markup, das den Inhalt, den es umschließt, semantisch beschreibt. Testen Sie ausgiebig und wenden Sie ARIA nur an, wenn Mängel zwischen den nativen HTML-Semantiken und den JavaScript-Interaktionen auftreten.

Entwicklungsteams werden den Vorteil von prägnantem Code schätzen, der einfacher zu warten ist. Raffinierte Entwickler nutzen einen CSS-Trick™ und verwenden CSS-Attributselektoren, um Systeme zu erstellen, bei denen die visuelle Darstellung an die semantische Bedeutung gebunden ist.

input:invalid,
[aria-invalid] {
  border: 4px dotted #f64100;
}

Beispiele

Hier sind einige der häufigeren Muster, die ich in letzter Zeit gesehen habe, und warum sie problematisch sind. Das bedeutet nicht, dass dies die einzigen Arten von Fehlern sind, aber es ist eine gute Einführung, um zu erkennen, was man nicht tun sollte.

<li role="listitem">Hold the Bluetooth button on the speaker for three seconds to make the speaker discoverable</li>

Die Rolle ist redundant. Die nativen Semantiken des li-Elements beschreiben es bereits als Listenpunkt.

<p role="command">Type CTRL+P to print</p>

command ist eine abstrakte Rolle. Sie wird nur in ARIA verwendet, um dessen Taxonomie zu beschreiben. Nur weil ein ARIA-Attribut anwendbar zu sein scheint, heißt das nicht, dass es das auch unbedingt ist. Außerdem könnte das kbd-Tag für „CTRL“ und „P“ verwendet werden, um den Tastaturbefehl genauer zu beschreiben.

<div role="button" class="button">Link to device specifications</div>

Das Nichtverwenden eines button-Tags birgt das Risiko, nicht alle verschiedenen Arten zu berücksichtigen, wie ein Benutzer mit einem Button interagieren kann und wie der Browser darauf reagiert. Außerdem sollte das a-Tag für Links verwendet werden.

<body aria-live="assertive" aria-atomic="true">

Normalerweise ist die Absicht hinter so etwas, Aktualisierungen für den Screenreader-Benutzer offenzulegen. Leider werden bei Beschränkung auf das Body-Tag jede Seitenänderung – einschließlich aller JS-bezogenen Updates – sofort angekündigt. Eine Einstellung von assertive für aria-live bedeutet auch, dass jede Aktualisierung unterbricht, was der Benutzer gerade tut. Dies ist eine katastrophale Erfahrung, insbesondere für Single-Page-Anwendungen.

<div aria-checked="true"></div>

Sie können ein natives Checkbox-Element so gestalten, wie Sie möchten. Bessere Unterstützung! Weniger Arbeit!

<div role="link" tabindex="40">
  Link text
</div>

Ja, das ist echter Produktionscode. Wo anfangen? Erstens, verwenden Sie niemals einen tabindex-Wert größer als 0. Zweitens, das title-Attribut tut wahrscheinlich nicht das, was Sie denken. Drittens sollte das Anker-Tag ein Ziel haben – Links führen schließlich irgendwohin. Viertens ist die Rolle link, die einem div zugewiesen ist, das ein a-Element umschließt, völlig überflüssig.

<h2 class="h3" role="heading" aria-level="1">How to make a perfect soufflé every time</h2>

Die Anerkennung gebührt, wem sie gebührt: Nicolas Steenhout beschreibt die Probleme hierfür.

Machen Sie es besser

Ähnlich wie bei Inhalten sollte Markup beim Erstellen einer Website keine nachträgliche Überlegung sein. Ich glaube, die meisten Leute versuchen die meiste Zeit wirklich ihr Bestes, aber eine Technologie zu nutzen, ohne deren Auswirkungen zu kennen, ist gefährlich und unverantwortlich.

Ich bin normalerweise eher vom Typ Honig statt Essig, wenn ich Leute dazu bringe, Barrierefreiheit zu praktizieren, aber nicht hier. Dies ist kein sanfter Verkauf über die Vorteile der Entwicklung und des Designs mit einem zugänglichen, integrativen Denkweise. Dies ist ein Beitrag zum Machen Ihrer Arbeit.

Jede Entscheidung, die ein Team trifft, beeinflusst die Zugänglichkeit einer Website.
– Laura Kalbag

Werden Sie besser im Authoring

Lernen Sie etwas über die verfügbaren HTML-Tags, was sie beschreiben und wie man sie am besten verwendet. Dasselbe gilt für ARIA. Schenken Sie den Semantiken Ihrer Seitenvorlage die gleiche Sorgfalt und Aufmerksamkeit, die Sie Ihrem JavaScript während Code-Reviews widmen.

Werden Sie besser im Testen

Es gibt kaum eine Entschuldigung, keinen Screenreader in Ihren Test- und QA-Prozess zu integrieren. NVDA ist kostenlos. macOS, Windows, iOS und Android verfügen alle über integrierte Screenreader. Einige nette Leute haben sogar Anleitungen geschrieben, die Ihnen helfen, sie zu lernen.

Automatisierte Barrierefreiheits-Tests sind ein großer Gewinn, aber auch kein Allheilmittel. Sie melden nicht, was sie nicht zu melden wissen, was bedeutet, dass es an einem Menschen liegt, manuell festzustellen, ob die Navigation durch die Website sinnvoll ist. Dies unterscheidet sich nicht von anderen Usability-Test-Vorhaben.

Bauen Sie bessere Gebäude

Universal Design lehrt uns, dass Websites, wie Gebäude, sowohl schön als auch zugänglich sein können. Wenn Sie nach einem Ausgangspunkt suchen, hier sind einige Ressourcen.

• A Book Apart: Accessibility for Everyone, von Laura Kalbag
• egghead.io: Intro to ARIA und Start Building Accessible Web Applications Today, von Marcy Sutton
• Google Developers: Introduction to ARIA, von Meggin Kearney, Dave Gash und Alice Boxhall
• YouTube: A11ycasts mit Rob Dodson, von Rob Dodson
• W3C: WAI-ARIA Authoring Practices 1.1
• W3C: Using ARIA
• Zomigi: Videos von Screenreadern, die ARIA verwenden
• Inclusive Components, von Heydon Pickering
• HTML5 Accessibility
• The American Foundation for the Blind: Improving Your Website’s Accessibility
• Designing for All: 5 Ways to Make Your Next Website Design More Accessible, von Carie Fisher
• Accessible Interface Design, von Nick Babich