HTML: Eine gute Grundlage für Barrierefreiheit

Wenn Sie mehr über HTML lernen — mehr Ressourcen lesen, mehr Beispiele ansehen, usw. — werden Sie ein gemeinsames Thema immer wieder sehen: die Bedeutung der Verwendung von semantischem HTML (manchmal als POSH bezeichnet, oder Plain Old Semantic HTML). Das bedeutet, die korrekten HTML-Elemente so oft wie möglich für ihren vorgesehenen Zweck zu verwenden.

Sie fragen sich vielleicht, warum das so wichtig ist. Schließlich können Sie eine Kombination aus CSS und JavaScript verwenden, um fast jedes HTML-Element so verhalten zu lassen, wie Sie es möchten. Zum Beispiel könnte eine Steuerungstaste, um ein Video auf Ihrer Website abzuspielen, so formatiert werden:

<div>Play video</div>

Aber wie Sie später noch genauer sehen werden, macht es Sinn, das richtige Element für die Aufgabe zu verwenden:

<button>Play video</button>

HTML-<button>s haben nicht nur einige passende Voreinstellungen (die Sie wahrscheinlich überschreiben möchten), sie bieten auch eingebaute Tastaturzugänglichkeit — Benutzer können mit der Tab-Taste zwischen den Tasten navigieren und ihre Auswahl mit Space, Return oder Enter aktivieren.

Semantisches HTML erfordert nicht mehr Zeit zum Schreiben als nicht-semantische (schlechte) Markup, wenn Sie von Anfang an konsequent vorgehen. Noch besser ist, dass semantisches Markup über Barrierefreiheit hinaus weitere Vorteile bietet:

1. Einfacher zu entwickeln — wie oben erwähnt, erhalten Sie einige Funktionen kostenlos, und es ist wohl einfacher zu verstehen.
2. Besser auf mobilen Geräten — semantisches HTML ist tendenziell leichter in der Dateigröße als nicht-semantischer Spaghetti-Code und einfacher responsive zu machen.
3. Gut für SEO — Suchmaschinen geben Keywords innerhalb von Überschriften, Links usw. mehr Bedeutung als Keywords, die in nicht-semantischen <div>s usw. enthalten sind, so dass Ihre Dokumente für Kunden auffindbarer werden.

Lassen Sie uns nun im Detail auf barrierefreies HTML eingehen.

Wir haben bereits über die Bedeutung korrekter Semantik gesprochen und warum wir das richtige HTML-Element für die Aufgabe verwenden sollten. Dies kann nicht ignoriert werden, da es einer der Hauptbereiche ist, in denen Barrierefreiheit ernsthaft beeinträchtigt wird, wenn sie nicht ordnungsgemäß behandelt wird.

Im Web machen die Menschen seltsame Dinge mit HTML-Markup. Oft ist der Missbrauch von HTML auf veraltete Praktiken zurückzuführen, die noch nicht verschwunden sind, aber manchmal passiert es auch, weil Autoren nichts Besseres wissen. In jedem Fall sollten Sie schlechtes Code durch gutes semantisches Markup ersetzen, wo immer möglich, sowohl in statischen HTML-Seiten als auch dynamisch generiertem HTML aus serverseitigem Code oder clientseitigen JavaScript-Frameworks wie React.

Manchmal sind Sie nicht in der Lage, schlechtes Markup loszuwerden — Ihre Seiten könnten von serverseitigem Code oder Web-/Framework-Komponenten abhängen, die außerhalb Ihrer Kontrolle liegen, oder Sie könnten Drittinhalte auf Ihrer Seite haben (wie Werbebanner).

Das Ziel ist nicht "alles oder nichts"; jede Verbesserung, die Sie vornehmen können, wird dem Zweck der Barrierefreiheit helfen.

Eine der besten Hilfen für Nutzer von Screenreader ist eine ausgezeichnete Textstruktur mit Überschriften, Absätzen, Listen usw. Ein gutes semantisches Beispiel könnte folgendermaßen aussehen:

<h1>My heading</h1>

<p>This is the first section of my document.</p>

<p>I'll add another paragraph here too.</p>

<ol>
  <li>Here is</li>
  <li>a list for</li>
  <li>you to read</li>
</ol>

<h2>My subheading</h2>

<p>
  This is the first subsection of my document. I'd love people to be able to
  find this content!
</p>

<h2>My 2nd subheading</h2>

<p>
  This is the second subsection of my content, which I think is more interesting
  than the last one.
</p>

Wir haben eine längere Textversion für Sie vorbereitet, die Sie mit einem Screenreader ausprobieren können (siehe good-semantics.html). Wenn Sie sich durch diese Version navigieren, werden Sie feststellen, dass sie ziemlich einfach zu bedienen ist:

1. Der Screenreader liest jede Überschrift aus, während Sie den Inhalt durchgehen, und informiert Sie darüber, was eine Überschrift, was ein Absatz usw. ist.
2. Er stoppt nach jedem Element, sodass Sie in Ihrem eigenen Tempo vorgehen können.
3. In vielen Screenreadern können Sie zur nächsten/vorherigen Überschrift springen.
4. Viele Screenreader bieten eine Liste aller Überschriften an, die Sie wie ein Inhaltsverzeichnis verwenden können, um spezifische Inhalte zu finden.

Menschen schreiben manchmal Überschriften, Absätze usw., indem sie Zeilenumbrüche verwenden und rein zu Stilzwecken HTML-Elemente hinzufügen, wie im folgenden Beispiel:

<span style="font-size: 3em">My heading</span> <br /><br />
This is the first section of my document.
<br /><br />
I'll add another paragraph here too.
<br /><br />
1. Here is
<br /><br />
2. a list for
<br /><br />
3. you to read
<br /><br />
<span style="font-size: 2.5em">My subheading</span>
<br /><br />
This is the first subsection of my document. I'd love people to be able to find
this content!
<br /><br />
<span style="font-size: 2.5em">My 2nd subheading</span>
<br /><br />
This is the second subsection of my content. I think is more interesting than
the last one.

Wenn Sie mit einem Screenreader unsere längere Version ausprobieren (siehe bad-semantics.html), werden Sie keine sehr gute Erfahrung machen — der Screenreader hat keine strukturellen Hinweise, sodass Sie kein nützliches Inhaltsverzeichnis abrufen können und die ganze Seite als ein einziger großer Block wahrgenommen wird, der in einem Zug durchgelesen wird.

Es gibt auch andere Probleme jenseits der Barrierefreiheit — es ist schwieriger, den Inhalt mit CSS zu gestalten oder mit JavaScript zu manipulieren, zum Beispiel, weil es keine Elemente gibt, die als Selektoren verwendet werden können.

Die Sprache, die Sie verwenden, kann ebenfalls die Barrierefreiheit beeinflussen. Generell sollten Sie eine klare Sprache verwenden, die nicht übermäßig komplex ist und keine unnötigen Fachbegriffe oder Slangwörter verwendet. Dies kommt nicht nur Menschen mit kognitiven oder anderen Behinderungen zugute; es hilft auch Lesern, für die der Text nicht in ihrer Muttersprache geschrieben ist, jüngeren Menschen... im Grunde jedem! Abgesehen davon sollten Sie versuchen, Sprache und Zeichen zu vermeiden, die vom Screenreader nicht klar vorgelesen werden. Zum Beispiel:

• Vermeiden Sie, wenn möglich, Bindestriche zu verwenden. Statt 5–7 zu schreiben, schreiben Sie 5 bis 7.
• Abkürzungen ausschreiben — statt Jan zu schreiben, schreiben Sie Januar.
• Abkürzungen erläutern, mindestens ein- oder zweimal, und dann das <abbr> Tag verwenden, um sie zu beschreiben.

Sie sollten geeignete Abschnittselemente verwenden, um Ihre Webseiten zu strukturieren, zum Beispiel für die Navigation (<nav>), Fußzeile (<footer>) und wiederkehrende Inhaltseinheiten (<article>). Diese bieten zusätzliche Semantik für Screenreader (und andere Werkzeuge), um den Benutzern zusätzliche Hinweise über den navigierten Inhalt zu geben.

Ein modernes Inhaltsstrukturbeispiel könnte etwa so aussehen:

<header>
  <h1>Header</h1>
</header>

<nav>
  <!-- main navigation in here -->
</nav>

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

    <!-- article content in here -->
  </article>

  <aside>
    <h2>Related</h2>

    <!-- aside content in here -->
  </aside>
</main>

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

<footer>
  <!-- footer content in here -->
</footer>

Sie finden ein komplettes Beispiel hier.

Neben guter Semantik und einem ansprechenden Layout sollte Ihr Inhalt in seiner Quellreihenfolge auch logischen Sinn ergeben — Sie können ihn später immer dort platzieren, wo Sie möchten, indem Sie CSS verwenden, aber Sie sollten die Quellreihenfolge von Anfang an richtig gestalten, sodass das, was Screenreader-Nutzer vorgelesen bekommen, Sinn ergibt.

Mit UI-Steuerelementen meinen wir die Hauptbestandteile von Webdokumenten, mit denen Benutzer interagieren — am häufigsten Buttons, Links und Formularelemente. In diesem Abschnitt beschäftigen wir uns mit den grundlegenden Themen der Barrierefreiheit, die bei der Erstellung solcher Steuerelemente zu beachten sind. Spätere Artikel zu WAI-ARIA und Multimedia werden sich mit anderen Aspekten der UI-Barrierefreiheit befassen.

Ein wichtiger Aspekt der Barrierefreiheit von UI-Steuerelementen ist, dass Browser diese standardmäßig über die Tastatur bedienbar machen. Sie können dies mit unserem native-keyboard-accessibility.html Beispiel ausprobieren (siehe den Quellcode). Öffnen Sie dies in einem neuen Tab und versuchen Sie, die Tabulatortaste zu drücken; nach ein paar Drücken sollten Sie sehen, wie der Tab-Fokus durch die verschiedenen fokussierbaren Elemente wechselt. Die fokussierten Elemente erhalten einen hervorgehobenen Standardstil in jedem Browser (es unterscheidet sich leicht zwischen verschiedenen Browsern), sodass Sie erkennen können, welches Element fokussiert ist.

Sie können dann Enter/Return drücken, um einem fokussierten Link zu folgen oder eine Schaltfläche zu drücken (wir haben etwas JavaScript eingebaut, damit die Schaltflächen eine Nachricht anzeigen), oder anfangen zu tippen, um Text in einem Texteingabefeld einzugeben. Andere Formularelemente haben unterschiedliche Steuerungen; zum Beispiel kann das <select>-Element seine Optionen mit den Pfeiltasten nach oben und unten anzeigen und zwischen ihnen wechseln.

Im Grunde erhalten Sie dieses Verhalten kostenlos, indem Sie einfach die entsprechenden Elemente verwenden, zum Beispiel:

<h1>Links</h1>

<p>This is a link to <a href="https://www.mozilla.org">Mozilla</a>.</p>

<p>
  Another link, to the
  <a href="https://developer.mozilla.org">Mozilla Developer Network</a>.
</p>

<h2>Buttons</h2>

<p>
  <button data-message="This is from the first button">Click me!</button>
  <button data-message="This is from the second button">Click me too!</button>
  <button data-message="This is from the third button">And me!</button>
</p>

<h2>Form</h2>

<form>
  <div>
    <label for="name">Fill in your name:</label>
    <input type="text" id="name" name="name" />
  </div>
  <div>
    <label for="age">Enter your age:</label>
    <input type="text" id="age" name="age" />
  </div>
  <div>
    <label for="mood">Choose your mood:</label>
    <select id="mood" name="mood">
      <option>Happy</option>
      <option>Sad</option>
      <option>Angry</option>
      <option>Worried</option>
    </select>
  </div>
</form>

Das bedeutet, Links, Buttons, Formularelemente und Beschriftungen angemessen zu verwenden (einschließlich des <label>-Elements für Formularelemente).

Allerdings kommt es vor, dass Menschen manchmal seltsame Dinge mit HTML machen. Zum Beispiel sieht man manchmal Tasten, die mit <div>s formatiert sind, zum Beispiel:

<div data-message="This is from the first button">Click me!</div>
<div data-message="This is from the second button">Click me too!</div>
<div data-message="This is from the third button">And me!</div>

Aber solche Codeverwendung wird nicht empfohlen — Sie verlieren sofort die native Tastaturzugänglichkeit, die Sie gehabt hätten, wenn Sie einfach <button>-Elemente verwendet hätten, und Sie erhalten keine der Standard-CSS-Styling-Optionen, die Tasten bekommen. In seltenen bis nicht existierenden Fällen, in denen Sie ein Nicht-Tasten-Element für eine Taste verwenden müssen, verwenden Sie die button-Rolle und implementieren Sie alle Standard-Tastenverhalten einschließlich Tastatur- und Maustastensupport.

Tastaturzugänglichkeit wieder einbauen

Solche Vorteile zurückzubringen erfordert etwas Arbeit (Sie können ein Beispiel in unserem fake-div-buttons.html Beispiel sehen — siehe auch den Quellcode). Hier haben wir unseren gefälschten <div>-Tasten die Möglichkeit gegeben, fokussiert zu werden (einschließlich über Tab), indem wir jedes mit dem Attribut tabindex="0" versehen. Wir schließen auch role="button" ein, damit Screenreader-Benutzer wissen, dass sie das Element fokussieren und interagieren können:

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

Grundsätzlich ist das tabindex-Attribut hauptsächlich dazu gedacht, tabbbaren Elementen eine benutzerdefinierte Tab-Reihenfolge (in positiver numerischer Reihenfolge) zu geben, anstatt sie in ihrer Standard-Quellreihenfolge zu tabben. Dies ist fast immer eine schlechte Idee, da es zu großen Verwirrung führen kann. Verwenden Sie es nur, wenn Sie es wirklich brauchen, zum Beispiel, wenn das Layout die Dinge in einer sehr anderen visuellen Reihenfolge als im Quellcode zeigt und Sie die Dinge logischer gestalten möchten. Es gibt zwei weitere Optionen für tabindex:

• tabindex="0" — wie oben erwähnt, erlaubt dieser Wert, dass Elemente, die normalerweise nicht tabbbar sind, tabbbar werden. Das ist der nützlichste Wert von tabindex.
• tabindex="-1" — dies ermöglicht normalerweise nicht tabbenden Elementen, programmatisch fokussiert zu werden, z. B. über JavaScript oder als Ziel von Links.

Obiger Zusatz ermöglicht es uns zwar, zu den Tasten zu tabben, erlaubt es uns jedoch nicht, sie über die Enter/Return-Taste zu aktivieren. Dazu mussten wir das folgende JavaScript-Stück hinzufügen:

document.onkeydown = (e) => {
  // The Enter/Return key
  if (e.key === "Enter") {
    document.activeElement.click();
  }
};

Hier fügen wir einen Listener zum document-Objekt hinzu, um zu erkennen, wenn eine Taste auf der Tastatur gedrückt wurde. Wir überprüfen, welche Taste gedrückt wurde, über die Eigenschaft key des Event-Objekts; wenn die gedrückte Taste Enter/Return ist, rufen wir die Funktion auf, die im onclick-Handler der Taste gespeichert ist, indem wir document.activeElement.click() verwenden. [activeElement](/de/docs/Web(API/Document/activeElement) gibt uns das Element, das derzeit auf der Seite fokussiert ist.

Das ist eine Menge extra Arbeit, um die Funktionalität wiederherzustellen. Und es wird sicherlich andere Probleme damit geben. Besser, gleich das richtige Element für die richtige Aufgabe zu verwenden.

Verwenden Sie bedeutungsvolle Textbeschriftungen

UI-Steuerelement-Textbeschriftungen sind für alle Benutzer sehr nützlich, aber sie richtig hinzubekommen, ist besonders wichtig für Benutzer mit Behinderungen.

Sie sollten darauf achten, dass Ihre Schaltflächen- und Linktextbeschriftungen verständlich und deutlich sind. Verwenden Sie nicht einfach "Hier klicken" für Ihre Beschriftungen, da Screenreader-Benutzer manchmal eine Liste von Schaltflächen und Formularelementen aufrufen. Der folgende Screenshot zeigt unsere Steuerelemente, die von VoiceOver auf dem Mac aufgelistet werden.

Stellen Sie sicher, dass Ihre Beschriftungen sowohl aus dem Kontext heraus als auch als Teil des umgebenden Textes Sinn ergeben. Zum Beispiel zeigt das folgende Beispiel, wie guter Linktext aussieht:

<p>
  Whales are really awesome creatures.
  <a href="whales.html">Find out more about whales</a>.
</p>

doch dies ist schlechter Linktext:

<p>
  Whales are really awesome creatures. To find out more about whales,
  <a href="whales.html">click here</a>.
</p>

Formularbeschriftungen sind auch wichtig, um Ihnen einen Hinweis darauf zu geben, was Sie in jedes Formulareingabefeld eingeben müssen. Das folgende Beispiel scheint ein vernünftiges Beispiel zu sein:

Fill in your name: <input type="text" id="name" name="name" />

Das ist jedoch für behinderte Benutzer nicht sehr nützlich. Es gibt nichts im obigen Beispiel, das die Beschriftung eindeutig mit der Formulareingabe verbindet und klar macht, wie sie auszufüllen ist, wenn man sie nicht sehen kann. Wenn Sie dieses Beispiel mit einigen Screenreadern verwenden, erhalten Sie möglicherweise nur eine Beschreibung wie "Edit Text".

Das folgende ist ein viel besseres Beispiel:

<div>
  <label for="name">Fill in your name:</label>
  <input type="text" id="name" name="name" />
</div>

Mit einem solchen Code wird die Beschriftung deutlich mit der Eingabe verbunden; die Beschreibung wird sein wie "Fill in your name: Edit Text".

Als zusätzlicher Vorteil bedeutet das Verknüpfen einer Beschriftung mit einer Formulareingabe in den meisten Browsern, dass Sie auf die Beschriftung klicken können, um das Formularelement auszuwählen oder zu aktivieren. Dies vergrößert die Trefferfläche des Eingabefelds und erleichtert die Auswahl.

In folgendem Video finden Sie eine schöne Erklärung über die Bedeutung von richtigen Textbeschriftungen und wie Sie Probleme mit Textbeschriftungen mit dem Firefox Accessibility Inspector untersuchen können:

Eine einfache Datentabelle kann mit sehr einfachem Markup geschrieben werden, zum Beispiel:

<table>
  <tr>
    <td>Name</td>
    <td>Age</td>
    <td>Pronouns</td>
  </tr>
  <tr>
    <td>Gabriel</td>
    <td>13</td>
    <td>he/him</td>
  </tr>
  <tr>
    <td>Elva</td>
    <td>8</td>
    <td>she/her</td>
  </tr>
  <tr>
    <td>Freida</td>
    <td>5</td>
    <td>she/her</td>
  </tr>
</table>

Aber das hat Probleme — es gibt keine Möglichkeit für einen Screenreader-Benutzer, Zeilen oder Spalten als Datengruppierungen zu verbinden. Dazu müssen die Überschriftenzeilen bekannt sein und ob sie Zeilen oder Spalten überschreiben usw. Dies kann für die obige Tabelle nur visuell erfolgen (siehe bad-table.html und probieren Sie das Beispiel selbst aus).

Sehen Sie sich nun unser punk bands table example an — hier können Sie einige Barrierefreiheitsunterstützungen sehen:

• Tabellenüberschriften werden mit <th>-Elementen definiert — Sie können auch angeben, ob sie Überschriften für Zeilen oder Spalten sind, mithilfe des Attributs scope. Dies gibt Ihnen vollständige Datengruppen, die von Screenreadern als einzelne Einheiten konsumiert werden können.
• Das <caption>-Element und das summary-Attribut des <table>-Elements erfüllen ähnliche Aufgaben — sie geben einem Screenreader-Benutzer eine nützliche kurze Zusammenfassung der Tabelleninhalte. Das <caption>-Element wird allgemein bevorzugt, da es seinen Inhalt auch sehenden Benutzern zugänglich macht, die es auch nützlich finden könnten. Sie benötigen nicht unbedingt beides.

Während textueller Inhalt inhärent barrierefrei ist, kann dies nicht unbedingt für multimediale Inhalte gesagt werden — Bild- und Videoinhalte können von sehbehinderten Menschen nicht gesehen werden und Audioinhalte nicht von hörgeschädigten Menschen. Wir behandeln Video- und Audioinhalte ausführlich im Accessible multimedia, aber in diesem Artikel befassen wir uns mit der Barrierefreiheit des bescheidenen <img>-Elements.

Wir haben ein einfaches Beispiel geschrieben, accessible-image.html, das vier Kopien desselben Bildes beinhaltet:

<img src="dinosaur.png" />

<img
  src="dinosaur.png"
  alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth." />

<img
  src="dinosaur.png"
  alt="A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a human, with small arms, and a large head with lots of sharp teeth."
  title="The Mozilla red dinosaur" />

<img src="dinosaur.png" aria-labelledby="dino-label" />

<p id="dino-label">
  The Mozilla red Tyrannosaurus Rex: A two legged dinosaur standing upright like
  a human, with small arms, and a large head with lots of sharp teeth.
</p>

Das erste Bild bietet beim Betrachten durch einen Screenreader dem Benutzer nicht wirklich viel Hilfe — VoiceOver zum Beispiel liest "/dinosaur.png, Bild" vor. Es liest dem Benutzer den Dateinamen vor, um einige Informationen zu geben. In diesem Fall weiß der Benutzer zumindest, dass es sich um einen Dinosaurier irgendeiner Art handelt, aber oft werden Dateien mit maschinengenerierten Dateinamen (z. B. von einer Digitalkamera) hochgeladen, die wahrscheinlich keinen Kontext zu den Bildinhalten bieten.

Wenn ein Screenreader auf das zweite Bild stößt, liest er das vollständige alt-Attribut vor — "Ein roter Tyrannosaurus Rex: Ein zweibeiniger Dinosaurier, der aufrecht wie ein Mensch steht, mit kleinen Armen und einem großen Kopf mit vielen scharfen Zähnen".

Dies hebt die Bedeutung hervor, nicht nur bedeutungsvolle Dateinamen zu verwenden, falls so genannter Alt-Text nicht verfügbar ist, sondern auch sicherzustellen, dass Alt-Text in alt-Attributen, wo immer möglich, bereitgestellt wird.

Beachten Sie, dass der Inhalt des alt-Attributs immer eine direkte Darstellung des Bildes und seiner visuellen Aussage bieten sollte. Das alt sollte kurz und prägnant sein und alle Informationen enthalten, die im Bild vermittelt werden, aber nicht im umgebenden Text dupliziert sind.

Der Inhalt des alt-Attributs für ein einzelnes Bild variiert je nach Kontext. Zum Beispiel, wenn das Foto von Fluffy ein Avatar neben einer Bewertung für Yuckymeat-Hundefutter ist, ist alt="Fluffy" angemessen. Wenn das Foto Teil von Fluffys Adoptionsseite für die Tierrettungsgesellschaft ist, sollten Informationen, die im Bild vermittelt werden und für einen potenziellen Hundebesitzer relevant sind, aber nicht im umgebenden Text bereits stehen, enthalten sein. Eine längere Beschreibung wie alt="Fluffy, ein dreifarbiger Terrier mit sehr kurzem Haar, mit einem Tennisball im Mund." ist angemessen. Da der umgebende Text wahrscheinlich Fluffys Größe und Rasse enthält, wird dies nicht im alt aufgenommen. Da die Biographie des Hundes wahrscheinlich keine Haarlänge, Farben oder Spielzeugvorlieben enthält, die für potenzielle Besitzer wichtig sind, wird dies aufgenommen. Ist das Bild im Freien, oder trägt Fluffy ein rotes Halsband mit einer blauen Leine? Nicht wichtig im Hinblick auf die Adoption des Haustiers und daher nicht aufgenommen. Alle Informationen, die ein sehender Benutzer aus dem Bild entnehmen kann und die im Kontext relevant sind, müssen vermittelt werden; nicht mehr. Halten Sie es kurz, präzise und nützlich.

Persönliches Wissen oder zusätzliche Beschreibungen sollten hier nicht eingefügt werden, da sie für Personen, die das Bild zuvor nicht gesehen haben, nicht nützlich sind. Wenn der Ball Fluffys Lieblingst Spielzeug ist oder ein sehender Benutzer das nicht aus dem Bild erkennen kann, dann nicht aufnehmen.

Bedenken Sie, ob Ihre Bilder in Ihrem Inhalt eine Bedeutung haben oder ob sie rein zur visuellen Dekoration verwendet werden und somit keine Bedeutung haben. Wenn sie dekorativ sind, ist es besser, einen leeren Text als Wert für das alt-Attribut zu schreiben (siehe Leere alt-Attribute) oder sie einfach als CSS-Hintergrundbilder in die Seite einzufügen.

Wenn Sie zusätzliche kontextuelle Informationen bereitstellen möchten, sollten Sie diese im umgebenden Text, oder in einem title-Attribut unterbringen, wie oben gezeigt. In diesem Fall lesen die meisten Screenreader den alt-Text, das title-Attribut und den Dateinamen vor. Außerdem zeigen Browser Title-Text als Tooltip an, wenn mit der Maus darauf gezeigt wird.

Lassen Sie uns schnell noch einmal die vierte Methode betrachten:

<img src="dinosaur.png" aria-labelledby="dino-label" />

<p id="dino-label">The Mozilla red Tyrannosaurus…</p>

In diesem Fall verwenden wir das alt-Attribut überhaupt nicht — stattdessen haben wir unsere Beschreibung des Bildes als regulären Textabschnitt präsentiert, ihm eine id zugewiesen und dann das aria-labelledby-Attribut verwendet, um sich auf diese id zu beziehen, was dazu führt, dass Screenreader diesen Absatz als Alt-Text/Beschriftung für dieses Bild verwenden. Dies ist besonders nützlich, wenn Sie denselben Text als Beschriftung für mehrere Bilder verwenden möchten — etwas, das mit alt nicht möglich ist.

HTML enthält zwei Elemente — <figure> und <figcaption> — die eine Abbildung irgendeiner Art (es könnte alles sein, nicht unbedingt ein Bild) mit einer Abbildungsüberschrift assoziieren:

<figure>
  <img
    src="dinosaur.png"
    alt="The Mozilla Tyrannosaurus"
    aria-describedby="dinodescr" />
  <figcaption id="dinodescr">
    A red Tyrannosaurus Rex: A two legged dinosaur standing upright like a
    human, with small arms, and a large head with lots of sharp teeth.
  </figcaption>
</figure>

Während es gemischte Unterstützung durch Screenreader gibt, Abbildungsüberschriften mit ihren Abbildungen zu assoziieren, schafft die Einbeziehung von aria-labelledby oder aria-describedby die Assoziation, wenn keine vorhanden ist. Davon abgesehen ist die Elementstruktur nützlich für das CSS-Styling und bietet eine Möglichkeit, eine Beschreibung des Bildes neben diesem in der Quelle zu platzieren.

<h3>
  <img src="article-icon.png" alt="" />
  Tyrannosaurus Rex: the king of the dinosaurs
</h3>

Es kann vorkommen, dass ein Bild im Design einer Seite enthalten ist, aber sein Hauptzweck visuelle Dekoration ist. Im obigen Codebeispiel werden Sie bemerken, dass das alt-Attribut des Bildes leer ist — dies soll Screenreader erkennen, das Bild nicht versuchen zu beschreiben (stattdessen würden sie nur "Bild" oder ähnliches sagen).

Der Grund, ein leeres alt anstelle keines zu verwenden, ist, dass viele Screenreader die gesamte Bild-URL ankündigen, wenn kein alt angegeben ist. Im obigen Beispiel dient das Bild als visuelle Dekoration für die Überschrift, mit der es verbunden ist. In solchen Fällen und bei Bildern, die nur dekorativ sind und keinen Inhaltswert bieten, sollten Sie ein leeres alt in Ihre img-Elemente aufnehmen. Eine andere Möglichkeit besteht darin, das aria role-Attribut role="presentation" zu verwenden, da dies auch Screenreader davon abhält, Alternativtext vorzulesen.

Links (das <a>-Element mit einem href-Attribut), abhängig davon, wie sie verwendet werden, können sie die Barrierefreiheit verbessern oder verschlechtern. Standardmäßig sind Links in der visuellen Darstellung zugänglich. Sie können die Barrierefreiheit verbessern, indem sie dem Benutzer helfen, schnell zu verschiedenen Abschnitten eines Dokuments zu navigieren. Sie können die Barrierefreiheit auch beeinträchtigen, wenn ihre zugängliche Darstellung entfernt wird oder wenn JavaScript sie in unvorhersehbarer Weise verhalten lässt.

Standardmäßig heben sich Links visuell von anderem Text durch sowohl Farbe als auch text-decoration ab, wobei Links standardmäßig blau und unterstrichen sind, lila und unterstrichen, wenn sie besucht wurden, und mit einem Fokus-Ring, wenn sie Tastaturfokus erhalten.

Farbe sollte nicht das einzige Unterscheidungsmerkmal zwischen Links und nicht-verlinktem Inhalt sein. Die Linktextfarbe, genauso wie jede andere Textfarbe, muss sich erheblich von der Hintergrundfarbe unterscheiden (ein Kontrast von 4,5:1). Darüber hinaus sollte sich der Linktext visuell signifikant von nicht-verlinktem Text unterscheiden, mit einem Mindestkontrast von 3:1 zwischen Linktext und umgebendem Text sowie zwischen Standard-, besuchtem und Fokus/aktivem Zustand und einem 4,5:1-Kontrast zwischen all diesen Zustandsfarben und der Hintergrundfarbe.

Ankertags werden oft mit dem onclick-Ereignis missbraucht, um Pseudo-Tasten zu erstellen, indem href auf "#" oder "javascript:void(0)" gesetzt wird, um zu verhindern, dass die Seite aktualisiert wird.

Diese Werte verursachen unerwartetes Verhalten beim Kopieren oder Ziehen von Links, Öffnen von Links in einem neuen Tab oder Fenster, Bookmarking und wenn JavaScript noch heruntergeladen wird, Fehler verursacht oder deaktiviert ist. Dies vermittelt auch falsche Semantik an unterstützende Technologien (z. B. Screenreader). In solchen Fällen wird empfohlen, stattdessen eine <button> zu verwenden. Im Allgemeinen sollten Sie ein Anker nur zum Navigieren mit einer richtigen URL verwenden.

Links, die über die target="_blank"-Deklaration in einem neuen Tab oder Fenster geöffnet werden, und Links, deren href-Wert auf eine Datei-Ressource verweist, sollten einen Indikator darüber enthalten, welches Verhalten beim Aktivieren des Links auftreten wird.

Personen mit Sehbehinderungen, die mit der Hilfe einer Screenreading-Technologie navigieren, oder die kognitive Probleme haben, könnten verwirrt sein, wenn das neue Tab, Fenster oder die Anwendung unerwartet geöffnet wird. Ältere Versionen von Screenreading-Software könnten das Verhalten nicht einmal ankündigen.

Link, der ein neues Tab oder Fenster öffnet

<a target="_blank" href="https://www.wikipedia.org/"
  >Wikipedia (opens in a new window)</a
>

Link zu einer nicht-HTML-Ressource

<a target="_blank" href="2017-annual-report.ppt"
  >2017 Annual Report (PowerPoint)</a
>

Wenn ein Symbol anstelle von Text verwendet wird, um auf diese Art von Linkverhalten hinzuweisen, stellen Sie sicher, dass es eine alternative Beschreibung enthält.

• WebAIM: Links and Hypertext - Hypertext Links
• MDN Understanding WCAG, Guideline 3.2 explanations
• G200: Öffnung neuer Fenster und Tabs nur bei Bedarf | W3C Techniken für WCAG 2.0
• G201: Benutzer vorher warnen, wenn ein neues Fenster geöffnet wird | W3C Techniken für WCAG 2.0

Eine Skip-Links, auch bekannt als Skipnav, ist ein a-Element, das so nah wie möglich an dem öffnenden <body>-Element platziert ist und auf den Beginn des Hauptinhalts der Seite verlinkt. Dieser Link ermöglicht es Menschen, Inhalte zu überspringen, die auf mehreren Seiten einer Website wiederholt werden, wie die Kopfzeile und Hauptnavigation der Website.

Skip-Links sind besonders nützlich für Personen, die mit Hilfe von assistiven Technologien wie Schaltsteuerung, Sprachbefehl oder Mundstäben/Kopfwandschaltern navigieren, bei denen die Bewegung durch wiederholte Links eine mühsame Aufgabe sein kann.

• WebAIM: "Skip Navigation" Links
• How-to: Use Skip Navigation links - The A11Y Project
• MDN Understanding WCAG, Guideline 2.4 explanations
• Understanding Success Criterion 2.4.1 | W3C Understanding WCAG 2.0

Wenn große Mengen interaktiver Inhalte eingeschlossen werden — einschließlich Anker —, die in enger visueller Nähe zueinander platziert sind, sollten Abstände eingefügt werden, um sie zu trennen. Dies begünstigt Menschen, die unter feinmotorischen Problemen leiden und möglicherweise versehentlich den falschen interaktiven Inhalt aktivieren, während sie navigieren.

Abstand kann mit CSS-Eigenschaften wie margin erzeugt werden.

• Handtremors und das große-Button-Problem - Axess Lab

Sie sind am Ende dieses Artikels angekommen, aber können Sie sich an die wichtigsten Informationen erinnern? Sehen Sie Testen Sie Ihre Fähigkeiten: HTML Accessibility, um zu überprüfen, ob Sie diese Informationen behalten haben, bevor Sie fortfahren.

Sie sollten jetzt gut darin sein, barrierefreies HTML für die meisten Gelegenheiten zu schreiben. Unser Artikel zu WAI-ARIA-Grundlagen wird helfen, Wissenslücken zu füllen, aber dieser Artikel hat die Grundlagen behandelt. Als Nächstes erkunden wir CSS und JavaScript und wie deren gute oder schlechte Verwendung die Barrierefreiheit beeinflusst.

• Zurück
• Übersicht: Barrierefreiheit
• Weiter