HTML: Eine gute Grundlage für Barrierefreiheit

Je mehr Sie über HTML lernen — lesen Sie mehr Ressourcen, schauen Sie sich mehr Beispiele an usw. — desto häufiger werden Sie ein gemeinsames Thema erkennen: die Wichtigkeit der Verwendung von semantischem HTML (manchmal als POSH oder Plain Old Semantic HTML bezeichnet). Dies bedeutet, die richtigen HTML-Elemente für ihren vorgesehenen Zweck so oft wie möglich zu verwenden.

Sie könnten sich fragen, warum dies so wichtig ist. Schließlich können Sie eine Kombination aus CSS und JavaScript verwenden, um beinahe jedes HTML-Element so zu verhalten, wie Sie es möchten. Zum Beispiel könnte ein Steuerelement, das ein Video auf Ihrer Website abspielt, folgendermaßen markiert 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 geeignete Standardstile (die Sie wahrscheinlich überschreiben möchten), sie verfügen auch über eingebaute Tastaturzugänglichkeit – Benutzer können mit der Tab-Taste zwischen Schaltflächen 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 es von Beginn Ihres Projekts an konsequent anwenden. Noch besser, semantisches Markup hat neben der Barrierefreiheit weitere Vorteile:

1. Einfacher zu entwickeln — wie oben erwähnt, erhalten Sie einige Funktionen kostenlos, außerdem ist es möglicherweise einfacher zu verstehen.
2. Besser auf mobilen Geräten — semantisches HTML ist möglicherweise leichter in der Dateigröße als nicht-semantischer Spaghetti-Code und einfacher responsiv zu gestalten.
3. Gut für SEO — Suchmaschinen messen Keywords in Überschriften, Links usw. mehr Bedeutung bei als Keywords, die in nicht-semantischen <div>s usw. enthalten sind, wodurch Ihre Dokumente für Kunden besser auffindbar werden.

Lassen Sie uns fortfahren und zugängliches HTML im Detail betrachten.

Wir haben bereits über die Wichtigkeit richtiger Semantik gesprochen und darüber, 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 die Barrierefreiheit schwer beeinträchtigt wird, wenn sie nicht richtig gehandhabt wird.

Draußen im Internet ist die Wahrheit, dass Menschen sehr seltsame Dinge mit HTML-Markup machen. Oft resultiert der Missbrauch von HTML aus älteren Praktiken, die noch nicht verschwunden sind, manchmal passiert es jedoch auch, weil Autoren es nicht besser wissen. In jedem Fall sollten Sie schlechten Code so weit wie möglich mit gutem semantischem Markup ersetzen, sowohl in statischen HTML-Seiten als auch dynamisch generiertem HTML von 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, über die Sie keine Kontrolle haben, oder Sie könnten Inhalte von Drittanbietern auf Ihrer Seite haben (wie Werbebanner).

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

Eines der besten Hilfsmittel für die Barrierefreiheit eines Bildschirmleser-Benutzers ist eine ausgezeichnete Textstruktur mit Überschriften, Absätzen, Listen usw. Ein gutes semantisches Beispiel könnte etwa so 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 Version mit längerem Text vorbereitet, die Sie mit einem Bildschirmleser ausprobieren können (siehe good-semantics.html). Wenn Sie versuchen, darin zu navigieren, werden Sie feststellen, dass es ziemlich einfach zu navigieren ist:

1. Der Bildschirmleser liest jede Überschrift vor, während Sie sich durch den Inhalt bewegen, und teilt Ihnen mit, was eine Überschrift ist, was ein Absatz ist usw.
2. Er hält nach jedem Element an, sodass Sie in Ihrem eigenen angenehmen Tempo gehen können.
3. In vielen Bildschirmlesern können Sie zur nächsten/vorherigen Überschrift springen.
4. Sie können auch eine Liste aller Überschriften in vielen Bildschirmlesern aufrufen, sodass Sie diese als praktische Inhaltsverzeichnis verwenden können, um bestimmten Inhalt zu finden.

Menschen schreiben manchmal Überschriften, Absätze usw. mit Zeilenumbrüchen und fügen HTML-Elemente nur für das Styling hinzu, etwa so:

<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 unsere längere Version mit einem Bildschirmleser ausprobieren (siehe bad-semantics.html), werden Sie keine gute Erfahrung haben — der Bildschirmleser hat nichts, was er als Wegweiser nutzen kann, sodass Sie kein nützliches Inhaltsverzeichnis abrufen können, und die gesamte Seite wird als ein einziger riesiger Block betrachtet, sodass sie auf einmal vollständig vorgelesen wird.

Es gibt auch andere Probleme über die Barrierefreiheit hinaus — es ist schwieriger, den Inhalt mit CSS zu stylen 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 beeinträchtigen. Allgemein sollten Sie klare Sprache verwenden, die nicht unnötig komplex ist und keine unnötigen Jargon- oder Slangbegriffe verwendet. Davon profitieren nicht nur Menschen mit kognitiven oder anderen Behinderungen; es kommt auch Lesern zugute, für die der Text nicht in ihrer Erstsprache geschrieben ist, jüngeren Menschen… jeder, in der Tat! Davon abgesehen sollten Sie versuchen, Sprache und Zeichen zu vermeiden, die vom Bildschirmleser nicht klar vorgelesen werden. Zum Beispiel:

• Verwenden Sie keine Striche, wenn Sie es vermeiden können. Statt 5–7 zu schreiben, schreiben Sie 5 bis 7.
• Kürzel ausschreiben — anstatt Jan zu schreiben, schreiben Sie Januar.
• Akronyme ausschreiben, mindestens einmal oder zweimal, und dann das <abbr>-Tag verwenden, um sie zu beschreiben.

Sie sollten geeignete Gliederungselemente verwenden, um Ihre Webseiten zu strukturieren, zum Beispiel Navigation (<nav>), Fußzeile (<footer>) und sich wiederholende Inhaltseinheiten (<article>). Diese bieten zusätzliche Semantik für Bildschirmleser (und andere Tools), um Benutzern zusätzliche Hinweise über den Inhalt zu geben, den sie navigieren.

Zum Beispiel könnte eine moderne Inhaltsstruktur 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 vollständiges Beispiel hier.

Neben guter Semantik und einem attraktiven Layout sollte Ihr Inhalt in seiner Quellreihenfolge logisch sinnvoll gestaltet sein – Sie können sie später immer mit CSS platzieren, wo Sie möchten, aber Sie sollten die Quellreihenfolge von Anfang an richtig setzen, damit das, was den Bildschirmleser-Benutzern vorgelesen wird, verständlich ist.

Mit UI-Steuerelementen meinen wir die Hauptteile von Webdokumenten, mit denen Benutzer interagieren – am häufigsten Schaltflächen, Links und Formularsteuerelemente. In diesem Abschnitt betrachten wir die grundlegenden barrierefreien Bedenken, auf die Sie achten sollten, wenn Sie solche Steuerelemente erstellen. Spätere Artikel über WAI-ARIA und Multimedia werden auf andere Aspekte der UI-Barrierefreiheit eingehen.

Ein wesentlicher Aspekt der Barrierefreiheit von UI-Steuerelementen ist, dass Browser standardmäßig die Manipulation durch die Tastatur ermöglichen. Sie können dies mit unserem Beispiel native-keyboard-accessibility.html ausprobieren (siehe den Quellcode). Öffnen Sie dies in einem neuen Tab und versuchen Sie, die Tab-Taste zu drücken; nach ein paar Drücken sollten Sie sehen, dass der Tab-Fokus anfängt, sich durch die verschiedenen fokussierbaren Elemente zu bewegen. Die fokussierten Elemente haben in jedem Browser einen hervorgehobenen Standardstil (er unterscheidet sich leicht zwischen verschiedenen Browsern), sodass Sie erkennen können, welches Element fokussiert ist.

Sie können dann Enter/Return drücken, um einen fokussierten Link zu folgen oder eine Schaltfläche zu drücken (wir haben etwas JavaScript eingefügt, um den Schaltflächen eine Meldung hinzuzufügen), oder anfangen zu tippen, um Text in ein Texteingabefeld einzugeben. Andere Formularelemente haben unterschiedliche Steuerungen; zum Beispiel kann das <select>-Element seine Optionen anzeigen und mit den Pfeiltasten auf- und abwärts zwischen ihnen wechseln.

Sie erhalten im Grunde dieses Verhalten kostenlos, nur indem Sie die geeigneten 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>

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

Dies ist jedoch ein weiteres Beispiel, bei dem Menschen manchmal seltsame Dinge mit HTML machen. Zum Beispiel sehen Sie manchmal Tasten, die mit <div>s markiert 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 die Verwendung eines solchen Codes wird nicht empfohlen — Sie verlieren sofort die native Tastatur-Zugänglichkeit, die Sie gehabt hätten, wenn Sie einfach <button>-Elemente verwendet hätten, und Sie erhalten auch nicht den Standard-CSS-Stil, den Schaltflächen haben. In dem seltenen bis nicht existierenden Fall, dass Sie ein Nicht-Schaltflächen-Element für eine Schaltfläche verwenden müssen, verwenden Sie die button role und implementieren Sie alle Standard-Schaltflächenverhaltensweisen inklusive Tastatur- und Mausunterstützung.

Tastaturzugänglichkeit wiederherstellen

Solche Vorteile wieder einzubauen 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>-Buttons die Fähigkeit gegeben, fokussiert zu werden (einschließlich per Tabulator), indem wir jedem das Attribut tabindex="0" hinzugefügt haben. Wir fügen auch role="button" hinzu, damit Bildschirmleser-Benutzer wissen, dass sie das Element fokussieren und damit 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>

Im Grunde ist das Attribut tabindex in erster Linie dazu gedacht, dass tabbare Elemente eine benutzerdefinierte Tab-Reihenfolge haben können (in einer positiven numerischen Reihenfolge angegeben), anstatt einfach in ihrer Standardquellreihenfolge durchgetabbt zu werden. Dies ist fast immer eine schlechte Idee, da es zu großen Verwirrungen führen kann. Verwenden Sie es nur, wenn Sie es wirklich benötigen, zum Beispiel, wenn das Layout die Dinge in einer sehr anderen visuellen Reihenfolge als der Quellcode anzeigt und Sie die Dinge logischer funktionieren lassen möchten. Es gibt zwei andere Optionen für tabindex:

• tabindex="0" — wie oben angegeben, ermöglicht dieser Wert, dass Elemente, die normalerweise nicht tabbar sind, tabbar werden können. Dies ist der nützlichste Wert von tabindex.
• tabindex="-1" — dies ermöglicht nicht tabbaren Elementen, Fokus programmatisch zu erhalten, z.B. über JavaScript oder als Ziel von Links.

Während die obige Ergänzung es uns ermöglicht, die Tasten zu tabben, ermöglicht sie uns nicht, sie über die Enter/Return-Taste zu aktivieren. Dazu mussten wir das folgende Stück JavaScript hinzufügen:

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

Hier fügen wir dem document-Objekt einen Listener hinzu, um zu erkennen, wann eine Taste auf der Tastatur gedrückt wurde. Wir prüfen, welche Taste über die key-Eigenschaft des Ereignisobjekts gedrückt wurde; wenn die Taste Enter/Return gedrückt wurde, führen wir die Funktion aus, die im onclick-Handler der Schaltfläche gespeichert ist, indem wir document.activeElement.click() verwenden. activeElement gibt uns das Element, das derzeit auf der Seite fokussiert ist.

Das ist eine Menge zusätzlicher Aufwand, um die Funktionalität wieder einzubauen. Und es wird sicherlich andere Probleme damit geben. Es ist besser, einfach von Anfang an das richtige Element für die richtige Aufgabe zu verwenden.

Verwenden Sie aussagekräftige Textbezeichnungen

Textbeschriftungen von UI-Steuerelementen sind für alle Benutzer sehr nützlich, aber besonders wichtig für Benutzer mit Behinderungen.

Sie sollten sicherstellen, dass Ihre Schaltflächen- und Link-Textbeschriftungen verständlich und eindeutig sind. Verwenden Sie nicht einfach "Hier klicken" für Ihre Beschriftungen, da Bildschirmleser-Benutzer manchmal eine Liste von Schaltflächen und Formularsteuerelementen aufrufen. Der folgende Screenshot zeigt unsere Steuerelemente, die von VoiceOver auf Mac aufgelistet werden.

Stellen Sie sicher, dass Ihre Beschriftungen sowohl außerhalb des Kontextes, in dem sie gelesen werden, als auch im Kontext des Absatzes, in dem sie enthalten sind, sinnvoll sind. Zum Beispiel zeigt das folgende Beispiel guten Linktext:

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

aber das 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 ebenfalls wichtig, um einen Hinweis darauf zu geben, was Sie in jedes Formulareingabefeld eingeben müssen. Folgendes scheint ein vernünftiges Beispiel zu sein:

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

Dies ist jedoch für behinderte Benutzer nicht besonders nützlich. Es gibt nichts im obigen Beispiel, das die Beschriftung unmissverständlich mit der Formulareingabe verknüpft und klar macht, wie man sie ausfüllt, wenn man sie nicht sehen kann. Wenn Sie mit einigen Bildschirmlesern darauf zugreifen, erhalten Sie möglicherweise nur eine Beschreibung wie "Text bearbeiten".

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 solchem Code wird die Beschriftung klar mit der Eingabe verknüpft; die Beschreibung wird eher wie "Geben Sie Ihren Namen ein: Text bearbeiten".

Ein zusätzlicher Bonus ist, dass in den meisten Browsern, wenn eine Beschriftung mit einer Formulareingabe verknüpft ist, Sie auf die Beschriftung klicken können, um das Formularelement auszuwählen oder zu aktivieren. Dies gibt der Eingabe ein größeres Treffergebiet, was sie leichter auswählbar macht.

Im folgenden Video finden Sie eine gute Erklärung zur Wichtigkeit richtiger Textbeschriftungen und wie Sie Textbeschriftungsprobleme 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 dies hat Probleme — es gibt keine Möglichkeit für einen Bildschirmleser-Benutzer, Reihen oder Spalten als Datenvergruppungen zu assoziieren. Dazu müssen Sie wissen, was die Kopfzeilenreihen sind und ob sie Zeilen, Spalten usw. anführen. Dies kann nur visuell für die obige Tabelle erfolgen (siehe bad-table.html und probieren Sie das Beispiel selbst aus).

Nun schauen Sie sich unser Punkbands-Tabellenbeispiel an — Sie sehen hier ein paar barrierefreie Hilfen:

• Tabellenüberschriften werden mit <th>-Elementen definiert — Sie können auch angeben, ob sie Überschriften für Zeilen oder Spalten sind, indem Sie das scope-Attribut verwenden. Dies gibt Ihnen vollständige Datengruppen, die von Bildschirmlesern als Einzeleinheiten konsumiert werden können.
• Das <caption>-Element und das summary-Attribut des <table>-Elements erfüllen ähnliche Aufgaben – sie fungieren als Alt-Text für eine Tabelle und geben einem Bildschirmleser-Benutzer eine nützliche schnelle Zusammenfassung des Tabelleninhalts. Das <caption>-Element wird im Allgemeinen bevorzugt, da es seinen Inhalt auch für sehende Benutzer zugänglich macht, die es ebenfalls nützlich finden könnten. Sie brauchen wirklich nicht beides.

Während Textinhalte von Natur aus zugänglich sind, kann dasselbe nicht unbedingt über multimediale Inhalte gesagt werden — Bild- und Videoinhalte können von sehbehinderten Menschen nicht gesehen werden, und Audiokontent kann von hörgeschädigten Menschen nicht gehört werden. Wir behandeln Video- und Audiokontent im Detail im Artikel Barrierefreie Multimedia, aber für diesen Artikel werden wir uns die Barrierefreiheit für das bescheidene <img>-Element ansehen.

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

<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 einem Bildschirmleser-Benutzer nicht wirklich viel Hilfe – VoiceOver beispielsweise liest "/dinosaur.png, Bild" vor. Es liest den Dateinamen vor, um etwas Hilfe zu geben. In diesem Beispiel wird der Benutzer zumindest wissen, dass es sich um einen Dinosaurier einer Art handelt, aber oft werden Dateien möglicherweise mit maschinell generierten Dateinamen hochgeladen (z. B. von einer Digitalkamera) und diese Dateinamen bieten wahrscheinlich keinen Kontext zum Bildinhalt.

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

Das zeigt die Wichtigkeit, nicht nur aussagekräftige Dateinamen zu verwenden, falls sogenannter Alt-Text nicht verfügbar ist, sondern auch sicherzustellen, dass Alt-Text immer wo möglich in alt-Attributen bereitgestellt wird.

Beachten Sie, dass die Inhalte des alt-Attributs immer eine direkte Darstellung des Bildes und dessen visueller Aussage vermitteln sollten. Der Alt sollte kurz und prägnant sein und alle Informationen enthalten, die im Bild vermittelt werden, die nicht im umgebenden Text wiederholt werden.

Der Inhalt des alt-Attributs für ein einzelnes Bild unterscheidet sich 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 Tierschutzgesellschaft ist, sollten Information im Bild, die für einen potenziellen Hundebesitzer relevant sind und die nicht im umgebenden Text wiederholt sind, enthalten sein. Eine längere Beschreibung wie alt="Fluffy, ein dreifarbiger Terrier mit sehr kurzem Haar, mit einem Tennisball im Maul." ist angemessen. Da der umgebende Text wahrscheinlich Fluffys Größe und Rasse enthält, ist das nicht im alt enthalten. Da Fluffys Biografie wahrscheinlich nicht Haarlänge, Farben oder Spielzeugvorlieben enthält, die der potenzielle Besitzer wissen muss, ist das enthalten. Ist das Bild im Freien, oder hat Fluffy ein rotes Halsband mit blauer Leine? Nicht wichtig im Hinblick auf die Adoption des Haustiers und daher nicht enthalten. Alle Informationen, die ein Bild vermittelt und auf die ein sehender Benutzer zugreifen kann und die für den Kontext relevant sind, müssen vermittelt werden; nicht mehr. Halten Sie es kurz, präzise und nützlich.

Persönliche Kenntnisse oder zusätzliche Beschreibungen sollten hier nicht enthalten sein, da sie für Personen, die das Bild noch nie gesehen haben, nicht nützlich sind. Wenn der Ball das Lieblingsspielzeug von Fluffy ist oder ein sehender Benutzer dies aus dem Bild nicht erkennen kann, schließen Sie es nicht ein.

Ein Aspekt, den Sie berücksichtigen sollten, ist, ob Ihre Bilder innerhalb Ihres Inhalts eine Bedeutung haben oder ob sie rein zur visuellen Dekoration dienen und daher 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 kontextbezogene Informationen bereitstellen möchten, sollten Sie diese in den Text um das Bild herum oder in ein title-Attribut einfügen, wie oben gezeigt. In diesem Fall werden die meisten Bildschirmleser den Alt-Text, das Title-Attribut und den Dateinamen vorlesen. Zusätzlich zeigen Browser Titeltext als Tooltips an, wenn sie mit der Maus überfahren werden.

Werfen wir einen kurzen Blick auf die vierte Methode:

<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 normalen Textabsatz dargestellt, ihm eine id zugewiesen und dann das aria-labelledby-Attribut verwendet, um auf diese id zu verweisen, was Bildschirmleser veranlasst, diesen Absatz als Alt-Text/Beschriftung für das Bild zu 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 Figurenunterschrift verknüpfen:

<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 die Unterstützung von Bildschirmlesern für die Verknüpfung von Figurenunterschriften mit ihren Figuren gemischt ist, wird die Verknüpfung, wenn keine vorhanden ist, durch Einfügen von aria-labelledby oder aria-describedby hergestellt. Trotzdem ist die Elementstruktur nützlich für CSS-Styling, außerdem bietet sie eine Möglichkeit, eine Beschreibung des Bildes neben ihm im Quelltext zu platzieren.

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

Es kann Zeiten geben, in denen ein Bild im Design einer Seite enthalten ist, seine primäre Funktion jedoch die visuelle Dekoration ist. Sie werden im obigen Codebeispiel feststellen, dass das alt-Attribut des Bildes leer ist — dies soll Bildschirmleser das Bild erkennen lassen, aber nicht versuchen, das Bild zu beschreiben (stattdessen würden sie nur "Bild" oder ähnliches sagen).

Der Grund für die Verwendung eines leeren alt anstelle des Nicht-Einschlusses ist, dass viele Bildschirmleser die gesamte Bild-URL ankündigen, wenn kein alt bereitgestellt wird. Im obigen Beispiel fungiert das Bild als visuelle Dekoration für die zugehörige Überschrift. In solchen Fällen, und in Fällen, in denen ein Bild nur dekorativ ist und keinen Inhaltswert hat, sollten Sie in Ihren img-Elementen ein leeres alt einfügen. Eine andere Alternative ist die Verwendung des role Attributs role="presentation", da dies auch Bildschirmleser daran hindert, den Alternativtext vorzulesen.

Links (das <a>-Element mit einem href-Attribut), je nachdem, wie sie verwendet werden, können zur Barrierefreiheit beitragen oder sie beeinträchtigen. Standardmäßig sind Links in ihrem Erscheinungsbild zugänglich. Sie können die Zugänglichkeit verbessern, indem sie einem Benutzer helfen, schnell zu verschiedenen Abschnitten eines Dokuments zu navigieren. Sie können jedoch die Zugänglichkeit beeinträchtigen, wenn ihr zugängliches Styling entfernt wird oder wenn JavaScript sie dazu bringt, sich auf unerwartete Weise zu verhalten.

Standardmäßig unterscheiden sich Links visuell von anderen Texten sowohl in Farbe als auch in Text-Dekoration, wobei Links standardmäßig blau und unterstrichen sind, lila und unterstrichen, wenn sie besucht wurden, und mit einem Fokus-Ring, wenn sie über die Tastatur fokussiert werden.

Farbe sollte nicht als einzige Methode verwendet werden, um Links vom nicht verlinkten Inhalt zu unterscheiden. Die Link-Text-Farbe muss, wie aller Text, deutlich unterschiedlich zur Hintergrundfarbe sein (ein Kontrast von 4,5:1). Zusätzlich sollten Links visuell deutlich vom nicht verlinkten Text abweichen, mit einer Mindestkontrastanforderung von 3:1 zwischen Link-Text und umgebendem Text sowie zwischen Standard-, Besuchs- und Fokus-/Aktiv-Zuständen und einem Kontrast von 4,5:1 zwischen all diesen Statusfarben und der Hintergrundfarbe.

Ankertags werden oft mit dem onclick-Ereignis missbraucht, um Pseudo-Schaltflächen zu schaffen, 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, beim Setzen von Lesezeichen und wenn JavaScript noch herunterlädt, fehlerhaft ist oder deaktiviert ist. Dies vermittelt auch falsche Semantik an unterstützende Technologien (z. B. Bildschirmleser). In diesen Fällen wird empfohlen, stattdessen ein <button> zu verwenden. Im Allgemeinen sollten Sie ein Ankerelement nur für die Navigation mit einer richtigen URL verwenden.

Links, die in einem neuen Tab oder Fenster über die Deklaration target="_blank" geöffnet werden, und Links, deren href-Wert auf eine Dateiquelle zeigt, sollten einen Hinweis auf das Verhalten enthalten, das beim Aktivieren des Links auftreten wird.

Personen mit Sehbehinderungen, die mit Hilfe von Bildschirmlesertechnologie oder kognitiven Beeinträchtigungen navigieren, könnten verwirrt werden, wenn ein neuer Tab, ein Fenster oder eine Anwendung unerwartet geöffnet wird. Ältere Versionen von Bildschirmlesesoftware könnten das Verhalten nicht einmal ankündigen.

Link, der einen neuen Tab oder ein neues 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 das Verhalten solcher Links anzuzeigen, stellen Sie sicher, dass es eine alternative Beschreibung enthält.

• WebAIM: Links und Hypertext - Hypertext-Links
• MDN Verständnis von WCAG, Guideline 3.2 Erklärungen
• G200: Öffnen neuer Fenster und Tabs aus einem Link heraus nur bei Bedarf | W3C Techniken für WCAG 2.0
• G201: Nutzern einen Hinweis geben, wenn ein neues Fenster geöffnet wird | W3C Techniken für WCAG 2.0

Ein Skip-Link, auch als Skipnav bekannt, ist ein a-Element, das so nah wie möglich am öffnenden <body>-Element platziert wird und auf den Anfang des Hauptinhalts der Seite verlinkt. Dieser Link ermöglicht es Menschen, Inhalte zu überspringen, die auf mehreren Seiten einer Website wiederholt werden, wie z. B. die Kopfzeile und die primäre Navigation einer Website.

Skip-Links sind besonders nützlich für Personen, die mit Unterstützungstechnologien wie Schaltersteuerung, Sprachbefehlen oder Mundstäben/Kopfstäben navigieren, wobei das Navigieren durch wiederholte Links eine mühsame Aufgabe sein kann.

• WebAIM: "Navigation überspringen" Links
• Anleitung: Verwendung von Skip-Nav-Links - The A11Y Project
• MDN Verständnis von WCAG, Leitfaden 2.4 Erklärungen
• Verständnis des Erfolgskriteriums 2.4.1 | W3C Verständnis von WCAG 2.0

Große Mengen an interaktivem Inhalt – einschließlich Anker – die in enger visueller Nähe zueinander platziert sind, sollten Abstände haben, um sie zu trennen. Dieser Abstand kommt Menschen zugute, die an feinmotorischen Kontrollproblemen leiden und möglicherweise versehentlich den falschen interaktiven Inhalt aktivieren, während sie navigieren.

Der Abstand kann mit CSS-Eigenschaften wie margin erstellt werden.

• Handzittern und das Riesenknopf-Problem - Axess Lab

Sie haben das Ende dieses Artikels erreicht, aber können Sie sich noch an die wichtigsten Informationen erinnern? Sehen Sie sich Testen Sie Ihre Fähigkeiten: HTML Accessibility an, um zu überprüfen, ob Sie diese Informationen gespeichert haben, bevor Sie weitermachen.

Sie sollten nun gut darauf vorbereitet sein, für die meisten Gelegenheiten zugängliches HTML zu schreiben. Unser WAI-ARIA-Grundlagenartikel wird helfen, Lücken in diesem Wissen zu schließen, aber dieser Artikel hat sich um die Grundlagen gekümmert. Als Nächstes werden wir CSS und JavaScript untersuchen und wie Barrierefreiheit durch deren gute oder schlechte Verwendung beeinflusst wird.

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