HTML & Barrierefreiheit

SEO Audit: Alles muss eine <h1> sein. Stimmt das?

<h1>JoomlaDay™ Aktuell</h1>
<h2>JoomlaDay DACH 2025 – Less than three weeks to go!</h2>
<h2>Das Programm ist online!</h2>
<h2>JJ!Otto AWARD 2025 - Bewerbung für die besten Website mit…</h2>
<h2>Jetzt Tickets für den JoomlaDay DACH 2025 sichern!</h2>
<h2>Newsletter abonnieren</h2>

Eine perfekte Überschriftenstruktur funktioniert auch außerhalb des Kontexts der Website. Das bedeutet, wenn ich nur die Überschriften betrachte, muss mir klar sein, was für eine Seite das ist und wie sie inhaltlich aufgeteilt ist.

Was ist eine Landmark?

Rollen und Elemente ARIA

Was geben uns Landmarks?

<header>
  <nav></nav>
</header>

<main>
  <nav></nav>
</main>

<footer></footer>

Klassische Beispiele dafür sind der Header und der Footer der Website, ebenso der Hauptinhalt und eine oder mehrere Navigationen.

<header>
  <nav></nav>
</header>

<main>
  <nav></nav>
</main>

<footer></footer>

Manchmal kann es auch Sinn machen, benutzerdefinierte Landmarks zu erstellen. Zum Beispiel könnte ich die Suchergebnisse auf einer Seite zu einer Landmark machen, damit man direkt hinspringen kann, oder die Zusammenfassung in einem Artikel ebenfalls als Landmark auszeichnen, um die Navigation zu vereinfachen.

Wichtig ist, dass ich sparsam mit Landmarks umgehe, weil, wenn alles eine Landmark ist, ist nichts eine Landmark. Ich sollte mich hier wirklich auf die wichtigsten Bereiche beschränken, auf die potenziell häufig und schnell zugegriffen werden will.

<nav aria-label="Haupt"></nav>
<nav aria-label="Sie befinden sich hier"></nav>
<nav aria-label="Auf dieser Seite"></nav>
<nav aria-label="Kategorien"></nav>

Eine Sache, die noch wichtig ist, ist, wenn ich mehrere Landmarks vom selben Typ habe, zum Beispiel Navigationen. Dann muss ich sie benennen, damit sie einzigartig sind. Man sieht hier, dass ich aria-label verwende, um den Navigationen einen Namen zu geben.

Was ist der Unterschied zwischen <section> und <article>?

Was geben uns Artikel?

Was geben uns Sections?

<section aria-label="Sprecher*innen"></section>
<section aria-label="Programm"></section>

Hier ein Beispiel dafür. Zwei sections mit der Rolle region und dem Accessible Name “Sprecher*innen” und “Programm”.

Wann verwende ich was?

Brauche ich ARIA, um Barrierefreiheit sicherzustellen?

<div role="tablist" aria-labelledby="tablist-1">
  <button role="tab" aria-selected="true" id="tab-1" type="button">
    Table
  </button>
  <button role="tab" aria-selected="false" id="tab-2" type="button" tabindex="-1">
    Map
  </button>
</div>

<div role="tabpanel" id="tabpanel-1" aria-labelledby="tab-1" tabindex="0"></div>
<div role="tabpanel" id="tabpanel-2" aria-labelledby="tab-2" tabindex="0" hidden></div>

Zum Beispiel gibt es in HTML kein Element für Reiter, aber in ARIA haben wir die entsprechenden Rollen, um Reiter barrierefrei zu gestalten.

<dialog>
  <h1>Dialog</h1>
</dialog>

Das Schöne an HTML ist, dass es sich stetig weiterentwickelt und wir immer mehr Dinge in HTML abbilden können, die vorher nur mit ARIA möglich waren. Ein Beispiel sind Dialoge. In HTML ist das <dialog>-Element nativ.

<button popovertarget="content">Show</button>
<div popover id="content">
  Content
</div>

Ein sehr aktuelles Beispiel sind Popover, die es ermöglichen, nichtmodale Dialoge zu erstellen und komplett ohne JavaScript zu öffnen und zu schließen.

<details>
  <summary>Show</summary>
  Content
</details>

Oder das <details>-Element, schon ein bisschen älter, mit dem ich komplett ohne JavaScript und ARIA Disclosure-Widgets erstellen kann.

Schadet der Einsatz von Tabellen?

Was geben uns Tabellen?

Es kann nicht zu viele Listen geben, oder?

Was geben uns Listen?

<ul style="list-style: none;">
  <li>…</li>
</ul>

<ul style="display: flex;">
  <li>…</li>
</ul>

Wenn man VoiceOver, den in macOS und iOS eingebauten Screen Reader, verwendet und Listen nicht aussehen wie Listen, werden sie auch nicht als Listen angekündigt. Der Grund dafür ist, dass es eine Zeit lang auf vielen Sites einfach zu viele Listen gab, die die Situation für Screenreader-Nutzer:innen nicht verbessert haben, sondern das Gegenteil.

<nav>
  <ul>
    <li>…</li>
  </ul>
</nav>

Eine Ausnahme bei VoiceOver sind Listen innerhalb von <nav>-Elementen. Da wird die Semantik beibehalten, auch wenn die Listen nicht aussehen wie Listen.

<ul style="list-style-type: '';">
  <li>…</li>
</ul>

Wenn man sich ganz sicher ist, dass eine Liste, die nicht aussieht wie eine Liste, trotzdem die semantische Information auch in allen Screan-Readern übermitteln soll, kann man diesen Workaround verwenden: Anstatt dass man list-style-type auf none setzt, setzt man’s auf einen leeren String und da wird die Semantik dann beibehalten.

Kann ich Click-Events auf jedes Element legen?

Soll ich Click-Events auf jedes Element legen?

<div class="button" onclick="alert(1)">
  Login
</div>

Der JavaScript-Befehl in diesem Beispiel, bei dem ich ein Klick-Event auf ein <div> gelegt habe, wird nur bei einem Klick ausgeführt. Keyboard-Nutzer:innen erreichen dieses Element erst gar nicht

<table>
  <tr>
    <td onclick="alert(1)">Name</td>
  </tr>
</table>

Das gilt nicht nur für generische Elemente wie <div>, sondern für jegliches andere Element, das nicht mit dem Keyboard fokussierbar ist.

<table>
  <tr>
    <td>
      <button onclick="alert(1)">
        Name
      </button>
    </td>
  </tr>
</table>

In so einem Fall brauche ich fast immer einen Button.