WAI-ARIA-Grundlagen

Was ist WAI-ARIA?

Sehen wir uns zunächst an, was WAI-ARIA ist und was es leisten kann.

Eine ganze Reihe neuer Probleme

Als Web-Apps komplexer und dynamischer wurden, entstanden neue Anforderungen und Probleme im Bereich der Barrierefreiheit.

HTML führte beispielsweise mehrere semantische Elemente ein, um häufige Bereiche einer Seite zu kennzeichnen (<nav>, <footer> usw.). Bevor diese verfügbar waren, verwendeten Entwickler <div>-Elemente mit IDs oder Klassen, etwa <div class="nav">. Das war problematisch, weil sich ein bestimmter Seitenbereich wie die Hauptnavigation nicht ohne Weiteres programmatisch finden ließ.

Eine erste Lösung bestand darin, am Anfang der Seite einen oder mehrere versteckte Links einzufügen, die zur Navigation oder zu anderen Bereichen führten, zum Beispiel:

<a href="#hidden" class="hidden">Skip to navigation</a>

Das ist jedoch immer noch nicht besonders präzise und funktioniert nur, wenn der Screenreader die Seite von Anfang an liest.

Ein weiteres Beispiel sind komplexe Steuerelemente in Apps, etwa Datumsauswahlfelder oder Schieberegler zur Auswahl von Werten. HTML bietet spezielle Eingabetypen, um solche Steuerelemente darzustellen:

<input type="date" /> <input type="range" />

Diese wurden ursprünglich nicht gut unterstützt. Außerdem war und ist es, wenn auch inzwischen in geringerem Maße, schwierig, ihr Erscheinungsbild anzupassen. Deshalb entschieden sich Designer und Entwickler häufig für eigene Lösungen. Statt diese nativen Funktionen zu verwenden, setzen manche Entwickler auf JavaScript-Bibliotheken, die solche Steuerelemente als Reihe verschachtelter <div>-Elemente erzeugen. Diese werden anschließend mit CSS gestaltet und mit JavaScript gesteuert.

Das Problem dabei: Visuell funktionieren sie, aber Screenreader können nicht erkennen, worum es sich handelt. Ihren Nutzern wird lediglich eine Ansammlung von Elementen ohne Semantik präsentiert, die deren Bedeutung erklärt.

Hier kommt WAI-ARIA ins Spiel

WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) ist eine vom W3C verfasste Spezifikation. Sie definiert zusätzliche HTML-Attribute, die Elementen weitere Semantik verleihen und die Barrierefreiheit dort verbessern können, wo sie fehlt. Die Spezifikation definiert drei Hauptbestandteile:

Rollen

Sie legen fest, was ein Element ist oder tut. Viele davon sind sogenannte Landmark-Rollen. Sie entsprechen weitgehend der Semantik struktureller Elemente, etwa role="navigation" (<nav>), role="banner" (<header> des Dokuments), role="complementary" (<aside>) oder role="search" (<search>). Andere Rollen beschreiben Seitenstrukturen, für die es kein entsprechendes HTML-Element gibt, beispielsweise role="tablist" und role="tabpanel", die häufig in Benutzeroberflächen vorkommen.

Eigenschaften

Sie beschreiben Merkmale von Elementen und können ihnen zusätzliche Bedeutung oder Semantik verleihen. Beispielsweise gibt aria-required="true" an, dass eine Formulareingabe ausgefüllt werden muss, damit sie gültig ist. Mit aria-labelledby="label" können Sie einem Element eine ID zuweisen und dieses Element dann als Beschriftung für andere Elemente auf der Seite referenzieren – auch für mehrere zugleich. Das ist mit <label for="input"> nicht möglich. Sie könnten aria-labelledby beispielsweise verwenden, um eine wichtige Beschreibung in einem <div> als Beschriftung für mehrere Tabellenzellen festzulegen. Ebenso lässt sich damit vorhandener Text auf der Seite als Alternativtext für ein Bild verwenden, statt ihn im alt-Attribut zu wiederholen. Ein Beispiel finden Sie unter Textalternativen.

Zustände

Das sind spezielle Eigenschaften, die den aktuellen Zustand eines Elements beschreiben. Beispielsweise teilt aria-disabled="true" einem Screenreader mit, dass eine Formulareingabe derzeit deaktiviert ist. Anders als Eigenschaften, die sich während der Laufzeit einer App nicht ändern, können sich Zustände ändern – normalerweise programmatisch über JavaScript.

Wichtig ist: WAI-ARIA-Attribute ändern an der Webseite nichts außer den Informationen, die über die Accessibility-APIs des Browsers bereitgestellt werden. Aus diesen APIs beziehen Screenreader ihre Informationen. WAI-ARIA verändert weder die Seitenstruktur noch das DOM. Die Attribute können allerdings nützlich sein, um Elemente mit CSS auszuwählen.

Wo wird WAI-ARIA unterstützt?

Diese Frage ist nicht einfach zu beantworten. Es ist schwierig, eine abschließende Quelle dafür zu finden, welche WAI-ARIA-Funktionen wo unterstützt werden, denn:

1. Die WAI-ARIA-Spezifikation umfasst viele Funktionen.
2. Es gibt zahlreiche Kombinationen aus Betriebssystemen, Browsern und Screenreadern zu berücksichtigen.

Der zweite Punkt ist entscheidend: Damit ein Screenreader überhaupt verwendet werden kann, muss das Betriebssystem Browser unterstützen, die über die erforderlichen Accessibility-APIs verfügen und die benötigten Informationen bereitstellen. Für die meisten verbreiteten Betriebssysteme gibt es ein oder zwei Browser, mit denen Screenreader zusammenarbeiten können.

Darüber hinaus müssen die betreffenden Browser ARIA-Funktionen unterstützen und über ihre APIs bereitstellen. Ebenso müssen Screenreader diese Informationen erkennen und ihren Nutzern sinnvoll vermitteln.

1. Die Browser-Unterstützung ist nahezu universell.
2. Die Unterstützung von ARIA-Funktionen durch Screenreader ist noch nicht ganz so umfassend, aber die verbreitetsten Screenreader kommen diesem Stand näher. Einen Eindruck vom Unterstützungsgrad vermittelt der Powermapper-Artikel WAI-ARIA Screen reader compatibility.

In diesem Artikel versuchen wir nicht, jede WAI-ARIA-Funktion und ihre genaue Unterstützung abzudecken. Stattdessen behandeln wir die wichtigsten Funktionen, die Sie kennen sollten. Wenn wir keine Einschränkungen bei der Unterstützung erwähnen, können Sie davon ausgehen, dass die Funktion gut unterstützt wird. Ausnahmen weisen wir ausdrücklich aus.

Wann sollten Sie WAI-ARIA verwenden?

Einige der Probleme, die zur Entwicklung von WAI-ARIA geführt haben, haben wir bereits angesprochen. Im Wesentlichen ist WAI-ARIA in vier Bereichen nützlich:

Orientierungspunkte/Landmarks

Die Werte des ARIA-Attributs role können als Landmarks dienen. Sie können die Semantik von HTML-Elementen wie <nav> nachbilden oder über die HTML-Semantik hinaus Orientierung für verschiedene Funktionsbereiche bieten, etwa mit search, tablist, tab oder listbox.

Dynamische Inhaltsaktualisierungen

Screenreader haben oft Schwierigkeiten, sich ständig ändernde Inhalte zu melden. Mit aria-live können wir Screenreader-Nutzer darüber informieren, wenn ein Inhaltsbereich dynamisch aktualisiert wird – beispielsweise wenn JavaScript auf der Seite neue Inhalte vom Server abruft und das DOM aktualisiert.

Verbesserung der Tastaturzugänglichkeit

Einige HTML-Elemente sind von Haus aus per Tastatur zugänglich. Werden andere Elemente zusammen mit JavaScript verwendet, um ähnliche Interaktionen nachzubilden, leiden darunter die Tastaturzugänglichkeit und die Ausgabe durch Screenreader. Wo sich das nicht vermeiden lässt, bietet WAI-ARIA eine Möglichkeit, andere Elemente fokussierbar zu machen (mit tabindex).

Barrierefreiheit nicht semantischer Steuerelemente

Werden verschachtelte <div>-Elemente zusammen mit CSS und JavaScript verwendet, um eine komplexe UI-Funktion zu erstellen, oder wird ein natives Steuerelement durch JavaScript stark erweitert oder verändert, kann die Barrierefreiheit leiden. Ohne Semantik oder andere Hinweise fällt es Screenreader-Nutzern schwer zu erkennen, was die Funktion bewirkt. In solchen Fällen kann ARIA die fehlenden Informationen ergänzen: Rollen wie button, listbox oder tablist und Eigenschaften wie aria-required oder aria-posinset geben weitere Hinweise auf die Funktionalität.

Im nächsten Abschnitt sehen wir uns diese vier Bereiche anhand von Beispielen genauer an. Bevor Sie weiterlesen, sollten Sie eine Testumgebung mit einem Screenreader einrichten, damit Sie die Beispiele ausprobieren können. Weitere Informationen finden Sie in unserem Abschnitt zum Testen mit Screenreadern.

Orientierungspunkte/Landmarks

WAI-ARIA ergänzt das role-Attribut, mit dem Sie Elementen Ihrer Website bei Bedarf zusätzliche semantische Bedeutung geben können. Ein wichtiger Einsatzbereich ist die Bereitstellung von Informationen für Screenreader, damit ihre Nutzer häufige Seitenbereiche finden können. Dieses Beispiel hat die folgende Struktur:

<header>
  <h1>Header</h1>

  <!-- Even is it's not mandatory, it's common practice to put the main navigation menu within the main header -->

  <nav>
    <ul>
      <li><a href="#">Home</a></li>
      <li><a href="#">Team</a></li>
      <li><a href="#">Projects</a></li>
      <li><a href="#">Contact</a></li>
    </ul>

    <!-- A search box is another common non-linear way to navigate through a website. -->

    <div class="search-controls">
      <input type="search" name="q" placeholder="Search query" />
      <input type="button" value="Go!" />
    </div>
  </nav>
</header>

<!-- Here is our page's main content -->
<main>
  <!-- It contains an article -->
  <article>
    <h2>Article heading</h2>

    <p>
      Lorem ipsum dolor sit amet, consectetur adipisicing elit. Donec a diam
      lectus. Set sit amet ipsum mauris. Maecenas congue ligula as quam viverra
      nec consectetur ant hendrerit. Donec et mollis dolor. Praesent et diam
      eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue
      enim, ut porta lorem lacinia consectetur.
    </p>

    <h3>subsection</h3>

    <p>
      Donec ut librero sed accu vehicula ultricies a non tortor. Lorem ipsum
      dolor sit amet, consectetur adipisicing elit. Aenean ut gravida lorem. Ut
      turpis felis, pulvinar a semper sed, adipiscing id dolor.
    </p>
  </article>

  <!-- the aside content can also be nested within the main content -->
  <aside>
    <h2>Related</h2>

    <ul>
      <li><a href="#">Oh I do like to be beside the seaside</a></li>
      <li><a href="#">Oh I do like to be beside the sea</a></li>
      <li><a href="#">Although in the North of England</a></li>
      <li><a href="#">It never stops raining</a></li>
      <li><a href="#">Oh well...</a></li>
    </ul>
  </aside>
</main>

<!-- And here is our main footer that is used across all the pages of our website -->

<footer>
  <p>©Copyright 2050 by nobody. All rights reversed.</p>
</footer>

/* || General setup */

html,
body {
  margin: 0;
  padding: 0;
}

html {
  font-size: 10px;
  background-color: darkgrey;
}

body {
  width: max(70vw, 90%);
  margin: 0 auto;
  padding: 0 10px;
  display: flex;
  flex-direction: column;
}

/* || typography */

h1,
h2,
h3 {
  font-family: "Sonsie One", cursive;
  color: #2a2a2a;
}

p,
input,
li {
  font-family: "Open Sans Condensed", sans-serif;
  color: #2a2a2a;
}

h1 {
  font-size: 4rem;
  text-align: center;
  color: white;
  text-shadow: 2px 2px 10px black;
}

h2 {
  font-size: 3rem;
  text-align: center;
}

h3 {
  font-size: 2.2rem;
}

p,
li {
  font-size: 1.6rem;
  line-height: 1.5;
}

/* || header layout */

header {
  margin-bottom: 10px;
}

nav,
article,
aside,
footer {
  background-color: white;
  padding: 1%;
}

nav {
  background-color: #ff80ff;
  display: flex;
  gap: 2vw;
  @media (width <= 650px) {
    flex-direction: column;
  }
}

nav ul {
  padding: 0;
  list-style-type: none;
  flex: 2;
  display: flex;
  gap: 2vw;
}

nav li {
  display: inline;
  text-align: center;
}

nav a {
  display: inline-block;
  font-size: 2rem;
  text-transform: uppercase;
  text-decoration: none;
  color: black;
}

nav .search-controls,
nav search {
  flex: 1;
  display: flex;
  align-items: center;
  height: 100%;
}

input {
  font-size: 1.6rem;
  height: 32px;
}

input[type="search"] {
  flex: 3;
}

input[type="button"] {
  flex: 1;
  margin-left: 1rem;
  background: #333333;
  border: 0;
  color: white;
}

/* || main layout */

main {
  display: flex;
  gap: 2vw;
  @media (width <= 650px) {
    flex-direction: column;
  }
}

article {
  flex: 4;
}

aside {
  flex: 1;
  background-color: #ff80ff;
}

aside li {
  padding-bottom: 10px;
}

footer {
  margin-top: 10px;
}

Wenn Sie das Beispiel mit einem Screenreader in einem modernen Browser testen, erhalten Sie bereits einige nützliche Informationen. VoiceOver gibt beispielsweise Folgendes aus:

• Für das <header>-Element: „banner, 2 items“ (es enthält eine Überschrift und das <nav>-Element).
• Für das <nav>-Element: „navigation 2 items“ (es enthält eine Liste und Suchsteuerelemente).
• Für das <main>-Element: „main 2 items“ (es enthält einen Artikel und ein Aside).
• Für das <aside>-Element: „complementary 2 items“ (es enthält eine Überschrift und eine Liste).
• Für das Sucheingabefeld: „Search query, insertion at beginning of text“.
• Für das <footer>-Element: „footer 1 item“.

Wenn Sie das Landmarks-Menü von VoiceOver öffnen (mit der VoiceOver-Taste + U und anschließend den Pfeiltasten, um durch die Menüoptionen zu navigieren), sehen Sie, dass die meisten Elemente übersichtlich aufgeführt sind und schnell angesteuert werden können.

Hier können wir allerdings noch etwas verbessern. Der Suchbereich ist eine wichtige Landmark, die Nutzer finden möchten. Er erscheint jedoch nicht im Landmarks-Menü und wird nicht als eigenständiger Orientierungspunkt behandelt. Lediglich das Eingabefeld selbst wird als Sucheingabe angekündigt (<input type="search">).

Um den Suchbereich als Landmark zu kennzeichnen, können Sie ihn entweder mit dem Element <search> umschließen oder ihm die ARIA-Rolle role="search" geben. Verwenden Sie grundsätzlich nach Möglichkeit HTML-Semantik und greifen Sie nur dann auf ARIA zurück, wenn es kein entsprechendes HTML-Element gibt.

<header>
  <h1>Header</h1>

  <!-- Even is it's not mandatory, it's common practice to put the main navigation menu within the main header -->

  <nav>
    <ul>
      <li><a href="#">Home</a></li>
      <li><a href="#">Our team</a></li>
      <li><a href="#">Projects</a></li>
      <li><a href="#">Contact</a></li>
    </ul>

    <!-- A search box is another common non-linear way to navigate through a website. -->

    <search>
      <input
        type="search"
        name="q"
        placeholder="Search query"
        aria-label="Search through site content" />
      <input type="button" value="Go!" />
    </search>
  </nav>
</header>

<!-- Here is our page's main content -->
<main>
  <!-- It contains an article -->
  <article>
    <h2>Article heading</h2>

    <p>
      Lorem ipsum dolor sit amet, consectetur adipisicing elit. Donec a diam
      lectus. Set sit amet ipsum mauris. Maecenas congue ligula as quam viverra
      nec consectetur ant hendrerit. Donec et mollis dolor. Praesent et diam
      eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue
      enim, ut porta lorem lacinia consectetur.
    </p>

    <h3>subsection</h3>

    <p>
      Donec ut librero sed accu vehicula ultricies a non tortor. Lorem ipsum
      dolor sit amet, consectetur adipisicing elit. Aenean ut gravida lorem. Ut
      turpis felis, pulvinar a semper sed, adipiscing id dolor.
    </p>

    <p>
      Pelientesque auctor nisi id magna consequat sagittis. Curabitur dapibus,
      enim sit amet elit pharetra tincidunt feugiat nist imperdiet. Ut convallis
      libero in urna ultrices accumsan. Donec sed odio eros.
    </p>
  </article>

  <!-- the aside content can also be nested within the main content -->
  <aside>
    <h2>Related</h2>
    <ul>
      <li><a href="#">Oh I do like to be beside the seaside</a></li>
      <li><a href="#">Oh I do like to be beside the sea</a></li>
      <li><a href="#">Although in the North of England</a></li>
      <li><a href="#">It never stops raining</a></li>
      <li><a href="#">Oh well...</a></li>
    </ul>
  </aside>
</main>

<!-- And here is our main footer that is used across all the pages of our website -->

<footer>
  <p>©Copyright 2050 by nobody. All rights reversed.</p>
</footer>

/* || General setup */

html,
body {
  margin: 0;
  padding: 0;
}

html {
  font-size: 10px;
  background-color: darkgrey;
}

body {
  width: max(70vw, 90%);
  margin: 0 auto;
  padding: 0 10px;
  display: flex;
  flex-direction: column;
}

/* || typography */

h1,
h2,
h3 {
  font-family: "Sonsie One", cursive;
  color: #2a2a2a;
}

p,
input,
li {
  font-family: "Open Sans Condensed", sans-serif;
  color: #2a2a2a;
}

h1 {
  font-size: 4rem;
  text-align: center;
  color: white;
  text-shadow: 2px 2px 10px black;
}

h2 {
  font-size: 3rem;
  text-align: center;
}

h3 {
  font-size: 2.2rem;
}

p,
li {
  font-size: 1.6rem;
  line-height: 1.5;
}

/* || header layout */

header {
  margin-bottom: 10px;
}

nav,
article,
aside,
footer {
  background-color: white;
  padding: 1%;
}

nav {
  background-color: #ff80ff;
  display: flex;
  gap: 2vw;
  @media (width <= 650px) {
    flex-direction: column;
  }
}

nav ul {
  padding: 0;
  list-style-type: none;
  flex: 2;
  display: flex;
  gap: 2vw;
}

nav li {
  display: inline;
  text-align: center;
}

nav a {
  display: inline-block;
  font-size: 2rem;
  text-transform: uppercase;
  text-decoration: none;
  color: black;
}

nav .search-controls,
nav search {
  flex: 1;
  display: flex;
  align-items: center;
  height: 100%;
}

input {
  font-size: 1.6rem;
  height: 32px;
}

input[type="search"] {
  flex: 3;
}

input[type="button"] {
  flex: 1;
  margin-left: 1rem;
  background: #333333;
  border: 0;
  color: white;
}

/* || main layout */

main {
  display: flex;
  gap: 2vw;
  @media (width <= 650px) {
    flex-direction: column;
  }
}

article {
  flex: 4;
}

aside {
  flex: 1;
  background-color: #ff80ff;
}

aside li {
  padding-bottom: 10px;
}

footer {
  margin-top: 10px;
}

Entscheidend ist, dass wir semantisches HTML verwendet haben. Es verleiht der Seitenstruktur Bedeutung und Rollen, ohne unserer HTML-Struktur unnötige role-Attribute hinzuzufügen. Die Struktur sieht etwa so aus:

<header>
  <h1>…</h1>
  <nav>
    <ul>
      …
    </ul>
    <search>
      <!-- search controls -->
    </search>
  </nav>
</header>

<main>
  <article>…</article>
  <aside>…</aside>
</main>

<footer>…</footer>

Dieses Beispiel enthält noch eine zusätzliche Funktion: Das <input>-Element hat das Attribut aria-label erhalten. Es stellt eine beschreibende Beschriftung bereit, die ein Screenreader vorliest, obwohl wir kein <label>-Element eingefügt haben. In solchen Fällen ist das sehr nützlich: Ein Suchformular wie dieses ist weitverbreitet und leicht zu erkennen; eine sichtbare Beschriftung würde das Seitendesign beeinträchtigen.

<input
  type="search"
  name="q"
  placeholder="Search query"
  aria-label="Search through site content" />

Wenn wir dieses Beispiel nun mit VoiceOver untersuchen, zeigen sich einige Verbesserungen:

• Der Suchbereich wird sowohl beim Navigieren durch die Seite als auch im Landmarks-Menü als eigener Eintrag angekündigt.
• Der Text im Attribut aria-label wird vorgelesen, wenn das Formulareingabefeld den Fokus erhält.

Wenn Sie ältere Browser wie IE8 unterstützen müssen, lohnt es sich, dafür ARIA-Rollen anzugeben. Und falls Ihre Website aus irgendeinem Grund ausschließlich mit <div>-Elementen aufgebaut ist, sollten Sie unbedingt ARIA-Rollen ergänzen, um die dringend benötigte Semantik bereitzustellen!

Im Folgenden erfahren Sie mehr über diese Semantik und die Möglichkeiten von ARIA-Eigenschaften und -Attributen, insbesondere im Abschnitt Barrierefreiheit nicht semantischer Steuerelemente. Sehen wir uns zunächst an, wie ARIA bei dynamischen Inhaltsaktualisierungen hilft.

Dynamische Inhaltsaktualisierungen

Auf Inhalte, die in das DOM geladen wurden, können Screenreader leicht zugreifen – von Text bis hin zu Alternativtext für Bilder. Traditionelle statische Websites, die überwiegend aus Text bestehen, lassen sich daher für Menschen mit Sehbeeinträchtigungen vergleichsweise leicht zugänglich gestalten.

Moderne Web-Apps bestehen jedoch häufig nicht nur aus statischem Text. Sie aktualisieren Teile der Seite, indem sie neue Inhalte vom Server abrufen (in diesem Beispiel verwenden wir ein statisches Array mit Zitaten) und das DOM ändern. Solche Bereiche werden manchmal als Live-Regionen bezeichnet.

Sehen wir uns ein Beispiel an: einen Generator für zufällige Zitate.

<section>
  <h1>Random quote generator</h1>
  <button>Start giving me quotes</button>
  <blockquote>
    <p></p>
  </blockquote>
</section>

* {
  box-sizing: border-box;
}

html {
  font-family: sans-serif;
}

html,
body {
  height: 100%;
}

h1 {
  letter-spacing: 2px;
}

p {
  line-height: 1.6;
}

section {
  height: 100%;
  padding: 10px;
  background: #666666;
  text-shadow: 1px 1px 1px black;
  color: white;
}

let quotes = [
  {
    quote:
      "Every child is an artist. The problem is how to remain an artist once he grows up.",
    author: "Pablo Picasso",
  },
  {
    quote:
      "You can never cross the ocean until you have the courage to lose sight of the shore.",
    author: "Christopher Columbus",
  },
  {
    quote:
      "I love deadlines. I love the whooshing noise they make as they go by.",
    author: "Douglas Adams",
  },
];

const quotePara = document.querySelector("section p");
const btn = document.querySelector("button");

btn.addEventListener("click", () => {
  function showQuote() {
    let random = Math.floor(Math.random() * quotes.length);
    quotePara.textContent = `${quotes[random].quote} -- ${quotes[random].author}`;
  }

  showQuote();
  btn.disabled = true;
  window.setInterval(showQuote, 5000);
});

Das funktioniert zwar, ist aber nicht gut für die Barrierefreiheit: Screenreader erkennen die Inhaltsänderung nicht, sodass ihre Nutzer nicht erfahren, was geschieht. Dieses Beispiel ist recht einfach. Stellen Sie sich jedoch eine komplexe Benutzeroberfläche mit vielen sich ständig aktualisierenden Inhalten vor – etwa einen Chatraum, die Oberfläche eines Strategiespiels oder eine laufend aktualisierte Warenkorbanzeige. Ohne eine Möglichkeit, Nutzer auf Änderungen aufmerksam zu machen, wäre die App kaum sinnvoll nutzbar.

Zum Glück bietet WAI-ARIA dafür einen Mechanismus: die Eigenschaft aria-live. Wird sie auf ein Element angewendet, lesen Screenreader aktualisierte Inhalte vor. Wie dringend die Aktualisierung angekündigt wird, hängt vom Attributwert ab:

off

Der Standardwert. Aktualisierungen sollen nicht angekündigt werden.

polite

Aktualisierungen sollen nur angekündigt werden, wenn der Nutzer gerade nicht aktiv ist.

assertive

Aktualisierungen sollen dem Nutzer so schnell wie möglich angekündigt werden.

Hier ändern wir das öffnende <blockquote>-Tag wie folgt:

<blockquote aria-live="assertive">…</blockquote>

Dadurch liest ein Screenreader den Inhalt vor, wenn er aktualisiert wird. Testen Sie die aktualisierte Live-Version:

<section>
  <h1>Random quote generator</h1>
  <button>Start giving me quotes</button>
  <blockquote aria-live="assertive">
    <p></p>
  </blockquote>
</section>

Verbesserung der Tastaturzugänglichkeit

Wie bereits an anderen Stellen dieses Moduls besprochen, ist eine der Stärken von HTML im Hinblick auf die Barrierefreiheit die integrierte Tastaturzugänglichkeit von Buttons, Formularsteuerelementen und Links. In der Regel können Sie mit der Tabulatortaste zwischen Steuerelementen wechseln und sie mit der Eingabetaste auswählen oder aktivieren. Gelegentlich werden weitere Tasten benötigt, beispielsweise die Pfeiltasten nach oben und unten, um zwischen Optionen in einem <select>-Feld zu wechseln.

Manchmal müssen Sie jedoch Code schreiben, der nicht semantische Elemente als Buttons oder andere Steuerelemente verwendet. In anderen Fällen werden fokussierbare Steuerelemente für einen Zweck eingesetzt, für den sie nicht ganz geeignet sind. Vielleicht müssen Sie übernommenen Code korrigieren oder ein komplexes Widget erstellen, das dies erfordert.

Um normalerweise nicht fokussierbare Elemente fokussierbar zu machen, erweitert WAI-ARIA die Nutzung des Attributs tabindex um folgende Werte:

• tabindex="0" — wie oben erwähnt, können damit Elemente per Tabulatortaste angesteuert werden, bei denen das normalerweise nicht möglich ist. Dies ist der nützlichste Wert von tabindex.
• tabindex="-1" — damit können normalerweise nicht per Tabulatortaste ansteuerbare Elemente programmatisch den Fokus erhalten, beispielsweise über JavaScript oder als Ziel eines Links.

In unserem Artikel zur Barrierefreiheit von HTML haben wir dies ausführlicher besprochen und eine typische Umsetzung gezeigt: Tastaturzugänglichkeit wiederherstellen.

Barrierefreiheit nicht semantischer Steuerelemente

Dieser Abschnitt knüpft an den vorherigen an: Wenn verschachtelte <div>-Elemente zusammen mit CSS und JavaScript eine komplexe UI-Funktion bilden oder ein natives Steuerelement durch JavaScript stark erweitert oder verändert wird, kann nicht nur die Tastaturzugänglichkeit leiden. Auch Screenreader-Nutzern fällt es ohne Semantik oder andere Hinweise schwer zu erkennen, was die Funktion bewirkt. In solchen Situationen kann ARIA die fehlende Semantik bereitstellen.

Formularvalidierung und Fehlermeldungen

Kehren wir zunächst zu dem Formularbeispiel aus unserem Artikel zur Barrierefreiheit von CSS und JavaScript zurück (eine ausführliche Wiederholung finden Sie unter Unaufdringlich bleiben). Am Ende dieses Abschnitts haben wir einige ARIA-Attribute zum Bereich für Fehlermeldungen hinzugefügt, der beim Absenden des Formulars Validierungsfehler anzeigt:

<div class="errors" role="alert" aria-relevant="all">
  <ul></ul>
</div>

• role="alert" macht das Element automatisch zu einer Live-Region, sodass Änderungen vorgelesen werden. Zugleich kennzeichnet die Rolle das Element semantisch als Warnmeldung mit wichtigen zeit- oder kontextabhängigen Informationen. So lassen sich Warnungen zugänglicher vermitteln als mit modalen Dialogen wie Aufrufen von alert(), die verschiedene Probleme bei der Barrierefreiheit verursachen. Siehe dazu Popup Windows von WebAIM.
• Der Wert all für aria-relevant weist den Screenreader an, den Inhalt der Fehlerliste vorzulesen, sobald sich etwas daran ändert – also wenn Fehler hinzugefügt oder entfernt werden. Das ist hilfreich, weil der Nutzer wissen möchte, welche Fehler noch vorhanden sind, und nicht nur, was zur Liste hinzugefügt oder daraus entfernt wurde.

Wir könnten ARIA noch weiter einsetzen und zusätzliche Hilfen für die Validierung anbieten. Wie wäre es, Pflichtfelder zu kennzeichnen und den zulässigen Altersbereich anzugeben?

1. Erstellen Sie zunächst lokale Kopien der Dateien form-validation.html und validation.js.

2. Öffnen Sie beide Dateien in einem Texteditor und sehen Sie sich an, wie der Code funktioniert.

3. Fügen Sie direkt vor dem öffnenden <form>-Tag einen Absatz wie den folgenden ein und kennzeichnen Sie beide <label>-Elemente des Formulars mit einem Sternchen. So werden Pflichtfelder üblicherweise für sehende Nutzer markiert.

   html

   <p>Fields marked with an asterisk (*) are required.</p>
   

4. Visuell ist das verständlich, für Screenreader-Nutzer jedoch nicht so leicht zu erkennen. Zum Glück bietet WAI-ARIA das Attribut aria-required. Damit erhalten Screenreader den Hinweis, Nutzern mitzuteilen, dass Formulareingaben ausgefüllt werden müssen. Aktualisieren Sie die <input>-Elemente wie folgt:

   html

   <input type="text" name="name" id="name" aria-required="true" />
   
   <input type="number" name="age" id="age" aria-required="true" />
   

5. Wenn Sie das Beispiel jetzt speichern und mit einem Screenreader testen, sollten Sie etwas hören wie „Enter your name star, required, edit text“.

6. Es wäre außerdem hilfreich, Screenreader-Nutzern und sehenden Nutzern einen Hinweis auf den erwarteten Alterswert zu geben. Solche Hinweise erscheinen häufig als Tooltip oder Platzhalter im Formularfeld. WAI-ARIA bietet die Eigenschaften aria-valuemin und aria-valuemax, um Mindest- und Höchstwerte anzugeben. Screenreader unterstützen außerdem die nativen Attribute min und max. Eine weitere gut unterstützte Funktion ist das HTML-Attribut placeholder. Es kann eine Nachricht enthalten, die im Eingabefeld erscheint, solange kein Wert eingegeben wurde, und von einigen Screenreadern vorgelesen wird. Aktualisieren Sie Ihr Zahlenfeld wie folgt:

   html

   <label for="age">Your age:</label>
   <input
     type="number"
     name="age"
     id="age"
     placeholder="Enter 1 to 150"
     required
     aria-required="true" />
   

Fügen Sie für jede Eingabe immer ein <label> hinzu. Einige Screenreader kündigen Platzhaltertext zwar an, die meisten jedoch nicht. Als Alternativen für einen zugänglichen Namen eines Formularsteuerelements eignen sich aria-label und aria-labelledby. Bevorzugt werden sollte jedoch ein <label>-Element mit einem for-Attribut, da es die Bedienbarkeit für alle Nutzer verbessert – auch für diejenigen, die eine Maus verwenden.

WAI-ARIA ermöglicht außerdem fortgeschrittene Techniken zur Beschriftung von Formularen, die über das klassische <label>-Element hinausgehen. Wir haben bereits besprochen, wie sich mit der Eigenschaft aria-label eine Beschriftung bereitstellen lässt, die für sehende Nutzer nicht sichtbar sein soll (siehe oben den Abschnitt Orientierungspunkte/Landmarks). Andere Techniken verwenden Eigenschaften wie aria-labelledby, wenn ein anderes Element als <label> als Beschriftung dienen oder dieselbe Beschriftung für mehrere Formulareingaben verwendet werden soll. Mit aria-describedby lassen sich zusätzliche Informationen mit einer Formulareingabe verknüpfen und vorlesen. Weitere Einzelheiten finden Sie im WebAIM-Artikel Advanced Form Labeling.

Es gibt noch viele weitere nützliche Eigenschaften und Zustände, um den Status von Formularelementen anzugeben. Beispielsweise kann aria-disabled="true" kennzeichnen, dass ein Formularfeld deaktiviert ist. Viele Browser überspringen deaktivierte Formularfelder, sodass Screenreader sie nicht vorlesen. In manchen Fällen wird ein deaktiviertes Element dennoch wahrgenommen. Deshalb ist es sinnvoll, dieses Attribut anzugeben, damit der Screenreader dessen deaktivierten Zustand erkennt.

Wenn sich der deaktivierte Zustand einer Eingabe voraussichtlich ändert, sollten Sie auch mitteilen, wann dies geschieht und was die Änderung bewirkt. In unserer Demo form-validation-checkbox-disabled.html gibt es beispielsweise eine Checkbox, die beim Aktivieren eine weitere Formulareingabe für zusätzliche Informationen freischaltet. Außerdem haben wir eine Live-Region eingerichtet, die durch absolute Positionierung visuell verborgen ist:

<p class="hidden-alert" aria-live="assertive"></p>

Wenn die Checkbox aktiviert oder deaktiviert wird, aktualisieren wir den Text in der verborgenen Live-Region. So erfahren Screenreader-Nutzer, welche Auswirkung die Aktion hat. Gleichzeitig aktualisieren wir den Zustand aria-disabled und einige visuelle Hinweise:

function toggleMusician(bool) {
  const instrument = formItems[formItems.length - 1];
  if (bool) {
    instrument.input.disabled = false;
    instrument.label.style.color = "black";
    instrument.input.setAttribute("aria-disabled", "false");
    hiddenAlert.textContent =
      "Instruments played field now enabled; use it to tell us what you play.";
  } else {
    instrument.input.disabled = true;
    instrument.label.style.color = "#999999";
    instrument.input.setAttribute("aria-disabled", "true");
    instrument.input.removeAttribute("aria-label");
    hiddenAlert.textContent = "Instruments played field now disabled.";
  }
}

Nicht semantische Buttons als Buttons kennzeichnen

In diesem Kurs haben wir bereits mehrfach die native Barrierefreiheit von Buttons, Links und Formularelementen sowie die Probleme angesprochen, die entstehen, wenn andere Elemente diese nachahmen. Siehe Nach Möglichkeit semantische UI-Steuerelemente verwenden im Artikel zur Barrierefreiheit von HTML und oben Verbesserung der Tastaturzugänglichkeit. In vielen Fällen lässt sich die Tastaturzugänglichkeit mit tabindex und etwas JavaScript ohne allzu großen Aufwand wiederherstellen.

Aber was ist mit Screenreadern? Sie erkennen die Elemente weiterhin nicht als Buttons. Wenn wir unser Beispiel fake-div-buttons.html mit einem Screenreader testen, werden die nachgebildeten Buttons etwa als „Click me!, group“ angekündigt. Das ist verständlicherweise verwirrend.

Mit einer WAI-ARIA-Rolle können wir das beheben. Erstellen Sie eine lokale Kopie von fake-div-buttons.html und fügen Sie jedem als Button verwendeten <div> die Rolle role="button" hinzu, zum Beispiel:

<div data-message="This is from the first button" tabindex="0" role="button">
  Click me!
</div>

Wenn Sie das Beispiel nun mit einem Screenreader testen, werden die Buttons etwa als „Click me!, button“ angekündigt. Das ist deutlich besser. Sie müssen allerdings weiterhin alle nativen Button-Funktionen ergänzen, die Nutzer erwarten – etwa die Verarbeitung der Eingabetaste und von Klickereignissen. Dies wird in der Dokumentation zur Rolle button erläutert.

Nutzer durch komplexe Widgets führen

Es gibt zahlreiche weitere Rollen, die nicht semantische Elementstrukturen als gängige UI-Funktionen kennzeichnen können, für die Standard-HTML keine Entsprechung bietet. Beispiele sind combobox, slider, tabpanel und tree. Die Codebibliothek der Deque University enthält mehrere hilfreiche Beispiele dafür, wie sich solche Steuerelemente barrierefrei gestalten lassen.

Weitere interaktive Beispiele finden Sie in unserer Dokumentation zu WAI-ARIA-Rollen. Sehen Sie sich beispielsweise unser Beispiel zur ARIA-Rolle tab an. Es erklärt, wie Sie eine barrierefreie Oberfläche mit Tabs umsetzen.

Zusammenfassung

Dieser Artikel behandelt längst nicht alle Möglichkeiten von WAI-ARIA. Er sollte Ihnen jedoch genügend Informationen vermittelt haben, um WAI-ARIA einzusetzen und einige der häufigsten Muster zu erkennen, bei denen es benötigt wird.

Im nächsten Artikel finden Sie Tests, mit denen Sie überprüfen können, wie gut Sie diese Informationen verstanden und behalten haben.

Siehe auch

• ARIA-Zustände und -Eigenschaften: Alle aria-*-Attribute
• WAI-ARIA-Rollen: Kategorien von ARIA-Rollen und die auf MDN beschriebenen Rollen
• ARIA in HTML des W3C: Eine Spezifikation, die für jede HTML-Funktion die vom Browser implizit zugewiesene Barrierefreiheitssemantik (ARIA) und die bei Bedarf zusätzlich verwendbaren WAI-ARIA-Funktionen definiert
• Codebibliothek der Deque University: Eine Sammlung nützlicher und praxisnaher Beispiele, die zeigen, wie komplexe UI-Steuerelemente mithilfe von WAI-ARIA-Funktionen zugänglich gemacht werden
• WAI-ARIA Authoring Practices des W3C: Ausführliche Entwurfsmuster des W3C, die erklären, wie sich verschiedene Arten komplexer UI-Steuerelemente mithilfe von WAI-ARIA-Funktionen barrierefrei umsetzen lassen

• Zurück
• Übersicht: Barrierefreiheit im Web
• Weiter