HTML & Barrierefreiheit

HTML & BARRIEREFREIHEIT FAQ Manuel Matuzović, JoomlaDay D-A-C-H, November 14th, 2025

Hallo, vielen Dank, dass ich hier heute dabei sein darf, auch wenn ich leider nicht live dabei bin, aber zumindest online.

accessibility-cookbook.com matuzo.social htmhell.dev matuzo.at manuel@matuzo.at

Mein Name ist Manuel Matuzovic. Ich bin Frontend-Developer, Berater, Dozent, Auditor und Buchautor aus Wien und lebe aktuell in Graz. Als Auditor betrachte ich Websites aus einer Barrierefreiheitssicht, überprüfe sie und schreibe Berichte. Ich hab das schon sehr oft gemacht. Ich habe also schon wirklich viel HTML von anderen gesehen, und mit der Zeit ist mir aufgefallen, dass sich gewisse Fehler wiederholen. Gewisse Fehler treten auf so gut wie jeder Website auf.

Deswegen habe ich für heute beschlossen, eine HTML- und Barrierefreiheits-FAQ zu machen. Ich werde versuchen, ein paar der häufig gestellten Fragen zum Thema HTML zu beantworten. Manche dieser Fragen haben Menschen auf Social Media gestellt. Andere habe ich einfach aus meiner Erfahrung abgeleitet. Wir haben heute genug Zeit. Ich werde meine Fragen, die ich vorbereitet habe, beantworten. Und danach könnt ihr auch noch eigene Fragen oder Follow-up-Fragen stellen.

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

Die erste Frage: Eine SEO-Expertin hat gesagt, dass ich exklusiv H1-Überschriften verwenden muss. Stimmt das?

Nein. Die Antwort ist ganz klar nein. Das sage nicht nur ich aus Überzeugung, sondern auch Google offiziell.

In einer Fragen-und-Antworten-Session auf dem offiziellen Google-Search-Kanal auf YouTube wurde die Frage gestellt, wie man mit SEO und Barrierefreiheit umgeht, also wie man da ein faires Gleichgewicht herstellt. Und die Antwort war ganz klar, dass man vorrangig auf die Barrierefreiheit achten soll und nicht irgendwelche Abstriche wegen Suchmaschinenoptimierung bei der Barrierefreiheit machen soll. Google hat früher sehr viel Gewicht auf Überschriften und Überschriftenstrukturen gelegt, das ist aber jetzt nicht mehr so der Fall. Überschriften sind zwar ein Faktor, aber nicht mehr der wichtigste.

https://www.youtube.com/watch?v=zyqJJXWk0gk

Wie sieht also so eine ideale Struktur aus? Man beginnt immer mit einer H1, die den Inhalt der Seite kurz beschreibt. Darauf folgt eine Reihe von H2, die größere thematische Blöcke innerhalb dieser Seite einleiten, und diese Blöcke können dann auch noch mal weiter in H3 unterteilt werden. Sobald man zu H4,H5,H6 kommt, sollte man sich die Frage stellen, ob es sinnvoll ist, diese Seite vielleicht auf mehrere Seiten aufzuteilen. Der Inhalt der Überschriften soll sinnvoll sein und den Inhalt, der darauf folgt, kurz und prägnant beschreiben. Hier sieht man zum Beispiel, dass die H1 auf der Seite „Aktuell“ „JoomlaDay Aktuell“ lautet und daraufhin eine Reihe von Artikeln folgt, die jeweils mit H2 beginnen.

<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?

Nächste Frage: Was ist eine Landmark?

Ein Bereich auf einer Seite, auf den die Benutzer:in möglicherweise schnell zugreifen möchte. Der Inhalt dieses Bereichs unterscheidet sich von dem anderer Bereiche auf der Seite und ist für einen bestimmten Zweck des Benutzers relevant, z. B. Hauptinhalt, Navigation, Suche. w3.org/TR/wai-aria-1.2/#dfn-landmark Vorlesen Das bedeutet also große wichtige Bereiche innerhalb einer Seite, auf die Benutzer:innen potenziell schnell zugreifen möchten.

Rollen und Elemente ARIA

HTML banner und <header>, complementary und <aside>, contentinfo und <footer>, form und <form aria label|aria labelledby>, main ud <main>, navigation und <nav>, region und <div role=”region”> / <section aria label|aria labelledby>, search und <search>

Dafür haben wir acht Rollen in Aria und acht Elemente in HTML.

• Im Kontext des body, nicht wenn sie in main, section, article, aside, oder nav geschachtelt sind.

Was geben uns Landmarks?

• Kein besonderes Default-Styling aber Stylingmöglichkeiten • Rollen werden bei Betreten und Verlassen angekündigt • Direkter Zugriff via Listen, Gesten, Shortcuts

<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>?

Die nächste Frage ist: Was ist der Unterschied zwischen <section> und <article>? Dafür schauen wir mal in die Spezifikation.

<article> steht für eine vollständige oder in sich geschlossene Komposition in einem Dokument, einer Seite, einer Anwendung oder einer Website, die grundsätzlich unabhängig verbreitet oder wiederverwendet werden kann. z. B. Artikel in einem RSS-Feed, Forumsbeitrag, ein Blogeintrag, ein Kommentar, ein interaktives Widget oder Gadget oder ein anderer unabhängiger Inhalt sein.

html.spec.whatwg.org/multipage/sections.html#the-article-element

Was geben uns Artikel?

• Kein besonderes Default-Styling aber Stylingmöglichkeiten • article Rolle wird bei Betreten und Verlassen angekündigt* • Direkter Zugriff via Listen, Gesten, Shortcuts* * standardmäßig nicht in allen Screen Readern

Und hier müssen wir uns wieder diese wichtige Frage stellen: Was geben uns Artikel?

<section> repräsentiert einen generischen Abschnitt eines Dokuments oder einer Anwendung. Ein Abschnitt ist in diesem Zusammenhang eine thematische Gruppierung von Inhalten, in der Regel mit einer Überschrift. z.B.: Kapitel, die verschiedenen Registerkarten in einem Dialogfeld oder die nummerierten Abschnitte einer Abschlussarbeit. Die Startseite einer Website könnte in Abschnitte für eine Einführung, Neuigkeiten und Kontaktinformationen unterteilt werden.

html.spec.whatwg.org/multipage/sections.html#the-section-element

Was geben uns Sections?

• Kein besonderes Default-Styling aber Stylingmöglichkeiten • generic Rolle ohne Accessible Name • region Rolle mit Accessible Name • Wird zu einer Landmark, wenn bezeichnet.

• Standardmäßig nicht in allen Screenreadern

Standardmäßig hat eine <section> dieselbe Rolle wie ein <div>. Das bedeutet, dass dieses Element keine besondere Rolle für Assistive Technologie spielt. Aber wir haben trotzdem ein semantisches Element in HTML. Eine Sache, die speziell an der <section> ist: Sobald ich sie bezeichne, beispielsweise mit aria-label, ändert sich die Rolle und wird zu region und damit zu einer Landmark.

<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?

• section für thematisch abgetrennte Bereiche auf einer Seite. Als Landmark, wenn User potenziell häufig und schnell darauf zugreifen müssen. Sections kommen üblicherweise mit Überschriften. • article für Inhalt, der für sich stehend außerhalb der Seite auch funktioniert. Wenn man unsicher ist, einfach keins von beiden verwenden.

Wann verwende ich also was? <section> für thematisch abgetrennte Bereiche auf einer Seite. Als Landmark nur dann, wenn Benutzer:innen potenziell häufig und schnell darauf zugreifen wollen. <article> für Inhalt, der für sich stehend außerhalb der Seite auch funktioniert.

Brauche ich ARIA, um Barrierefreiheit sicherzustellen?

Die Antwort ist ganz klar nein. ARIA steht für Accessible Rich Internet Applications und hilft uns, benutzerdefinierte JavaScript-lastige Elemente, die HTML nativ nicht abbilden kann, zu erstellen.

<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.

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

www.w3.org/TR/using-aria/#firstrule

Das ist alles schön und gut, aber in der Spezifikation steht auch, dass wir immer HTML vor ARIA bevorzugen sollen. Wenn wir etwas in HTML abbilden können, sollten wir es auch machen und nicht ARIA verwenden.

<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.

Homepages mit ARIA wiesen mehr als doppelt so viele Fehler auf (durchschnittlich 57) wie Seiten ohne ARIA (durchschnittlich 27).

webaim.org/projects/million/#aria

Das Verständnis dafür, was in HTML möglich ist und wofür ich ARIA benötige, ist sehr wichtig. Der Hauptgrund dafür ist, dass wir sehr schlecht im Umgang mit ARIA sind. Der WebAim Million Evaluation zufolge weisen Startseiten mit ARIA mehr als doppelt so viele Fehler auf wie jene ohne ARIA.

Schadet der Einsatz von Tabellen?

Nein. Nein, absolut nicht. Tabellen sind super.

Was geben uns Tabellen?

• Übersichtliche Anordnung von mehrdimensionalen Listen • Anzahl der Reihen wird angekündigt • Shortcuts für einfache Navigation von Zelle zu Zelle • Tableheaders (<th>) werden angekündigt bei Wechsel von Spalte zu Spalte oder Reihe oder Reihe • Weitere Shortcuts

Wichtig ist nur, dass wir Tabellen nicht für Layout verwenden.

Es kann nicht zu viele Listen geben, oder?

Was geben uns Listen?

• Sie sehen aus wie Listen • Verhalten sich wie Listen (Struktur und Hierarchie) • Anzahl der Elemente wird angekündigt • Aufzählungszeichen bzw. 1., 2., 3. werden angekündigt • Position innerhalb der Liste (z.B., 2 von 4) wird angekündigt • Zusätzliche Shortcuts zur Navigation

Um diese Frage zu beantworten, müssen wir uns wieder anschauen, was uns die Listen geben. Wir sehen, dass Listen wirklich viel bewirken. Wenn wir also Listen übermäßig verwenden und sie dann vielleicht auch noch in Kombination mit anderen Elementen wie Überschriften oder Artikeln, bieten wir zu viel Struktur und machen das Interface unter Umständen zu komplex. Tatsächlich gab es eine Zeit, in der wir Listen so intensiv verwendet haben, dass Apple darauf reagieren musste.

<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.

Die Entscheidung kann man auch auf Webkits Bug-Tracker nachlesen

<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?

Ich meine, grundsätzlich ja.

Soll ich Click-Events auf jedes Element legen?

Nein. Der Grund dafür ist ganz einfach: All jene Aktionen, die ich mit der Maus machen kann, sollte ich auch mit dem Keyboard ausführen können. Konkret geht’s darum, dass, wenn ich mit der Maus klicken kann, ich dasselbe auch mit der Enter-Taste machen können soll. Wenn ich aber ein Klick-Event auf ein Element lege, das mit dem Keyboard nicht fokussierbar ist, funktioniert das nicht.

<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.

Wie zeichne ich Abkürzungen richtig aus?

Eine der wichtigsten Grundlagen ist die OnPageOptimierung. Sie ist das Fundament und eine zentrale Voraussetzung für nachhaltigen SEO-Erfolg.

dach.joomladay.org/de/programm-2025

Schauen wir uns das anhand eines Beispiels an und nehmen folgenden Satz aus der Beschreibung eines Talks für morgen. Für die meisten wird klar sein, wofür SEO steht, weil wir hier ein Fachpublikum haben, aber man kann nicht zu 100 % sicher sein, dass es so ist. In HTML gibt es für Abkürzungen das <abbr>-element.

…zentrale Voraussetzung für nachhaltigen <abbr>SEO</abbr> Erfolg.

Das macht leider nur standmäßig gar nichts in Screen-Readern; es wird nicht speziell angekündigt.

…zentrale Voraussetzung für nachhaltigen <abbr title=”Search Engine Optimization”>SEO abbr Erfolg.

/ < Man kann das title-Attribut angeben. Dadurch bekommt das Element eine gepunktete Unterstreichung und User wissen, dass sie mit der Maus drüber hovern können und dann einen Tool-Tipp mit der Bezeichnung sehen. Das ist eh okay, aber es funktioniert halt nur für Maus-User und Screen Reader kündigen es auch nicht an. Die einzige Ausnahme ist VoiceOver auf macOS.

matuzo.social Eine der wichtigsten Grundlagen ist die OnPageOptimierung. Sie ist das Fundament und eine zentrale Voraussetzung für nachhaltigen Erfolg bei Search Engine Optimization (SEO). Mein Vorschlag wäre, das im Text zu lösen, indem man die Bezeichnung beim ersten Mal ausschreibt, die Abkürzung in Klammern angibt und ab dann nur noch die Abkürzung verwendet.

matuzo.social Was kann ich an meinen <title>s verbessern? Das Thema ist mir auch ein wichtiges Anliegen, weil Titel sehr wichtig sind und häufig falsch verwendet werden. Sie sind wichtig, weil der Titel einer Seite üblicherweise die erste Information ist, die eine Scree-Reader-Nutzer:in hört.

matuzo.social Man sieht auch in den Google-Suchergebnissen, dass sich nicht alles ausgeht.

matuzo.social

matuzo.social

matuzo.social

matuzo.social

matuzo.social

matuzo.social Was kann ich an meinen <title>s verbessern? Bei der Verwendung als Titel der Seite • Einzigartige Titel verwenden • Kurz und treffend • Kontext liefern, wenn es Sinn macht

matuzo.social Womit kann ich am meisten bewegen?

matuzo.social Womit kann ich am meisten bewegen? …um die Barrierefreiheit zu verbessern • Wohlstrukturiertes HTML durch den sauberen und gezielten Einsatz von Überschriften und Listen. • HTML vor ARIA. • Elemente nicht nach Gefühl einsetzen, sondern immer die Frage stellen: „Welchen Nutzen hat dieses Element für die Nutzer:in?“ • Intensiv mit dem Keyboard testen.

matuzo.social matuzo.at/joomladay25

matuzo.social Danke! ❤ accessibility-cookbook.com matuzo.social htmhell.dev matuzo.at manuel@matuzo.at