Einleitung
Es ist die schönste Zeit des Jahres! Nein, ich meine nicht die Winterferien, sondern diese andere zauberhafte Zeit des Jahres, auf die sich Eltern sehnsüchtig erwarten und Lehrer fürchten – der Schulanfang! Aber Spaß beiseite: Ich war eines dieser streberhaften Kinder, die die Schule tatsächlich geliebt haben. Ich erinnere mich noch gut an den Geruch von Bleistiftspänen und Kreidestaub, an das Geräusch, wenn man ein neues Buch aufschlägt und den Buchrücken knackt, daran, alte Freunde wiederzusehen und neue Fächer zu lernen … was gibt es daran nicht zu lieben?
Heute sehen die meisten Erwachsenen das Lernen von Neuem etwas anders. Irgendwo zwischen unserer Schulzeit und dem Erwachsenenalter verändert sich für viele von uns die Kunst des Lernens. Beim Lernen geht es weniger darum, kreativ zu sein und Spaß zu haben, sondern es wird zu etwas Alltäglichem, Verpflichtendem oder sogar Bedrohlichem. Denken Sie einmal darüber nach – wann haben Sie sich das letzte Mal wirklich darauf gefreut, etwas Neues zu lernen?
Mit dieser Einführungsreihe zum Thema Barrierefreiheit möchte ich diese Begeisterung fürs Lernen wieder wecken und euch gleichzeitig eine Vielzahl von Themen aus der Welt der digitalen Barrierefreiheit näherbringen. Ich habe vor, diese Artikel leicht verständlich und sachlich zu halten und euch vor allem praktische Tipps zu geben, die ihr in euren Arbeitsalltag integrieren könnt.
ARIA, Erster Akt
Szene 1: Die Stiftung
ARIA wurde erstmals im Jahr 2008 von der Web Accessibility Initiative (WAI) entwickelt – einer Untergruppe des übergeordneten World Wide Web Consortium (W3C), das das Internet regelt und standardisiert. ARIA ist eine Abkürzung für „Accessible Rich Internet Applications“ und heißt offiziell WAI-ARIA (wird jedoch von vielen Menschen unter seiner Abkürzung bezeichnet).
Die WAI-Gruppe definiert ARIA wie folgt:
„Eine Methode, um Webinhalte und Webanwendungen für Menschen mit Behinderungen besser zugänglich zu machen. Sie ist insbesondere bei dynamischen Inhalten und komplexen Bedienelementen der Benutzeroberfläche hilfreich, die mit Ajax, HTML, JavaScript und verwandten Technologien entwickelt wurden.“
Einfacher ausgedrückt: ARIA definiert eine Reihe von Attributen, die dabei helfen, fehlerhafte Markups zu korrigieren und Lücken im HTML zu schließen, um Nutzern von assistiver Technologie (AT) eine barrierefreiere Erfahrung zu ermöglichen. Durch die korrekte Einbindung von ARIA in Ihren Code wird sichergestellt, dass Nutzer von assistiver Technologie über alle Informationen verfügen, die sie zur Nutzung Ihrer Website oder App benötigen.
Gemäß den Richtlinien weist ARIA drei Hauptmerkmale auf:
- Rollen — definieren, was ein Element ist oder welche Funktion es hat. Rollen können dabei helfen, Orientierungspunkte, die Struktur eines Dokuments sowie Widgets zu identifizieren. Ein Beispiel hierfür ist:
<div role="button">Here is a snazzy button</div>
- Eigenschaften — beschreiben Eigenschaften oder Beziehungen eines Objekts. Ein Beispiel hierfür unter Verwendung von `aria-describedby` lautet:
<div role="button" aria-describedby="some-other-element">Here is a snazzy button</div> <div id="some-other-element">This page will self destruct in 10 seconds.</div>
- Zustände oder Werte — definieren die aktuellen Bedingungen oder Datenwerte, die mit dem Element verbunden sind. Ein Beispiel hierfür unter Verwendung von `aria-pressed` lautet:
<div role="button" aria-describedby="some-other-element" aria-pressed="false">Here is a snazzy button</div> <div id="some-other-element">This page will self destruct in 10 seconds.</div>
Natürlich handelt es sich hierbei um eine vereinfachte Erklärung von ARIA, und die obigen Code-Beispiele sind stark gestrafft, um die Funktionsweise von ARIA zu veranschaulichen (d. h., bei einer echten Schaltfläche würden Sie zusätzlichen Code einfügen wollen). Wenn Ihr Code komplexer wird, können ARIA-Rollen, -Eigenschaften und -Zustände schichtweise hinzugefügt werden, bis das endgültige Barrierefreiheitsziel erreicht ist. Die Kenntnis der Grundregeln jeder ARIA-Rolle, -Eigenschaft und jedes ARIA-Zustands kann Ihnen dabei helfen, herauszufinden, welche Elemente an welcher Stelle in Ihrem Markup platziert werden müssen.
Vielleicht befürchten Sie nun, dass ARIA die Funktionalität Ihrer Webseite sowie deren Gesamterscheinungsbild verändern könnte – das ist jedoch nicht der Fall! ARIA verändert die native Browserfunktionalität tatsächlich in keiner Weise. Stellen Sie sich ARIA als eine zusätzliche Ebene des Verständnisses zwischen HTML und assistiven Technologien vor. Ebenso verändert ARIA Ihre Webseite aus visueller Sicht nicht, es sei denn, Sie fügen Ihrem CSS Stile hinzu, die speziell auf ARIA ausgerichtet sind. Das bedeutet, dass niemand außer assistiven Technologien (und den Menschen, die diese nutzen) Unterschiede zwischen einer Webseite oder App mit ARIA und einer ohne ARIA bemerken wird.
Szene 2: ARIA vs. HTML
In 2014, the W3C officially published the HTML5 recommendation to the world. With it came some big changes, including the addition of elements such as `<main>`, `<header>`, `<footer>`, `<aside>`, `<nav>` and attributes like `hidden` and `required`. With the addition of these new HTML5 elements and attributes coupled with increased browser support, parts of ARIA are now obsolete – or at least less critical than before.
Wenn der Browser ein HTML-Tag mit einer impliziten Rolle unterstützt, für die es ein ARIA-Äquivalent gibt, ist es in der Regel nicht erforderlich, dem Element zusätzlich ARIA-Attribute hinzuzufügen. ARIA umfasst jedoch nach wie vor viele Rollen, Zustände und Eigenschaften, die in keiner HTML-Version verfügbar sind, sodass diese noch für einige Zeit nützlich bleiben werden.
Um es für Anfänger einfach zu halten, wiederholen wir bei den Schulungen von „ Deque “ die erste Regel von ARIA, die vom W3C aufgestellt wurde:
„Wenn Sie ein natives HTML-Element oder -Attribut verwenden können, das bereits über die von Ihnen benötigte Semantik und das gewünschte Verhalten verfügt, anstatt ein Element umzufunktionieren und eine ARIA-Rolle, einen ARIA-Status oder eine ARIA-Eigenschaft hinzuzufügen, um es barrierefrei zu gestalten, dann tun Sie dies.“
So if we look back at the earlier coding example, instead of using ARIA to define the role of our button element, we can use the HTML `<button>` element instead.
Originalcode (nur mit ARIA):
<div role="button">Here is a snazzy button</div>
Neuer Code (nur mit HTML):
<button>Here is a snazzy button</button>
Neuer Code (mit HTML + ARIA):
<button aria-describedby="some-other-element">Here is a snazzy button</button> <div id="some-other-element">This page will self destruct in 10 seconds.</div>
Technically, each example conveys the same semantics, but the big difference is the ARIA only version requires us to define the functionality of the button role with additional code, while the HTML versions work right out of the box for browsers that support the `<button>` element.* When we combine the powers of HTML and ARIA as shown in the last example, we provide additional information about the button’s purpose.
*Hinweis: Da die <button> Da dieses Element bereits in HTML4 eingeführt wurde, kann ich mit Fug und Recht davon ausgehen, dass es von den neuesten Versionen aller gängigen Browser vollständig unterstützt wird und mit den meisten assistiven Technologien gut zusammenarbeitet. Das Gleiche lässt sich jedoch nicht über alle neueren HTML5-Elemente und -Attribute sagen. Um die Browserkompatibilität zu überprüfen, nutze ich häufig Websites wie Barrierefreiheit in HTML5, Kann ich das verwenden?, oder die Liste des W3C mit ARIA in HTML-Attributen bevor ich mich entscheide, ob ich für ein bestimmtes Muster HTML- oder ARIA-Elemente verwenden kann. Auf dieses Thema werde ich in einem Folgebeitrag zum Thema ARIA noch etwas ausführlicher eingehen.
Barrierefreiheitsexperten und Nutzer von assistiven Technologien vertreten unterschiedliche Meinungen zum Thema „ARIA vs. HTML“ und werden dieses Thema wahrscheinlich noch sehr lange diskutieren. Diese Diskussionen sind in einer theoretischen Welt, in der ein auf Barrierefreiheit bedachter Entwickler die volle Kontrolle über das Markup, das Styling und die Funktionalität einer Website oder App hätte, durchaus sinnvoll. Die Realität ist jedoch oft komplexer.
For example, there may be times where you cannot change all the `<div role=”button”>`’s on your page to `<button>`’s and that is maybe not ideal, but it is OK. If you do have more control over your website or app code, by all means, add in fully supported HTML elements (and any ARIA helpers you may need) from the beginning. But from a practical sense, I encourage other developers to just do what works for your particular situation and be sure to test your code before releasing it. Even if you only change one small piece of code at a time – every little bit helps!
Szene 3: ARIA in Aktion
Wie bereits weiter oben in diesem Artikel erwähnt, empfiehlt es sich, native HTML-Elemente zu verwenden, wenn die Browserunterstützung gut ist. Bei korrekter Programmierung können und sollten ARIA-Elemente jedoch wie native HTML-Elemente funktionieren. So haben Sie eine gewisse Flexibilität bei der Verbesserung der Barrierefreiheit Ihres Musters!
I find it more useful to see code examples rather than explain them, so let’s break down a typical pattern you might find on a website or app in more detail. For this article, we will look at radio buttons and groups. All radio groups require a group label of some kind. The classic method is using `<fieldset>` and `<legend>`. The ARIA method of `role=”radiogroup”` and `aria-labelledby` can also be used. Both are technically correct, so depending on your situation you could use either method and that would result in a similar experience for the user.
Method 1: Using HTML `<fieldset>` and `<legend>` elements:
<fieldset class="deque-radio-group"> <legend class="deque-radio-group-label">What's your favorite flavor of ice cream?</legend> <div id="radioGroup"> <span id="Whatsyourfavoriteflavor_0" class="deque-radio" aria-labelledby="vanilla"></span> <span id="vanilla">Vanilla</span> <span id="Whatsyourfavoriteflavor_1" class="deque-radio" aria-labelledby="chocolate"></span> <span id="chocolate">Chocolate</span> <span id="Whatsyourfavoriteflavor_2" class="deque-radio" aria-labelledby="strawberry"></span> <span id="strawberry">Strawberry</span> <span id="Whatsyourfavoriteflavor_3" class="deque-radio" aria-labelledby="none"></span> <span id="none">I prefer cake</span> </div> </fieldset>
Option 2: Verwendung von ARIA `role="radiogroup"` und `aria-labelledby` :
<div class="deque-radio-group" role="radiogroup" aria-labelledby="inspire"> <div class="deque-radio-group-label" id="inspire"> Which one of these scientists most inspires you?</div> <div id="radioGroup"> <span id="Whichoneofthesescientistsmostinspiresyou_0" class="deque-radio" aria-labelledby="curie"></span> <span id="curie">Marie Curie</span> <span id="Whichoneofthesescientistsmostinspiresyou_1" class="deque-radio" aria-labelledby="goodall"></span> <span id="goodall">Jane Goodall</span> <span id="Whichoneofthesescientistsmostinspiresyou_2" class="deque-radio" aria-labelledby="franklin"></span> <span id="franklin">Rosalind Franklin</span> <span id="Whichoneofthesescientistsmostinspiresyou_3" class="deque-radio" aria-labelledby="lamarr"></span> <span id="lamarr">Hedy Lamarr</span> </div> </div>
Screenshot von Option 1

Screenshot von Option 2

Wie Sie auf den Screenshots sehen können, ist die visuelle Darstellung sowohl beim HTML- als auch beim ARIA-Radio-Muster identisch. Auch aus funktionaler Sicht sollten sie im Wesentlichen gleich sein, allerdings gibt es einige Unterschiede zwischen den verschiedenen Kombinationen aus Browsern und assistiven Technologien. Es gibt keine Einheitslösung, die für alle Fälle passt, daher muss jedes Muster möglicherweise an Ihre jeweiligen Anforderungen an die Barrierefreiheit angepasst werden. Ein Live-Beispiel für den oben genannten Code finden Sie unter https://codepen.io/cariefisher/pen/VGPEBo.
Szene 4: Die Komplexität von ARIA
Natürlich wäre dieser Artikel ohne ein paar Warnhinweise zu ARIA nicht vollständig. Erstens: Seien Sie vorsichtig, wenn Sie ARIA in Ihr Markup einfügen! Dies ist ein Bereich, in dem ein wenig Programmierwissen bei falscher Anwendung schädlich (oder einfach nur nervig) sein kann. Ein Mentor sagte mir einmal: „Schlechtes ARIA ist schlimmer als gar kein ARIA“ – weise Worte, nach denen ich bei jeder Zeile Code, die ich schreibe, zu leben versuche. Manchmal fügen wir in der Absicht, zu helfen, zu viele oder die falschen ARIA-Attribute hinzu. Denken Sie daran, es einfach zu halten.
Zweitens: Auch wenn die von uns behandelten Muster für Schaltflächen und Optionsfelder bzw. Optionsfeldgruppen relativ einfach sind, kann die Erstellung barrierefreier benutzerdefinierter Muster sehr schnell sehr kompliziert werden. Es gibt viele Dinge zu beachten (unter anderem) – Tastatur-, Mobil- und Touch-Interaktionen, Best Practices für die ARIA-Erstellung oder sogar die grundlegende Entscheidung, ob man sich überhaupt für HTML oder ARIA entscheiden soll. Versuchen Sie, die Bedürfnisse Ihrer Nutzer zu antizipieren, und testen Sie Ihren Code unbedingt auf Barrierefreiheit. Wenn Sie Nutzer von assistiven Technologien finden (und bezahlen) können, die beim Testen helfen – umso besser. Stellen Sie zumindest sicher, dass es eine barrierefreie Möglichkeit gibt, über die ein Nutzer ein Bug-Ticket einreichen kann, falls er ein Problem entdeckt.
Abgesehen von diesen Warnungen ist digitale Barrierefreiheit keineswegs eine „Alles-oder-nichts“-Situation – es handelt sich vielmehr um ein Spektrum, das gewisse Grauzonen wie diese zulässt, in denen je nach Situation mehrere Programmierlösungen als „richtig“ angesehen werden können. Wichtig ist, dass ihr weiter lernt, testet und versucht, unsere digitale Welt für alle offener zu gestalten!
ARIA, Erster Akt: Zusammenfassung
Hoffentlich hat Ihnen dieser Artikel einen kurzen Einblick in die vielfältige Welt von ARIA gegeben. Hier sind einige wichtige Erkenntnisse:
- ARIA definiert eine Reihe von Attributen, die dabei helfen sollen, fehlerhafte Markups zu korrigieren und Lücken im HTML zu schließen, um Nutzern von assistiver Technologie (AT) eine barrierefreiere Nutzung zu ermöglichen.
- Durch die korrekte Einbindung von ARIA in Ihren Code wird sichergestellt, dass alle Nutzer über die Informationen verfügen, die sie zur Nutzung Ihrer Website oder App benötigen.
- ARIA lässt sich wie folgt unterteilen:
- Rollen –definieren, was ein Element ist oder welche Funktion es erfüllt.
- Eigenschaften –beschreiben Merkmale oder Beziehungen eines Objekts.
- Zustände und Werte – definieren die aktuellen Zustände oder Datenwerte, die mit dem Element verbunden sind.
- Rollen –definieren, was ein Element ist oder welche Funktion es erfüllt.
- ARIA allein verändert weder die Funktionalität noch das allgemeine Erscheinungsbild Ihrer Website oder App.
- Es gibt mehr als eine Möglichkeit, barrierefreien Code zu schreiben. HTML kann oft durch ARIA ersetzt oder ergänzt werden – allerdings sollten Sie zunächst prüfen, ob der Browser dies unterstützt.
- Im Zweifelsfall sollten Sie ein vom Browser unterstütztes HTML-Element verwenden und auf ARIA verzichten. Falsch eingesetzte ARIA-Attribute können schlimmer sein als gar keine ARIA-Attribute!
- Testen Sie Ihren Code – vorzugsweise mit Hilfe von Nutzern von assistiven Technologien. Stellen Sie zumindest eine barrierefreie Möglichkeit bereit, diese Fehler zu melden.
Da sich dieser Artikel an Anfänger richtete, habe ich einige wichtige Themen bewusst nur kurz angesprochen. Im nächsten Artikel über ARIA möchte ich mich mit einigen Fragen für Fortgeschrittene befassen, wie zum Beispiel:
- Woher weiß ich, welches ARIA- oder HTML-Element ich wählen soll?
- Wo wird ARIA unterstützt?
- Wie führe ich einen ARIA-Test durch?
Falls ihr weitere allgemeine Fragen zu ARIA habt, lasst es mich bitte in den Kommentaren wissen! Um in der Zwischenzeit noch fundiertere Kenntnisse über ARIA zu erwerben und weitere Musterbeispiele in der Praxis zu sehen, könnt ihr euch für unsere Kurse der „Deque -Universität“ anmelden.
