Beispiel für ein Website-Barrierefreiheits-Audit gemäß WCAG 2.2 A und AA

In diesem Artikel habe ich die Website portfolio.barrierenlos.com/audit-demo systematisch anhand der WCAG 2.2 A und AA-Kriterien [1] überprüft. Die Prüfung erfolgte am 06. April 2025. Dabei kamen sowohl automatisierte Tools (Simulierte Prüfung mit WAVE Browser Extension, manuelle Code-Inspektion) als auch manuelle Tests mit Screenreader und Tastaturnavigation zum Einsatz.

warnung

Ziel dieses Berichts ist Dir zu zeigen, wie ein professionelles Barrierefreiheits-Audit durchgeführt wird und welche Maßnahmen zur Verbesserung der digitalen Zugänglichkeit empfohlen werden.

Ein echtes Audit ist meistens umfassender, beinhaltet mehr Details und berücksichtigt die spezifischen Anforderungen und Inhalte der jeweiligen Website. Dieser Bericht dient als Beispiel für die Durchführung eigener Audits.

Falls Du ein professionelles Audit für Deine eigene Website benötigst, informiere Dich gerne über unser BFSG-Audit-Angebot.

Wie ist der Bericht aufgebaut?

Der Bericht ist wie die WCAG 2.2 [1] strukturiert, wobei zu jedem Kriterium eine Bewertung erfolgt. Für jedes nicht erfüllte Kriterium der WCAG 2.2 (A und AA) wurden ausführliche Erklärungen mit Code-Beispielen erstellt, und es wurden entsprechende To-Dos abgeleitet. Am Ende des Berichts befindet sich eine Übersicht aller To-Dos, die im Audit zusammengetragen wurden. Die Erfüllung dieser To-Dos wird eine barrierefreie Website und BFSG-Konformität [2] sicherstellen.

Im Folgenden werden die Ergebnisse und Empfehlungen detailliert vorgestellt, die nach den vier Prinzipien der Barrierefreiheit im Web gegliedert sind: Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit.

Überblick über die vier WCAG-Prinzipien und den Erfüllungsstatus der Demo-Website

Beschreibung der Übersichtsgrafik

In diesem Diagramm werden die vier WCAG-Prinzipien wahrnehmbar, bedienbar, verständlich und robust gezeigt. Zu jedem Prinzip steht, dass mehrere beziehungsweise viele Kriterien in der Demo-Website nicht erfüllt sind und welche Problemtypen dort auftreten, etwa Kontrast, Tastaturbedienung, fehlende Fehlermeldungen oder mangelhafte Semantik.

Ist Deine Website für alle Nutzer wahrnehmbar?

Die Wahrnehmbarkeit ist das erste der vier grundlegenden Prinzipien der Barrierefreiheit im Web [3].

Sie legt den Grundstein dafür, dass alle Nutzer, unabhängig von ihren sensorischen Fähigkeiten, Zugang zu Deinen Inhalten haben.

Ob jemand eine Sehbehinderung hat, schwerhörig ist oder spezielle Technologien zur Bedienung des Internets nutzt – durch die Beachtung der folgenden Richtlinien sorgst Du dafür, dass niemand ausgeschlossen wird.

Gib Textalternativen für alles, was kein Text ist.

Nicht-erfüllt: Nicht-Text-Inhalte – WCAG 2.2, 1.1.1. (A)

• Hast Du für alle einfachen nicht-textuellen Inhalte eine kurze textuelle Alternative bereitgestellt, die denselben Zweck erfüllt und die gleichen Informationen vermittelt?
• Hast Du für komplexe nicht-textuelle Inhalte wie Diagramme oder Infografiken eine ausführlichere textuelle Beschreibung bereitgestellt? (Keine solchen Inhalte vorhanden)
• Hast Du für alle Steuerelemente und Eingabefelder eine klare und eindeutige textuelle Beschreibung hinzugefügt, die deren Funktion erklärt? (Wird unter 3.3.2 und 4.1.2 behandelt, wo es fehlschlägt)
• Hast Du für zeitbasierte Medien oder Inhalte eine passende kurze textuelle Beschreibung bereitgestellt? (Keine relevanten zeitbasierten Medien vorhanden)
• Hast Du für CAPTCHAs eine textuelle Beschreibung bereitgestellt und eine alternative Methode angeboten? (Kein CAPTCHA vorhanden)
• Hast Du nicht-textuelle Inhalte so implementiert oder markiert, dass sie von unterstützender Technologie ignoriert werden, wenn sie keine relevanten Informationen liefern?

Jedes Bild, das relevante Informationen vermittelt (nicht rein dekorativ ist), benötigt einen beschreibenden Alternativtext [4], [5]. Rein dekorative Bilder sollten ein leeres alt=""-Attribut haben, damit sie von Screenreadern übersprungen werden [6], [7].

'Entscheidungsbaum für Alt-Texte'

Textuelle Beschreibung des Entscheidungsbaums

Der Entscheidungsbaum beschreibt Schritt für Schritt, wie bestimmt wird, ob ein Bild einen Alternativtext benötigt und welcher Art dieser Alt-Text sein muss.

1. Startpunkt: Zuerst wird geprüft, ob das Bild interaktiv ist, also ob es anklickbar ist oder eine Funktion auslöst.

2. Wenn das Bild interaktiv ist, folgen mehrere Abzweigungen:

   • Handelt es sich um eine Image Map, also eine Grafik mit mehreren klickbaren Bereichen, müssen sowohl das <img> als auch jede einzelne <area> einen Alt-Text haben.
   • Wenn das Bild die einzige Information in einem Link oder Button ist, beschreibt der Alt-Text die Funktion oder das Ziel (z. B. „Menü öffnen“).
   • Wenn zusätzlich sichtbarer Text vorhanden ist, wird geprüft, ob dieser Text die Funktion vollständig beschreibt.
     • Falls nicht, ist ein Alt-Text nötig, der die zusätzliche Bedeutung erklärt, z. B. Hinweise wie „öffnet in neuem Fenster“.
     • Falls ja, ist das Bild rein dekorativ und soll ein leeres alt="" erhalten oder als CSS-Bild eingebunden werden.

3. Wenn das Bild nicht interaktiv ist, verzweigt der Baum in mehrere spezialisierte Fälle:

   • CAPTCHAs: brauchen einen Alt-Text, der den Zweck beschreibt, und müssen eine alternative Methode bereitstellen.
   • Komplexe Grafiken: Diagramme, Infografiken oder Organigramme benötigen einen kurzen Alt-Text sowie eine ausführliche Langbeschreibung.
   • Logos: Der Alt-Text ist der Name der Organisation.
   • Textbilder: Der Alt-Text gibt den Text im Bild exakt wieder.
   • Bildgruppen, wie Sterne einer Bewertung: Der Alt-Text gehört nur ans erste Bild, die übrigen bekommen alt="".
   • Symbolische Icons, die im Text eine Bedeutung tragen: Der Alt-Text beschreibt die Bedeutung, z. B. „erledigt“ oder „Fehler“.
   • Emotionale oder stimmungsorientierte Bilder: Der Alt-Text beschreibt die vermittelte Stimmung.
   • Bilder, die als Label dienen, z. B. ein Telefon-Icon: Der Alt-Text ergänzt das Label, z. B. „Telefon:“.
   • Bilder, die sachliche Zusatzinformationen geben: benötigen einen Alt-Text, der diese Information vermittelt.

4. Wenn keine der Bedingungen zutrifft, ist das Bild dekorativ. In diesem Fall erhält es alt="" oder wird als CSS-Hintergrund eingebunden.

Der Entscheidungsbaum führt also von der allgemeinen Frage „Was für ein Bild ist das?“ über verschiedene Bildtypen bis zur abschließenden Entscheidung, ob ein Alt-Text nötig ist und welcher Art dieser sein muss.

Auf dieser Demo-Seite sind alle Bilder jedoch rein dekorativ und benötigen keine Beschreibung, obwohl jedes Bild ein alt-Attribut hat. Sie tragen dem Inhalt nichts bei und würden den Nutzer mit extra-Inhalten eher überlasten.

Beispiel aus dem Slider:

Beispiel für ein dekoratives Bild im Slider-Bereich der Beispiel-Website.

Von daher sollten alle Bilder auf der Seite ein leeres alt-Attribut haben, z. B.:

Beispiel für ein Bild ohne Alternativtext

<img src="bild-2.jpg" alt="" width="..." height="..." />

To-Dos:

• Alternativtexte für alle Bilder leeren.

Biete Alternativen für zeitbasierte Medien.

info

Gemäß § 1 Abs. 4 Nr. 1 BFSG [2] sind die zeitbasierte Medien, die vor dem 28. Juni 2025 veröffentlicht wurden, von den Barrierefreiheitsanforderungen ausgenommen. Also sind alle Anforderungen in diesem Abschnitt erst mal automatisch erfüllt.

Auf dieser Website sind keine zeitbasierten Medien (Audio oder Video) eingebunden. Daher sind alle Anforderungen in diesem Abschnitt erfüllt.

Erfüllt: Nur Audio und Nur Video (Vorab aufgezeichnet) – WCAG 2.2, 1.2.1 (A)

• Hast Du für alle vorab aufgezeichneten Audio-Inhalte eine gleichwertige Textalternative bereitgestellt?
• Hast Du für alle vorab aufgezeichneten Video-Inhalte ohne Ton eine gleichwertige Textalternative oder einen Audiotrack bereitgestellt?

Erfüllt: Untertitel (Vorab aufgezeichnet) – WCAG 2.2, 1.2.2 (A)

• Bietest Du für vorab aufgezeichnete Audioinhalte in synchronisierten Medien Untertitel an?

Erfüllt: Audiodeskription oder Medienalternative (Vorab aufgezeichnet) – WCAG 2.2, 1.2.3 (A)

• Hast Du für vorab aufgezeichnete Video-Inhalte entweder eine Audiodeskription oder eine Textalternative bereitgestellt?

Erfüllt: Untertitel (Live) – WCAG 2.2, 1.2.4 (AA)

• Bietest Du für Live-Audioinhalte in synchronisierten Medien Untertitel an?

Erfüllt: Audiodeskription (Vorab aufgezeichnet) – WCAG 2.2, 1.2.5 (AA)

• Hast Du für vorab aufgezeichnete Videos in synchronisierten Medien eine Audiodeskription hinzugefügt?

Erstelle flexible Inhalte ohne Informationsverluste.

Deine Website sollte so gestaltet sein, dass sie sich an die Bedürfnisse der Nutzer anpasst. Das betrifft nicht nur die Darstellung auf verschiedenen Geräten, sondern auch die Bedienung mit unterschiedlichen Eingabemethoden.

Nicht-erfüllt: Informationen und Beziehungen – WCAG 2.2, 1.3.1 (A)

• Werden Informationen und Beziehungen mittels semantischer Struktur programmatisch erkennbar gemacht?
• Wenn die verwendete Technologie keine semantische Struktur unterstützt, bietest Du dann textliche Alternativen oder zusätzliche Erläuterungen an? (HTML unterstützt Semantik, sie wird nur nicht genutzt)

Die semantische HTML-Struktur der Website ist grundlegend mangelhaft. Sie verwendet fast ausschließlich generische <div>- und <span>-Elemente anstelle von semantisch korrekten HTML-Tags, die die Struktur und Bedeutung von Inhalten für assistive Technologien (wie Screenreader) und Browser verständlich machen [8]. Dies führt zu erheblichen Barrieren.

Seitenstruktur und Landmarken

Seitenbereiche wie Header, Navigation, Hauptinhalt, einzelne Abschnitte (Sektionen) und der Footer sind nicht mit den dafür vorgesehenen HTML5-Elementen (<header>, <nav>, <main>, <footer>) ausgezeichnet [9], [10].

Semantische Seitenstruktur mit HTML5-Landmarks

Textuelle Beschreibung des Diagramms zur semantischen Seitenstruktur

Das Diagramm zeigt die Struktur einer Webseite mit body, Skip-Link, Header, Main und Footer. Im Main-Bereich liegen mehrere Sektionen wie Hero, Slider, Features und FAQ. Header, Main und Footer sind als Landmarks hervorgehoben, weil sie für Screenreader eine schnelle Navigation ermöglichen.

Diese Elemente definieren sogenannte „Landmark Regions“, die es Nutzern assistiver Technologien ermöglichen, schnell zwischen wichtigen Bereichen der Seite zu navigieren.

Ausschnitt aus dem Google Chrome DevTools-Inspektor, der die fehlende semantische Struktur für den Header-Bereich der Beispiel-Website zeigt.

Damit Du aus einer Sektion ebenfalls eine Landmark machst, solltest Du das <section>-Element verwenden, um thematisch zusammengehörige Inhaltsblöcke zu gruppieren, und diese eindeutig mit diesem Titel über aria-labelledby [11] benennen.

Hier ist ein Beispiel, wie ein Landmark-Menü bei VoiceOver aussieht:

Beispiel für ein Landmark-Menü in VoiceOver

Ein kurzes Video, das zeigt, wie ein Nutzer mit VoiceOver das Landmark-Menü einer Website öffnet und die verschiedenen Landmark-Regionen der Seite erkundet.

Wiedergabeposition

Lautstärke

0:00 von 0:00

Sollte das nicht möglich sein, stelle einfach sicher, dass die Sektionen mit <h1...6> ausgezeichnet sind [12]. Die Nutzer können sich dann schnell auf der Seite zurechtfinden, indem sie sich im Rotor-Menü alle Überschriften anzeigen lassen.

Beispiel der Navigation über Headings in VoiceOver

Ein kurzes Video, das zeigt, wie ein Nutzer mit VoiceOver das Headings-Menü einer Website öffnet und die verschiedenen Überschriften der Seite erkundet.

Wiedergabeposition

Lautstärke

0:00 von 0:00

Code der Problemstelle

Ausschnitt aus der Website ohne semantische Seitenstruktur

<body>
  <div class="site-header"></div>
  <div class="hero">...</div>
  <div class="slider-section">...</div>
  <div class="section">...</div>
  <div class="section-alt">...</div>
  <div class="site-footer">...</div>
</body>

Code, wie er richtig wäre

Beispiel mit semantischer Seitenstruktur und Landmarken

<body>
  <a href="#main-content" class="skip-link">Zum Inhalt springen</a>
  <header class="site-header"></header>

  <main id="main-content">
    <div class="hero">
      <h1 id="hero-title">...</h1>
      ...
    </div>

    <section class="slider-section" aria-labelledby="slider-title">
      <h2 id="slider-title">Aktuelle Highlights.</h2>
      ...
    </section>

    <section class="features-section" aria-labelledby="features-title">
      <h2 id="features-title">...</h2>
      ...
    </section>

    <section class="alternating-section-1" aria-labelledby="alt1-title">
      <h2 id="alt1-title">...</h2>
      ...
    </section>
  </main>
  <footer class="site-footer"></footer>
</body>

Dabei ist es wichtig zu erwähnen, dass die erste Sektion nicht als solche gekennzeichnet ist, weil der Titel in dieser Sektion die ganze Seite beschriftet.

To-Dos:

• Seitenstruktur mit korrekten HTML5-Landmark-Elementen auszeichnen: <header>, <nav>, <main>, <section>, <footer>.
• Dem <main>-Element eine ID (id="main-content") geben als Ziel für den Skip-Link.
• <section>-Elemente verwenden, um thematisch zusammengehörige Inhaltsblöcke zu gruppieren und diese mit Überschriften und aria-labelledby zu benennen.

Überschriften

Überschriften werden durch visuell gestylte <div>-Elemente (.hero-title, .section-title, .feature-title, .layout-title) anstelle von echten Überschriften-Tags (<h1> - <h6>) dargestellt [12].

Ausschnitt aus dem Google Chrome DevTools-Inspektor, der die fehlenden semantischen Überschriften der Beispiel-Website zeigt.

Dadurch geht die hierarchische Struktur des Dokuments verloren, die für Screenreader-Nutzer zur Navigation und zum Verständnis der Seitenorganisation essenziell ist [8], [13].

Beispiel für eine logische Überschriften-Hierarchie

Textuelle Beschreibung des Diagramms zur Überschriften-Hierarchie

Das Diagramm zeigt eine saubere Überschriftenhierarchie. Ganz oben steht eine einzige h1 für den Seitentitel. Darunter folgen h2-Überschriften für Hauptsektionen wie „Why Choose CoursePro?“ und „How it Works“. Unter jeder h2 stehen passende h3-Überschriften für die Unterpunkte. Es werden keine Hierarchieebenen übersprungen.

Code der Problemstelle

Ausschnitt aus der Website ohne semantische Überschriften

<div class="hero-title">Unlock Your Potential...</div>
<div class="section-title">Why Choose CoursePro?</div>
<div class="feature-item">
  <div class="feature-title">Expert Instructors</div>
  ...
</div>

Code, wie er richtig wäre

Beispiel mit semantischen Überschriften

<h1 class="hero-title">Unlock Your Potential...</h1>

<h2 class="section-title">Why Choose CoursePro?</h2>

<div class="feature-item">
  <h3 class="feature-title">Expert Instructors</h3>
  ...
</div>

warnung

Die Überschriftenebene (h1 bis h6) muss der logischen Struktur der Seite folgen und darf keine Ebenen überspringen [12]. Das bedeutet, dass nach einer <h1> nur eine <h2> folgen darf, danach eine <h3>, usw. Wenn eine Sektion mit einer <h2> beginnt, sollten alle Unterüberschriften in dieser Sektion mit <h3> ausgezeichnet werden.

To-Dos:

• Alle visuellen Überschriften durch korrekte HTML-Überschriften-Tags (<h1> bis <h6>) ersetzen.
• Sicherstellen, dass die Überschriftenhierarchie logisch korrekt ist (nur eine <h1> pro Seite, keine Ebenen überspringen).

Listen für Gruppen

Gruppen von zusammengehörigen Elementen, wie Navigationspunkte, Features im Grid, Schritte in der "How it Works"-Sektion oder FAQ-Einträge, sind nicht als semantische Listen (<ul>, <ol>, <li>) ausgezeichnet.

Ausschnitt aus dem Google Chrome DevTools-Inspektor, der die fehlende semantische Listenstruktur der Hauptnavigation der Beispiel-Website zeigt.

Stattdessen werden oft <div>-Container verwendet. Dadurch erkennen assistive Technologien nicht, dass es sich um eine Gruppe zusammengehöriger Items handelt und wie viele Items in der Gruppe sind [14].

Code der Problemstelle

Ausschnitt aus der Website ohne semantische Listenstruktur

<div class="main-nav">
  <div>Features</div>
  <div>Pricing</div>
  <div>Testimonials</div>
</div>

Code, wie er richtig wäre

Beispiel mit semantischer Listenstruktur

<nav aria-label="Hauptnavigation">
  <ul class="main-nav">
    <li><a href="#features">Features</a></li>
    <li><a href="#pricing">Pricing</a></li>
    <li><a href="#testimonials">Testimonials</a></li>
  </ul>
</nav>

Code der Problemstelle (Features Grid)

Ausschnitt aus der Website ohne semantische Listenstruktur

<div class="features-grid">
  <div class="feature-item">...</div>
  <div class="feature-item">...</div>
  <div class="feature-item">...</div>
</div>

Code, wie er richtig wäre (Features Grid - Basisstruktur):

Beispiel mit semantischer Listenstruktur

<ul class="features-grid">
  <li class="feature-item">...</li>
  <li class="feature-item">...</li>
  <li class="feature-item">...</li>
</ul>

warnung

Für nummerierte Schritte ("How it Works") wäre <ol> anstelle von <ul> semantisch korrekt [14]. Die detaillierte Struktur für Karteikarten folgt im nächsten Punkt.

To-Dos:

• Navigationsmenüs als ungeordnete Listen (<ul>) mit Listeneinträgen (<li>), die Links (<a>) enthalten, strukturieren.
• Feature-Grids, Testimonial-Listen, FAQ-Listen etc. als <ul> mit <li>-Elementen auszeichnen (siehe auch Punkt 4).
• Schritt-für-Schritt-Anleitungen ("How it Works") als geordnete Listen (<ol>) mit <li>-Elementen auszeichnen (siehe auch Punkt 4).

Karteikarten und Artikel (<article>)

Inhaltsblöcke, die wie Karteikarten gestaltet sind (z.B. die einzelnen Features, "How it Works"-Schritte, Testimonials), stellen oft in sich geschlossene Informationseinheiten dar. Diese sollten nicht nur in einer Liste (<ul>/<ol> -> <li>) gruppiert sein, sondern der Inhalt jeder einzelnen Karte sollte zusätzlich mit dem <article>-Element ausgezeichnet werden.

Ausschnitt aus dem Google Chrome DevTools-Inspektor, der die fehlende semantische Struktur für Karteikarten der Beispiel-Website zeigt.

Das würde den Nutzer von Screenreadern den notwendigen Kontext geben, indem ihnen zum Beispiel direkt mitgeteilt wird, dass die Liste zwei Elemente enthält.

Dort ist ersichtlich, dass die Nutzer sofort darüber informiert werden, dass es sich um eine Liste mit vier Elementen (Karteikarten) handelt. Wenn die Nutzer ein einzelnes Element auswählen, wird am Ende jeweils mitgeteilt, an welcher Stelle sich dieses Element in der Liste befindet und wie viele Elemente es insgesamt gibt.

hinweis

Generelle Empfehlung: Wenn es auf der Website Elemente mit vergleichbarem Inhalt gibt (z. B. Karteikarten, Bildergalerien, Karussells, Referenzen, Logos von Partnerorganisationen etc.), sollten diese in einer Liste mit <ul> oder <ol> semantisch zusammengeführt werden [14].

Das <article>-Element repräsentiert eine vollständige oder in sich geschlossene Komposition in einem Dokument, die prinzipiell unabhängig verteilbar oder wiederverwendbar ist (z.B. ein Forenbeitrag, ein Blogeintrag, ein Produkt auf einer Shopseite oder eben eine Feature-Beschreibung).

Struktur von Liste und Karten in einer Sektion

Textuelle Beschreibung des Diagramms zur Listen- und Kartenstruktur

Das Diagramm stellt eine Feature-Sektion dar. In der Sektion liegt eine ungeordnete Liste. Jedes Listenelement enthält ein Article-Element mit Bild, Überschrift und Text. So wird für Screenreader klar, dass es sich um eine Liste von einzelnen, in sich geschlossenen Informationseinheiten handelt.

Code der Problemstelle (Features Grid, fortgesetzt)

Karteikarten"
<div class="features-grid">
  <div class="feature-item">
    <div class="feature-title">Expert Instructors</div>
    <div>Learn from the best...</div>
    <img src="..." />
  </div>
</div>

Code, wie er richtig wäre (Features Grid - Basisstruktur)

Beispiel mit semantischer Struktur für Karteikarten

<ul class="features-grid">
  <li class="feature-item">
    <article aria-labelledby="feature1-title">
      <img
        src="https://source.unsplash.com/random/100x100/?lightbulb,idea"
        alt="Glühbirne als Symbol für Expertenwissen"
      />
      <h3 id="feature1-title" class="feature-title">
        Expert Instructors
      </h3>
      <div>
        Learn from the best in the industry. Our instructors are vetted
        professionals.
      </div>
    </article>
  </li>
  <li class="feature-item">
    <article aria-labelledby="feature2-title">
      <img
        src="https://source.unsplash.com/random/100x100/?books,laptop"
        alt="Bücher und Laptop als Symbol für flexibles Lernen"
      />
      <h3 id="feature2-title" class="feature-title">
        Flexible Learning
      </h3>
      <div>
        Access courses anytime, anywhere, on any device. Learn at your own
        pace.
      </div>
    </article>
  </li>
</ul>

warnung

Hinweis: Die Überschrift innerhalb des <article> sollte zur umgebenden Überschriftenhierarchie passen, hier z.B. <h3>, wenn die Sektion eine <h2> hat [12]. aria-labelledby [11] auf dem <article> kann die Zugänglichkeit verbessern, indem es klarstellt, welche Überschrift zum Artikel gehört.

To-Dos:

• Sektionen mit Karteikarten-Layout (Features, "How it Works", ggf. Testimonials) als Listen (<ul> oder <ol>) strukturieren.
• Jede einzelne Karte (z.B. .feature-item, .step-item) in ein <li>-Element einschließen.
• Den gesamten Inhalt innerhalb jeder Karte mit einem <article>-Element umschließen.
• Sicherstellen, dass jedes <article> eine passende Überschrift (z.B. <h3>, <h4>) enthält.

Interaktive Elemente (FAQ)

Interaktive Elemente, die Aktionen auslösen, wie das Aufklappen von FAQ-Antworten, sind als nicht-interaktive <div>-Elemente implementiert.

Ausschnitt aus dem Google Chrome DevTools-Inspektor, der die fehlende semantische Struktur für das FAQ-Akkordeon der Beispiel-Website zeigt.

Diese sind standardmäßig nicht per Tastatur fokussierbar oder aktivierbar und haben keine passende semantische Rolle (wie "Button") oder Zustandsinformationen (wie "aufgeklappt"/"zugeklappt") [15].

Zustandsmaschine für eine einzelne FAQ-Frage

Textuelle Beschreibung des Zustandsdiagramms für das FAQ-Akkordeon

Das Zustandsdiagramm zeigt zwei Zustände für eine einzelne FAQ-Frage: zugeklappt und aufgeklappt. Im zugeklappten Zustand ist aria-expanded auf false und die Antwort versteckt. Wenn der Button per Maus oder Tastatur ausgelöst wird, wechselt der Zustand nach aufgeklappt, aria-expanded wird true und die Antwort wird sichtbar. Ein erneutes Aktivieren klappt die Antwort wieder zu.

Code der Problemstelle

Ausschnitt aus der Website ohne semantische Struktur für FAQ

<div class="faq-item">
  <div class="faq-question">What payment methods...?</div>
  <div class="faq-answer" style="display: none;">
    ...
  </div>
</div>

Code, wie er richtig wäre

Beispiel mit semantischer Struktur für FAQ-Akkordeon

<ul class="faq-list">
  <li class="faq-item">
    <h3>
      <button
        class="faq-question"
        aria-expanded="false"
        aria-controls="faq1-answer"
        id="faq1-question"
      >
        What payment methods do you accept?
      </button>
    </h3>
    <div
      id="faq1-answer"
      class="faq-answer"
      role="region"
      aria-labelledby="faq1-question"
      hidden
    >
      We accept all major credit cards and PayPal.
    </div>
  </li>
  <li class="faq-item">
    <h3>
      <button
        class="faq-question"
        aria-expanded="false"
        aria-controls="faq2-answer"
        id="faq2-question"
      >
        Can I get a refund if I'm not satisfied?
      </button>
    </h3>
    <div
      id="faq2-answer"
      class="faq-answer"
      role="region"
      aria-labelledby="faq2-question"
      hidden
    >
      Yes, we offer a 30-day money-back guarantee...
    </div>
  </li>
</ul>

warnung

Das aria-expanded-Attribut muss per JavaScript dynamisch zwischen true und false umgeschaltet werden [15]. Das hidden-Attribut wird ebenfalls per JS hinzugefügt/entfernt. Die id des Antwort-Containers muss mit dem aria-controls-Attribut des Buttons übereinstimmen. role="region" und aria-labelledby helfen, den Antwortbereich zu identifizieren und mit der Frage zu verknüpfen [15].

To-Dos:

• FAQ-Fragen als native <button>-Elemente implementieren, idealerweise innerhalb einer passenden Überschrift (h3, h4...).
• Die gesamte FAQ-Sektion als Liste (<ul>/<li>) strukturieren.
• Für das FAQ-Akkordeon die notwendigen ARIA-Attribute (aria-expanded, aria-controls) hinzufügen und deren Zustand per JavaScript korrekt verwalten.
• Den Antwort-Containern eine passende Rolle (role="region") und eine Verknüpfung zur Frage (aria-labelledby mit der ID des Buttons) geben und sie standardmäßig verstecken (z.B. mit dem hiddenAttribut).

Formular-Beziehungen (Labels)

Den Eingabefeldern (<input>, <textarea>) im Kontaktformular fehlen zugeordnete <label>-Elemente. Dadurch ist die Beziehung zwischen der sichtbaren Beschriftung (die nur im placeholder steht) und dem Eingabefeld nicht programmatisch bestimmt [16].

Ausschnitt aus dem Google Chrome DevTools-Inspektor, der die fehlenden Labels für Eingabefelder im Kontaktformular der Beispiel-Website zeigt.

Screenreader können das Feld nicht korrekt benennen. (Detaillierte Korrektur siehe SC 3.3.2 Labels or Instructions).

Code der Problemstelle

Ausschnitt aus der Website ohne Labels für Eingabefelder

<form class="contact-form">
  <input type="text" placeholder="Your Name" />
  <input type="email" placeholder="Your Email Address" />
  <textarea placeholder="Your Message"></textarea>
  <button type="submit">Send Message</button>
</form>

Code, wie er richtig wäre

Beispiel mit Labels für Eingabefelder

<form class="contact-form">
  <label for="contact-name">Your Name</label>
  <input
    type="text"
    id="contact-name"
    name="contact-name"
    placeholder="Your Name"
    autocomplete="name"
  />

  <label for="contact-email">Your Email Address</label>
  <input
    type="email"
    id="contact-email"
    name="contact-email"
    placeholder="Your Email Address"
    autocomplete="email"
  />

  <label for="contact-message">Your Message</label>
  <textarea
    id="contact-message"
    name="contact-message"
    placeholder="Your Message"
    autocomplete="off"
  ></textarea>

  <button type="submit">Send Message</button>
</form>

tipp

Willst Du ein Beispiel von einem barrierefreien Kontaktformular sehen? Schau Dir unser barrierefreies Kontaktformular-Beispiel an.

To-Dos:

• Explizite <label>-Elemente hinzufügen und korrekt mit den Eingabefeldern über for/id verknüpfen.
• <input> Elemente mit autocomplete-Attribut versehen, um automatisches Ausfüllen der Form zu ermöglichen.

Erfüllt: Sinnvolle Abfolge – WCAG 2.2, 1.3.2 (A)

• Ist die Reihenfolge der Inhalte programmatisch bestimmbar und bleibt sie sinnvoll erhalten? (Die DOM-Reihenfolge scheint der visuellen Reihenfolge zu entsprechen)[17]

Erfüllt: Sensorische Merkmale – WCAG 2.2, 1.3.3 (A)

• Verlässt Du Dich bei Anleitungen nicht ausschließlich auf sensorische Merkmale (Farbe, Form, Größe etc.)? [18]

Erfüllt: Ausrichtung – WCAG 2.2, 1.3.4 (AA)

• Kann die Seite sowohl im Hoch- als auch im Querformat benutzt werden, ohne Funktionalität oder Inhalte zu verlieren? (Keine Einschränkungen gefunden) [19]

Nicht-erfüllt: Eingabezweck identifizieren – WCAG 2.2, 1.3.5 (AA)

• Sind alle Felder, die Nutzerdaten abfragen (Name, Adresse, E-Mail etc.), programmgesteuert als solche markiert (z. B. Autocomplete)?

Die Eingabefelder im Kontaktformular (Name, E-Mail, Nachricht) besitzen keine autocomplete-Attribute.

Zwei Felder, die im Kontaktformular der Beispiel-Website keine Autocomplete-Attribute besitzen.

Dies erschwert es Nutzern, die auf Browser-Autofill-Funktionen oder assistive Technologien angewiesen sind, das Formular effizient auszufüllen [20].

Code der Problemstelle

Ausschnitt aus der Website ohne Autocomplete-Attribute

<input type="email" placeholder="Your Email Address" />

Code, wie er richtig wäre

Beispiel mit Autocomplete-Attributen

  <label for="email">Your Email Address</label>
  <input
    type="email"
    id="email"
    name="email"
    placeholder="Your Email Address"
    autocomplete="email"
  />

  <label for="name">Your Name</label>
  <input
    type="text"
    id="name"
    name="name"
    placeholder="Your Name"
    autocomplete="name"
  />

To-Dos:

• Passende autocompleteAttribute für die Felder Name (autocomplete="name") und E-Mail (autocomplete="email") im Kontaktformular hinzufügen.

Mach Inhalte klar und gut erkennbar.

Die Lesbarkeit und Erkennbarkeit von Inhalten ist entscheidend für die Barrierefreiheit. Achte darauf, dass Texte gut lesbar sind, Farben kontrastreich und Schriftgrößen ausreichend groß sind. Auch die Bedienungselemente sollten klar erkennbar und gut voneinander unterscheidbar sein. Besonders wichtig ist es, dass Farben nicht als einzige Informationsquelle dienen, da sie für viele Nutzer nicht wahrnehmbar sind.

Erfüllt: Nutzung der Farbe – WCAG 2.2, 1.4.1 (A)

• Benutzt Du nicht ausschließlich Farbe, um Informationen (z. B. Zustände) zu vermitteln? [21]
• Wenn Farbe in Bildern verwendet wird, hast Du alternative Darstellungen (z. B. Muster, Beschriftungen) integriert?

Erfüllt: Audiosteuerung – WCAG 2.2, 1.4.2 (A)

• Spielen Audioinhalte sich nicht automatisch länger als 3 Sekunden ab oder bietest Du einen Stopp-/Pause-Knopf? (Keine Audioinhalte vorhanden) [22]

Nicht-erfüllt: Kontrast (Minimum) – WCAG 2.2, 1.4.3 (AA)

• Hat größerer Text (z. B. ab 18 pt oder 14 pt fett) einen Kontrast von mindestens 3:1? Hat normal großer Text (unter 18 pt und unter 14 pt fett) einen Kontrast von mindestens 4,5:1?

Mehrere Textelemente auf der Seite erfüllen nicht die minimalen Kontrastanforderungen nach WCAG AA [23], [24]:

• Platzhaltertext in Formularen: Der Platzhaltertext (#999) auf weißem Hintergrund (#ffffff) hat ein Kontrastverhältnis von nur 2.85:1. Dies ist zu niedrig, 4,1:1 ist erforderlich.

  

  Bemessungsergebnis des Kontrasts für den Platzhaltertext im Kontaktformular der Beispiel-Website.

• Button-Text:

  • Grüner Button (#28a745 BG, #fff Text): Kontrast 3.98:1 (zu niedrig für normalen Text, 4,1:1 ist erforderlich).

    

    Bemessungsergebnis des Kontrasts für den Text auf dem grünen Button der Beispiel-Website.

To-Dos:

• Die Farbe des Platzhaltertextes abdunkeln oder sicherstellen, dass Felder immer ein sichtbares <label> haben.
• Die Hintergrund- oder Textfarben der Buttons (grün) anpassen, sodass der Kontrast mindestens 4.5:1 beträgt (da der Text normale Größe hat).

Erfüllt: Text vergrößerbar – WCAG 2.2, 1.4.4 (AA)

• Kann Dein Text bis zu 200 % vergrößert werden, ohne dass Inhalte verloren gehen oder unbenutzbar werden? (Standard-Browser-Zoom funktioniert) [25]

Erfüllt: Bilder von Text – WCAG 2.2, 1.4.5 (AA)

• Vermeidest Du Bilder von Text, wenn der gleiche Effekt mit echtem Text erreichbar ist?

Erfüllt: Reflow – WCAG 2.2, 1.4.10 (AA)

• Bleiben alle Inhalte ohne horizontales Scrollen und ohne Informationsverlust nutzbar bis zu einer Breite von 320 CSS-Pixeln?

Leider gibt es horizontales Scrollen:

Beispiel für horizontales Scrollen auf der Beispiel-Website bei einer Breite von 320px.

Das passiert, weil die Container in den Sektionen mit einem Bild links margin: 0 auto; und gleichzeitig width: 90% hat. Eins von beiden Eigenschaften muss auf Mobile entfernt werden [26], [27].

To-Dos:

• width: 90% oder margin: 0 auto; bei der Klasse .container auf Mobile entfernen.

Nicht-erfüllt: Nicht-Text-Kontrast – WCAG 2.2, 1.4.11 (AA)

• Haben Bedienelemente (Buttons, Fokusrahmen etc.) einen Kontrast von mindestens 3:1 gegenüber dem Hintergrund?
• Enthalten Grafiken wichtige Bereiche, die einen Kontrast von mindestens 3:1 aufweisen? (Keine komplexen Grafiken, deren Verständnis vom Kontrast abhängt)

Mehrere Bedienelemente auf der Seite erfüllen nicht die Anforderungen für den Nicht-Text-Kontrast nach WCAG AA [28], [29]:

• Formularfeld-Ränder: Die Ränder der Eingabefelder (#ccc) auf weißem Hintergrund (#ffffff) haben ein Kontrastverhältnis von nur 1.61:1. Dies ist zu niedrig für die Erkennbarkeit der Komponente.

Bemessungsergebnis des Kontrasts für die Ränder der Eingabefelder im Kontaktformular der Beispiel-Website.

• Fokusindikatoren: Es gibt keine sichtbaren Fokusindikatoren für interaktive Elemente (siehe 2.4.7). Damit fehlt auch der notwendige Kontrast für den Fokusindikator selbst.

Beispiel für fehlende Fokusindikatoren auf der Beispiel-Website.

To-Dos:

• Die Farbe der Ränder von Eingabefeldern abdunkeln, um einen Kontrast von mindestens 3:1 zu erreichen (z.B. #767676).
• Sichtbare Fokusindikatoren mit ausreichendem Kontrast implementieren (siehe 2.4.7).

Erfüllt: Textabstände – WCAG 2.2, 1.4.12 (AA)

• Bleibt Deine Seite vollständig nutzbar, wenn Zeilen- und Absatzabstände, Wort- und Zeichenabstände vergrößert werden? (Keine Techniken gefunden, die dies verhindern) [30]

Erfüllt: Inhalte bei Hover oder Fokus – WCAG 2.2, 1.4.13 (AA)

• Bleiben zusätzlich eingeblendete Inhalte (z. B. Tooltips) sichtbar, bis Du sie schließt oder den Fokus entfernst? (Keine solchen Inhalte vorhanden)

Ist Deine Website für alle Nutzer bedienbar?

Der zweite Grundpfeiler der Barrierefreiheit ist die Bedienbarkeit [3].

Dieser Aspekt stellt sicher, dass alle Nutzer – unabhängig von ihren körperlichen Fähigkeiten oder der von ihnen verwendeten Technologie – problemlos durch Deine Website navigieren und alle Funktionen nutzen können.

Mach alle Funktionen per Tastatur zugänglich.

Nicht-erfüllt: Tastatur – WCAG 2.2, 2.1.1 (A)

• Ist alle Funktionalität Deiner Webseite über die Tastatur bedienbar, ohne bestimmte Zeitvorgaben?

Mehrere zentrale Funktionen und interaktive Elemente der Website sind nicht über die Tastatur bedienbar:

• Hauptnavigation
• FAQ-Akkordeon
• Slider/Marquee-Steuerung

Dies schließt Nutzer aus, die keine Maus verwenden können oder auf Tastaturnavigation angewiesen sind (z.B. Nutzer mit motorischen Einschränkungen oder Screenreader-Nutzer) [31].

Navigation nicht per Tastatur bedienbar

Die Hauptnavigationselemente sind als <div>-Elemente implementiert. <div>-Elemente sind standardmäßig nicht interaktiv und erhalten keinen Tastaturfokus. Sie können nicht mit der Tab-Taste erreicht und nicht mit Enter oder der Leertaste aktiviert werden [31].

Ausschnitt aus dem Google Chrome DevTools-Inspektor, der die fehlende semantische Struktur für die Hauptnavigation der Beispiel-Website zeigt.

Nur native interaktive Elemente wie Links (<a> mit href) und Buttons (<button>, <input type="button"> etc.) oder Elemente mit explizitem tabindex="0" [32] sind standardmäßig per Tastatur fokussierbar und bedienbar. Die Verwendung von <div>s für Navigation verhindert dies.

Code der Problemstelle:

Ausschnitt aus der Website ohne semantische Struktur für Navigation

<div class="site-header">
  <div class="container nav-container">
    <div class="logo">CoursePro</div>
    <div class="main-nav">
      <div>Features</div>
      <div>Pricing</div>
      <div>Testimonials</div>
      <div>Contact</div>
      <div>FAQ</div>
    </div>
  </div>
</div>

Code, wie er richtig wäre:

Beispiel mit semantischer Struktur für Navigation

  <header class="site-header">
    <div class="container nav-container">
      <div class="logo">CoursePro</div>
      <nav aria-label="Hauptnavigation">
        <ul class="main-nav">
          <li><a href="#features">Features</a></li>
          <li><a href="#pricing">Pricing</a></li>
          <li><a href="#testimonials">Testimonials</a></li>
          <li><a href="#contact">Contact</a></li>
          <li><a href="#faq">FAQ</a></li>
        </ul>
      </nav>
    </div>
  </header>

To-Dos:

• Die <div>-Elemente der Navigation durch echte <a>-Elemente mit sinnvollen href-Attributen ersetzen.
• Die Navigationsstruktur semantisch korrekt als Liste (<ul>/<li>) innerhalb eines <nav>-Elements aufbauen [14], [33].

FAQ nicht per Tastatur bedienbar

Die Fragen im FAQ-Bereich, die zum Ein-/Ausklappen der Antworten dienen, sind ebenfalls als <div>-Elemente implementiert (<div class="faq-question">). Wie bei der Navigation sind diese nicht per Tastatur fokussierbar oder aktivierbar [31].

Ausschnitt aus dem Google Chrome DevTools-Inspektor, der die fehlende semantische Struktur für das FAQ-Akkordeon der Beispiel-Website zeigt.

Für eine solche Aufklapp-Funktionalität (Akkordeon) ist ein <button>-Element die semantisch korrekte und barrierefreie Wahl [15]. Buttons sind per Tastatur fokussierbar und können mit Enter/Leertaste ausgelöst werden, um die zugehörige Aktion (hier: das Ein-/Ausklappen des Inhalts via JavaScript) zu starten.

Code der Problemstelle:

Ausschnitt aus der Website ohne semantische Struktur für FAQ

<div class="faq-item">
  <div class="faq-question">What payment methods do you accept?</div>
  <div class="faq-answer" style="display: none;">
    ...
  </div>
</div>

Code, wie er richtig wäre:

Beispiel mit semantischer Struktur für FAQ-Akkordeon

<ul class="faq-list">
  <li class="faq-item">
    <h3>
      <button
        class="faq-question"
        aria-expanded="false"
        aria-controls="faq1-answer"
        id="faq1-question"
      >
        What payment methods do you accept?
      </button>
    </h3>
    <div
      id="faq1-answer"
      class="faq-answer"
      role="region"
      aria-labelledby="faq1-question"
      hidden
    >
      We accept all major credit cards and PayPal.
    </div>
  </li>
</ul>

To-Dos:

• Die <div>-Elemente für FAQ-Fragen (.faq-question) durch <button>-Elemente ersetzen.
• Sicherstellen, dass diese Buttons per JavaScript den Zustand (aria-expanded) und die Sichtbarkeit der Antworten (hiddenAttribut) korrekt steuern [15].

Keine Tastatursteuerung für Slider/Marquee

Der automatisch ablaufende Bild-Slider und das Text-Marquee bieten keinerlei Steuerelemente an. Folglich gibt es auch keine per Tastatur bedienbaren Steuerelemente, um diese dynamischen Inhalte zu kontrollieren (z.B. anzuhalten, fortzusetzen, manuell durchzublättern) [31], [34].

Ausschnitt aus dem Google Chrome DevTools-Inspektor, der die fehlenden Steuerungselemente für den Sliderder Beispiel-Website zeigt.

Visuelle Darstellung des Marquees ohne Steuerungselemente.

Jede Funktionalität, die über die Maus oder automatisch ausgelöst wird, muss auch eine äquivalente Tastaturbedienung haben. Für Slider und Marquees bedeutet das in der Regel Buttons zum Pausieren/Starten der Animation und ggf. zur manuellen Navigation. Diese Buttons müssen als <button> implementiert werden, um Tastaturbedienbarkeit sicherzustellen.

Code der Problemstelle

Ausschnitt aus der Website ohne Tastatursteuerung für Slider und Marquee

<div class="slider-section">
<div class="slides-wrapper">...</div>
</div>

<div class="marquee-section">
<div class="marquee-content">...</div>
</div>

Code, wie er richtig wäre

Beispiel mit Tastatursteuerung für Slider und Marquee

<section
class="slider-section"
aria-roledescription="carousel"
aria-labelledby="slider-title"
>
<h2 id="slider-title" class="visually-hidden">Aktuelle Highlights</h2>
<div class="slider-controls">
<button class="slider-control pause" aria-label="Animation anhalten">
  Pause
</button>
<button class="slider-control prev" aria-label="Vorherige Folie">‹</button>
<button class="slider-control next" aria-label="Nächste Folie">›</button>
</div>
<div class="slides-wrapper" aria-live="off">...</div>
</section>

<section class="marquee-section" aria-labelledby="marquee-title">
<h2 id="marquee-title" class="visually-hidden">Laufband</h2>
<button class="marquee-control pause" aria-label="Laufband anhalten">
Pause
</button>
<div class="marquee-content-wrapper" style="overflow:hidden;">
<div class="marquee-content">...</div>
</div>
</section>

warnung

Die Funktionalität (z.B. das Pausieren via Klick/Enter auf den Button) muss per JavaScript implementiert werden [35]. aria-label ist wichtig, wenn der Button keinen sichtbaren Text hat oder der Text allein nicht eindeutig ist. aria-live="off" im Slider verhindert, dass Screenreader ständig über Folienwechsel informiert werden, was störend sein kann [34], [36].

tipp

Willst Du mehr über die barrierefreie Implementierung von Karussells/Slidern erfahren? Schau Dir unser Tutorial zur barrierefreien Karussell-Implementierung an.

To-Dos:

• Füge explizite Steuerelemente (mindestens Play/Pause) für den Slider und das Marquee hinzu. Implementiere diese als <button>-Elemente.
• Stelle sicher, dass diese Buttons per Tastatur erreichbar sind und ihre Funktion (Animation anhalten/starten) per Enter/Leertaste ausgelöst werden kann (via JavaScript-Event-Listener).
• Für den Slider zusätzlich Vor-/Zurück-Buttons (<button>) implementieren, um die manuelle Navigation per Tastatur zu ermöglichen.

Erfüllt: Keine Tastaturfalle – WCAG 2.2, 2.1.2 (A)

• Gibt es keine Tastaturfalle? Kannst Du den Fokus jederzeit weiterbewegen oder verlassen? (Keine Falle erkennbar) [37]

Erfüllt: Zeichen-Tastenkombinationen – WCAG 2.2, 2.1.4 (A)

• Falls Du Zeichen-Tastenkürzel (Buchstaben/Ziffern) nutzt, kann man sie deaktivieren oder umbelegen, oder wirken sie nur, wenn das Element Fokus hat? (Keine solchen Kürzel implementiert)

Gib Nutzern genug Zeit, um Inhalte zu lesen und zu nutzen.

Erfüllt: Zeitbegrenzung anpassbar – WCAG 2.2, 2.2.1 (A)

• Kannst Du Sitzungszeitlimits abschalten oder verlängern (mindestens das 10-Fache)? (Keine Zeitlimits implementiert) [38]
• Steuert ein Skript das Zeitlimit? Kannst Du es abschalten oder verlängern? (Keine Zeitlimits implementiert)
• Hast Du bei zeitlich begrenztem Lesen (z. B. Lauftext) eine Pause- oder Stopp-Funktion?

Die Marquee bietet keine Möglichkeit, die automatische Bewegung zu pausieren oder zu stoppen. Dies kann für Nutzer mit kognitiven Einschränkungen oder Aufmerksamkeitsstörungen problematisch sein [35].

To-Dos:

• Für das Marquee eine Pause/Play-Funktion anbieten oder die Animation standardmäßig stoppen und nur auf Nutzeraktion starten lassen.
• Zusätzlich: Die CSS-Media-Query prefers-reduced-motion respektieren und Animationen für Nutzer deaktivieren, die dies in ihrem System eingestellt haben.

Nicht-erfüllt: Anhalten, Stoppen, Ausblenden – WCAG 2.2, 2.2.2 (A)

• Kannst Du bewegte, blinkende oder automatisch aktualisierende Inhalte stoppen, pausieren oder ausblenden?

Mehrere automatisch ablaufende Inhalte auf der Seite bieten keine Möglichkeit, die Bewegung zu stoppen oder zu pausieren [35]. Dies betrifft insbesondere:

• Slider: Der Image-Slider im oberen Bereich der Seite läuft automatisch und ununterbrochen, ohne dass der Nutzer eine Möglichkeit hat, ihn anzuhalten, zu pausieren oder die Folien manuell zu wechseln [34].
• Marquee: Das Marquee mit Text ("Trusted By Thousands...") läuft ebenfalls automatisch und endlos per CSS-Animation, ohne Steuerungsmöglichkeit.

Steuerung von bewegten Inhalten wie Slider und Marquee

Textuelle Beschreibung des Diagramms zur Steuerung von bewegten Inhalten

Das Diagramm zeigt, dass sowohl der Slider als auch das Marquee mindestens einen Play-/Pause-Button brauchen. Beim Slider kommen zusätzlich Vor- und Zurück-Buttons hinzu, um Folien gezielt zu wechseln. Außerdem wird dargestellt, dass bei aktivierter System-Einstellung für reduzierte Bewegung Animationen standardmäßig ausgeschaltet sein sollten.

Diese automatisch bewegten Inhalte können für Nutzer mit kognitiven Einschränkungen, Aufmerksamkeitsstörungen oder vestibulären Störungen sehr störend oder sogar schädlich sein.

To-Dos:

• Für den Slider Steuerelemente hinzufügen (z.B. Pause/Play-Button, Vor/Zurück-Pfeile, Folienindikatoren), die auch per Tastatur bedienbar sind.
• Für das Marquee ebenfalls eine Pause/Play-Funktion anbieten oder die Animation standardmäßig stoppen und nur auf Nutzeraktion starten lassen.
• Zusätzlich: Die CSS-Media-Query prefers-reduced-motion respektieren und Animationen für Nutzer deaktivieren, die dies in ihrem System eingestellt haben.

Vermeide Inhalte, die Anfälle oder körperliche Reaktionen auslösen können.

Erfüllt: Drei Blitze oder unterhalb der Schwelle – WCAG 2.2, 2.3.1 (A)

• Enthält Deine Website keine blitzenden oder flackernden Inhalte, die Anfälle auslösen könnten? [39]

Mach Deine Website für alle Nutzer navigierbar.

Es gibt nicht nur die Maus und den Touchscreen. Viele Nutzer verwenden Tastaturen, Screenreader oder andere Hilfsmittel, um sich durch Deine Website zu bewegen.

Nicht-erfüllt: Blöcke überspringen – WCAG 2.2, 2.4.1 (A)

• Kannst Du wiederkehrende Inhalte überspringen, z. B. mit einem „Zum Inhalt springen“-Link?

Der Website fehlt ein Mechanismus, um wiederkehrende Blöcke wie die Hauptnavigation zu überspringen. Tastaturnutzer müssen bei jedem Seitenaufruf durch alle Navigationselemente tabben, bevor sie zum Hauptinhalt gelangen [40].

Fokus-Fluss für Tastaturnutzer mit Skip-Link und Navigation

Textuelle Beschreibung des Fokus-Flusses für Tastaturnutzer

Das Diagramm zeigt, wie sich der Tastaturfokus über die Seite bewegt. Der erste Tab erreicht den Skip-Link. Wenn dieser ausgelöst wird, springt der Fokus direkt zum Main-Bereich. Alternativ kann der Nutzer weiter tabben und zuerst das Logo und dann die Navigationslinks fokussieren. Danach folgen die Inhalte und Buttons im Hauptbereich.

Beispiel für einen 'Zum Inhalt springen'-Link auf der Website.

Der erste versteckte Navigationsbereich dient als „Skip Link“, um Nutzern – insbesondere denen, die assistive Technologien verwenden – den direkten Sprung zum Hauptinhalt zu ermöglichen. Durch die Verwendung von aria-label wird der Zweck des Links klar kommuniziert.

HTML

Beispiel für einen 'Zum Inhalt springen'-Link mit Sprungzielbereich

<nav aria-label="Sprungzielbereich">
  <ul class="stmc-links__wrapper">
    <li>
      <a
        href="#skip-link-target"
        title="Zum Hauptinhalt springen"
        class="stmc-link"
        >Zum Hauptinhalt springen
      </a>
    </li>
  </ul>
</nav>

CSS

CSS für den 'Zum Inhalt springen'-Link

.stmc-link,
.stmc-link:visited {
  position: absolute;
  top: 0;
  left: 50%;
  transform: translate(-50%, -100%);

  z-index: -1;
  opacity: 0;

  &:focus {
    top: 0;
    opacity: 1;

    transform: translate(-50%, 0);
    z-index: 99999999;
  }
}

.stmc-links__wrapper {
  position: absolute;

  z-index: -1;
  inset: 0;
  opacity: 0;

  &:focus-within {
    opacity: 1;
    z-index: 9999999;
  }
}

Alternativ kannst Du einfach einen Link als erstes Element auf der Seite platzieren [40]:

HTML

Einfacher 'Zum Inhalt springen'-Link

<a href="#skip-link-target" title="Zum Hauptinhalt springen" class="stmc-link">
  Zum Hauptinhalt springen
</a>

To‑Dos:

• Sicherstellen, dass der Link auch bei Tastaturnutzung sichtbar und gut erkennbar ist.
• Überprüfen, ob der Sprungzielbereich (id="skip-link-target") korrekt definiert ist und unmittelbar an den Hauptinhalt anknüpft.

Erfüllt: Seiten-Titel – WCAG 2.2, 2.4.2 (A)

• Hat jede Seite einen aussagekräftigen Titel, der Thema oder Zweck vermittelt? (Der <title> "Inaccessible Course Platform - Demo v2" ist vorhanden) [41]

Erfüllt: Fokusreihenfolge – WCAG 2.2, 2.4.3 (A)

• Ist die Fokus-Reihenfolge logisch, sodass die Bedeutung und Bedienbarkeit nicht beeinträchtigt werden? (Innerhalb der fokussierbaren Elemente scheint die Reihenfolge logisch) [42]

Nicht-erfüllt: Linkzweck (im Kontext) – WCAG 2.2, 2.4.4 (A)

• Ist der Zweck jedes Links über den sichtbaren Linktext oder den programmatisch definierten Kontext eindeutig?

Der Zweck von Elementen, die zur Navigation dienen sollen, ist oft nicht programmatisch bestimmbar oder wird durch die Verwendung semantisch falscher Elemente verschleiert. Dies hindert Nutzer assistiver Technologien daran, Navigationsoptionen korrekt zu identifizieren und zu verstehen, wohin ein Klick führt [43].

Navigationszweck nicht programmatisch bestimmt (Divs statt Links)

Die Hauptnavigation und die Links im Footer verwenden <div>- bzw. <span>-Elemente anstelle von echten Links (<a>). Obwohl der sichtbare Text (z.B. "Features", "Privacy Policy") für sehende Nutzer verständlich sein mag, fehlt diesen Elementen die semantische Rolle eines Links. Assistive Technologien erkennen sie nicht als Navigationselemente, und der Zweck ("zu einer anderen Seite/Sektion navigieren") ist programmatisch nicht ersichtlich.

Screenshot der Navigation-Links, die als `<div>`-Elemente implementiert sind.

Screenshot der Footer-Links, die als `<span>`-Elemente implementiert sind.

Code der Problemstelle (Navigation)

Ausschnitt aus der Website mit nicht-semantischer Navigation

<div class="main-nav">
  <div>Features</div>
  <div>Pricing</div>
</div>

Code der Problemstelle (Footer)

Footer-Links" ```html
<div class="footer-links">
  <span>Privacy Policy</span> <span>Terms of Service</span>
</div>

Nur ein korrekt implementiertes <a>-Element mit einem href-Attribut signalisiert eindeutig die Rolle und den Zweck eines Hyperlinks [44]. Der Linktext selbst sollte dann das Ziel oder die Funktion des Links beschreiben [43].

Code, wie er richtig wäre (Navigation)

Beispiel für semantisch korrekte Navigation

<nav aria-label="Hauptnavigation">
  <ul class="main-nav">
    <li>
      <a href="#features">Features</a>
    </li>
    <li>
      <a href="#pricing">Pricing</a>
    </li>
    <li>
      <a href="#testimonials">Testimonials</a>
    </li>
  </ul>
</nav>

Code, wie er richtig wäre (Footer)

Beispiel für semantisch korrekte Footer-Links

<nav aria-label="Rechtliche Hinweise und Service">
  <ul class="footer-links">
    <li>
      <a href="/privacy-policy">Privacy Policy</a>
    </li>
    <li>
      <a href="/terms-of-service">Terms of Service</a>
    </li>
  </ul>
</nav>

warnung

Die href-Attribute müssen auf gültige Ziele verweisen. Die Struktur als Liste innerhalb von <nav> verbessert zusätzlich die Semantik, siehe 1.3.1.

To-Dos:

• Alle Elemente, die zur Navigation dienen (Header-Navigation, Footer-Links), als korrekte <a>-Elemente mit gültigem hrefAttribut und aussagekräftigem Linktext implementieren.
• Sicherstellen, dass diese Links in einer semantisch korrekten Struktur (z.B. nav > ul > li > a) eingebettet sind.

Buttons für reine Navigation verwendet (Buttons statt Links)

An mehreren Stellen werden <button>-Elemente für Call-to-Actions (CTAs) verwendet, deren primäre Funktion jedoch die Navigation zu einer anderen Seite oder einem anderen Abschnitt ist (z.B. "Get Started Today", "Explore Courses").

Screenshot der Hero-CTA, die als `<button>` implementiert ist.

Screenshot eines Sektions-CTA, der als `<button>` implementiert ist.

Screenshot eines weiteren Sektions-CTA, der als `<button>` implementiert ist.

Semantisch ist ein <button> für Aktionen innerhalb der aktuellen Seite vorgesehen (Formular absenden, Zustand ändern, Dialog öffnen). Für reine Navigation ist ein Link (<a>) das korrekte Element [44]. Die Verwendung eines Buttons vermittelt assistiven Technologien eine falsche Erwartungshaltung über die auszuführende Aktion.

Obwohl der Text des Buttons klar sein mag, signalisiert die role="button" eine Aktion, keine Navigation. Dies kann verwirrend sein. Wenn der Klick den Nutzer zu einer anderen URL oder einem Anker auf der Seite führt, sollte ein <a>-Element verwendet werden, das entsprechend gestylt wird, um wie ein Button auszusehen.

Code der Problemstelle:

Ausschnitt aus der Website mit Buttons für Navigation

<button class="cta-button">Get Started Today</button>
<button class="section-cta-button">Explore Courses</button>

Code, wie er richtig wäre:

Beispiel für semantisch korrekte Links für Navigation

<a href="/signup" class="cta-button button-like">
  Get Started Today
</a>
<a href="/courses" class="section-cta-button button-like">
  Explore Courses
</a>

warnung

Eine CSS-Klasse wie .button-like kann verwendet werden, um das Aussehen eines Buttons auf das <a>-Element anzuwenden. Der Linktext beschreibt klar die Aktion/das Ziel [43].

To-Dos:

• Überprüfen aller <button>-Elemente auf der Website.
• Buttons, deren Hauptfunktion die Navigation zu einer anderen URL oder einem Anker ist, durch <a>-Elemente mit entsprechendem hrefAttribut ersetzen.
• Sicherstellen, dass der Linktext den Zweck oder das Ziel des Links klar beschreibt.
• Das visuelle Erscheinungsbild von Buttons bei Bedarf über CSS auf die <a>-Elemente übertragen.

Nicht-erfüllt: Mehrere Wege – WCAG 2.2, 2.4.5 (AA)

• Bietest Du mehrere Navigationswege an (z. B. Suche, Sitemap, Menü), um Seiten zu finden?

Die Website bietet nur eine primäre Navigation (im Header, die zudem unzugänglich ist) und eine rudimentäre Link-Sammlung im Footer (die ebenfalls unzugänglich ist). Es gibt keine Sitemap und keine Suchfunktion. Damit fehlt es an alternativen Wegen, um Inhalte zu finden, insbesondere wenn die Hauptnavigation nicht nutzbar ist [45], [46], [47].

To-Dos:

• Mindestens einen weiteren Weg zur Navigation bereitstellen. Möglichkeiten:
  • Eine Sitemap-Seite erstellen und verlinken.
  • Eine Suchfunktion implementieren.
  • Sicherstellen, dass die Hauptnavigation und die Footer-Navigation alle wichtigen Seiten konsistent verlinken.

Nicht-erfüllt: Überschriften und Labels – WCAG 2.2, 2.4.6 (AA)

• Sind Überschriften und Beschriftungen aussagekräftig und beschreiben Thema bzw. Zweck?

Mehrere Überschriften und Formularbeschriftungen auf der Seite sind nicht semantisch korrekt implementiert, was die Navigation und das Verständnis für Nutzer assistiver Technologien erschwert [48], [49]. Insbesondere betrifft dies:

• Überschriften: Wie früher beschrieben, werden keine echten Überschriften-Tags (<h1><h6>) verwendet. Gestylte <div>s erfüllen nicht den Zweck, die Seitenstruktur programmatisch zu gliedern [12].
• Labels: Wie früher beschrieben, fehlen den Formularfeldern im Kontaktbereich explizite <label>-Elemente. Placeholder sind keine ausreichenden Beschriftungen [16].

To-Dos:

• Echte, hierarchisch korrekte Überschriften (<h1><h6>) für alle Sektionen und Unterbereiche verwenden.
• Explizite, korrekt verknüpfte <label>-Elemente für alle Formularfelder bereitstellen.

Nicht-erfüllt: Fokus sichtbar – WCAG 2.2, 2.4.7 (AA)

• Ist der Tastaturfokus sichtbar, wenn Du durch die Seite navigierst?

Im CSS der Seite fehlen explizite :focus-visible-Stile für alle interaktiven Elemente [50]. Das betrifft:

• Die <div>-Elemente in der Navigation (die ohnehin nicht fokussierbar sind).
• Die <button>-Elemente (Hero CTA, Form Submit, Sektions-CTAs).
• Die <input> und <textarea>-Felder im Kontaktformular.
• Die <div>-Elemente der FAQ-Fragen (die ebenfalls nicht fokussierbar sind).

Ohne sichtbaren Fokusindikator wissen Tastaturnutzer nicht, welches Element gerade aktiv ist, was die Bedienung extrem erschwert oder unmöglich macht [50].

To-Dos:

• Deutlich sichtbare :focus Stile für alle interaktiven Elemente (Links, Buttons, Formularfelder, etc.) im CSS definieren. Der Fokusindikator muss sich klar vom Hintergrund und vom Element selbst abheben (siehe auch 1.4.11 Non-text Contrast). Ein einfacher outline ist oft ausreichend, z.B.:

Beispiel für Fokus-Stile im CSS

button:focus-visible,
input:focus-visible,
textarea:focus-visible,
a:focus-visible,
[tabindex='0']:focus-visible {
  outline: 2px solid blue; /* Beispiel */
  outline-offset: 2px;
}

Erfüllt: Fokus nicht verdeckt (Minimum) – WCAG 2.2, 2.4.11 (AA)

• Wird der Fokusindikator nicht von anderen Inhalten verdeckt, wenn ein Element den Fokus erhält? (Keine sticky Header/Footer oder nicht-modale Dialoge vorhanden, die den Fokus verdecken würden)

Mach Deine Website für alle Eingabemethoden zugänglich.

Erfüllt: Zeigergesten – WCAG 2.2, 2.5.1 (A)

• Sind alle Mehrfinger- oder Pfad-Gesten (z. B. Wischen, Pinch-To-Zoom) auch einfach per Einzelzeiger bedienbar? (Keine solchen Gesten erforderlich)

Erfüllt: Zeiger-Abbruch – WCAG 2.2, 2.5.2 (A)

• Wird eine Aktion erst bei Zeigerhebung (MouseUp / TouchEnd) abgeschlossen oder gibt es eine Rückgängig-/AbbrechenOption? (Standardverhalten von Buttons/Inputs) [51]

Nicht-erfüllt: Label im Namen – WCAG 2.2, 2.5.3 (A)

• Stimmt der sichtbare Text im Label mit dem zugänglichen Namen überein?

Da die Felder keine sichtbaren <label>-Elemente haben, kann dieses Kriterium nicht erfüllt werden. Der zugängliche Name (der durch ein Label bereitgestellt würde) fehlt [16], [52]. Placeholder zählen nicht als Label.

To-Dos:

• Sichtbare <label>-Elemente für alle Formularfelder hinzufügen (siehe 3.3.2). Sicherstellen, dass der Text im Label den Zweck des Feldes klar beschreibt.

Erfüllt: Bewegungsaktivierung – WCAG 2.2, 2.5.4 (A)

• Können Gerätebewegungen (z. B. Schütteln) auch über ein Bedienelement ausgeführt werden und deaktivierst Du ungewollte Auslöser? (Keine bewegungsaktivierten Funktionen) [53]

Erfüllt: Ziehbewegungen – WCAG 2.2, 2.5.7 (AA)

• Kann die Funktion, die ein Ziehen (Drag & Drop) erfordert, auch ohne Ziehen ausgeführt werden? (Kein Drag & Drop vorhanden)

Erfüllt: Zielgröße (Minimum) – WCAG 2.2, 2.5.8 (AA)

• Sind alle klick-/touchbaren Flächen mindestens 24x24 CSS-Pixel groß oder entsprechend gut getrennt? (Visuell scheinen die Buttons und Links (wenn sie welche wären) ausreichend groß oder weit genug voneinander entfernt)

Ist Deine Website verständlich für alle Nutzer?

Deine Website sollte so gestaltet sein, dass alle Nutzer den Inhalt und die Bedienung verstehen können [3]. Dazu gehören klare Sprache, einfache Navigation und verständliche Interaktionen. Achte besonders darauf, dass Screenreader die Sprache korrekt aussprechen und die Bedienung logisch ist.

Mach Deine Website für alle Nutzer lesbar.

Erfüllt: Sprache der Seite – WCAG 2.2, 3.1.1 (A)

• Ist die Standardsprache der Seite korrekt ausgezeichnet (z. B. lang="de")? (lang="en" ist im HTML gesetzt, was der Sprache des Inhalts entspricht) [54]

Erfüllt: Sprache von Teilen – WCAG 2.2, 3.1.2 (AA)

• Kennzeichnest Du Sprachwechsel im Text (z. B. Zitate, Fremdwörter, Kundenrezensionen etc.) mit langAttributen? (Keine offensichtlichen Sprachwechsel im Demo-Inhalt) [55]

Mach Deine Website für alle Nutzer vorhersehbar.

Erfüllt: Bei Fokus – WCAG 2.2, 3.2.1 (A)

• Verändert sich nicht der Kontext automatisch, sobald ein Element den Fokus erhält? [56]

Erfüllt: Bei Eingabe – WCAG 2.2, 3.2.2 (A)

• Verändert sich der Kontext nicht automatisch, sobald ein Wert in einem Formular-Element geändert wird? [57]

Erfüllt: Konsistente Navigation – WCAG 2.2, 3.2.3 (AA)

• Sind Navigationselemente, die auf mehreren Seiten wiederholt werden, stets in gleicher Reihenfolge angeordnet? (Da es nur eine Seite ist, ist dies trivialerweise erfüllt) [58]

Erfüllt: Konsistente Identifizierung – WCAG 2.2, 3.2.4 (AA)

• Sind gleich funktionierende Elemente konsistent beschriftet und gekennzeichnet (z. B. gleiche Icons, Farben)? (Buttons haben konsistentes Styling) [59]

Nicht-erfüllt: Konsistente Hilfe – WCAG 2.2, 3.2.6 (A)

• Werden auf allen Seiten Hilfefunktionen (Kontakt, FAQ, Chat etc.) an derselben Stelle angeboten?

Die Website bietet zwar eine FAQ-Sektion und eine Kontakt-Sektion, aber es gibt keinen konsistenten, leicht auffindbaren Mechanismus für Hilfe, der auf jeder (hypothetischen) Seite verfügbar wäre (z.B. ein immer präsenter "Hilfe"-Link im Header oder Footer). Die Links zur FAQ und zum Kontakt im Header sind zudem unzugänglich (siehe 2.1.1, 1.3.1).

To-Dos:

• Einen konsistenten Hilfe-Mechanismus auf allen Seiten bereitstellen. Dies könnte ein Link zu einer Hilfe-Seite, Kontaktinformationen oder eine FAQ-Seite sein, der immer an der gleichen Stelle (z.B. im Header oder Footer) platziert ist und barrierefrei zugänglich ist [60], [61].

Hilf Nutzern, Fehler zu vermeiden und zu korrigieren.

Nicht-erfüllt: Fehlererkennung – WCAG 2.2, 3.3.1 (A)

• Werden Eingabefehler automatisch erkannt und das fehlerhafte Element dem Nutzer mitgeteilt sowie der Fehler textuell beschrieben?

Der aktuelle Code des Kontaktformulars enthält keine Mechanismen zur Fehlererkennung oder -kommunikation. Wenn ein Nutzer das Formular mit Fehlern (z.B. leere Pflichtfelder, ungültiges E-Mail-Format) absendet, ist nicht sichergestellt, dass:

1. Der Fehler überhaupt erkannt wird (Validierung fehlt).
2. Das fehlerhafte Feld programmatisch als solches markiert wird (z.B. für Screenreader) [62].
3. Eine klare textuelle Beschreibung des Fehlers bereitgestellt und mit dem Feld verknüpft wird [63], [64].

Dies führt dazu, dass Nutzer, insbesondere solche, die auf assistive Technologien angewiesen sind, möglicherweise nicht bemerken, dass ein Fehler aufgetreten ist, welches Feld betroffen ist oder wie der Fehler behoben werden kann.

Ablauf der barrierefreien Fehlerbehandlung im Kontaktformular

Textuelle Beschreibung des Diagramms zum Fehlererkennungsablauf im Formular

Das Diagramm zeigt den Ablauf bei der Formularabsendung. Wenn die Validierung erfolgreich ist, wird das Formular gesendet. Wenn Fehler vorhanden sind, werden die betroffenen Felder markiert, aria-invalid gesetzt, textuelle Fehlermeldungen erzeugt und über aria-describedby mit den Feldern verknüpft. Ein Container mit role-alert sorgt dafür, dass Screenreader die Meldung automatisch ausgeben.

tipp

Ein Beispiel für eine vollständige Fehlerbehandlung findest Du in unserem Tutorial zur barrierefreien Formularen.

Problembeschreibung am Beispiel eines Formularfeldes

Ein typisches Eingabefeld im aktuellen Code bietet keine Struktur, um Fehler anzuzeigen oder programmatisch zu kommunizieren.

Um WCAG 3.3.1 zu erfüllen, muss nach einer Validierung (client- oder serverseitig) bei einem Fehler das betroffene Eingabefeld klar identifiziert und der Fehler beschrieben werden. Dies geschieht typischerweise durch:

• Visuelle Hervorhebung (z.B. roter Rahmen).
• Setzen des Attributs aria-invalid="true" auf das fehlerhafte <input>-Element [62]. Dies signalisiert assistiven Technologien den Fehlerzustand.
• Anzeige einer textuellen Fehlermeldung in unmittelbarer Nähe des Feldes.
• Verknüpfung des <input>-Elements mit der Fehlermeldung über das aria-describedbyAttribut [65]. Der Wert des Attributs muss der id des Elements entsprechen, das die Fehlermeldung enthält. Screenreader lesen dann typischerweise zuerst das Label, dann den Typ des Feldes und anschließend den durch aria-describedby verknüpften Fehlertext vor.

Problemstelle

Ausschnitt aus dem Kontaktformular ohne Fehlererkennung

<div>
  <input
    type="email"
    id="contact-email"
    name="contact-email"
    placeholder="Your Email Address"
  />
</div>

Code, wie er richtig wäre:

Beispiel für ein Eingabefeld mit Fehlererkennung

<div class="form-group has-error">
  <label for="contact-email">Your Email Address</label>
  <input
    type="email"
    id="contact-email"
    name="contact-email"
    placeholder="Your Email Address"
    required
    aria-invalid="true"
    aria-describedby="email-error-message"
  />
  <div id="email-error-message" class="error-message" role="alert">
    Bitte geben Sie Ihre E-Mail-Adresse im folgenden Format ein:
    beispiel@email.com. Dieses Feld ist erforderlich.
  </div>
</div>

warnung

required ist ein HTML5-Attribut für Pflichtfelder. Das role="alert" auf der Fehlermeldung sorgt dafür, dass die Meldung von Screenreadern sofort angesagt wird, was technisch eher unter SC 4.1.3 [66] fällt, aber hier für eine vollständige Lösung sinnvoll ist. Die eigentliche Validierungslogik (JavaScript oder serverseitig) muss implementiert werden, um aria-invalid zu setzen und die Fehlermeldung anzuzeigen/auszublenden.

To-Dos:

• Implementiere eine clientseitige und/oder serverseitige Validierungslogik für das Kontaktformular (z.B. Prüfung auf leere Pflichtfelder, korrektes E-Mail-Format).
• Wenn ein Fehler auftritt: Setze dynamisch (z.B. per JavaScript) das Attribut aria-invalid="true" auf das fehlerhafte <input> oder <textarea>-Element.
• Zeige eine klare, textuelle Fehlermeldung in unmittelbarer Nähe des fehlerhaften Feldes an. Gib diesem Fehlermeldungs-Element eine eindeutige id.
• Füge dem fehlerhaften <input>/<textarea>-Element das Attribut aria-describedby hinzu, dessen Wert auf die id der zugehörigen Fehlermeldung verweist.
• Stelle sicher, dass der Fehler auch visuell deutlich erkennbar ist (z.B. durch Farbe, Icon, Hervorhebung des Feldes und/oder der Fehlermeldung).
• Entferne aria-invalid="true" und aria-describedby (oder blende die Fehlermeldung aus), sobald der Fehler korrigiert wurde.

Nicht-erfüllt: Labels oder Anweisungen – WCAG 2.2, 3.3.2 (A)

• Haben alle Steuerelemente, die eine Nutzereingabe erfordern, zugeordnete Beschriftungen (Labels) oder Anweisungen?

Die Eingabefelder (<input>, <textarea>) im Kontaktformular besitzen keine expliziten, programmgesteuert verknüpften <label>-Elemente. Stattdessen werden placeholder-Attribute verwendet, um den Zweck der Felder anzudeuten. Dies ist aus mehreren Gründen problematisch und nicht ausreichend [16], [67]:

1. Flüchtigkeit: Placeholder-Text verschwindet, sobald der Nutzer mit der Eingabe beginnt, wodurch die Information über den erwarteten Inhalt verloren geht.
2. Erkennung durch Assistive Technologien: Placeholder werden nicht von allen Browser-/Screenreader-Kombinationen zuverlässig als zugänglicher Name (Accessible Name) für das Feld erkannt [67]. Der zugängliche Name ist jedoch entscheidend, damit Screenreader-Nutzer wissen, welches Feld sie gerade bearbeiten.
3. Kontrast: Placeholder-Text hat oft einen geringen Farbkontrast zum Hintergrund, was die Lesbarkeit für Nutzer mit Sehbeeinträchtigungen erschwert.
4. Zweck: Placeholder sind primär für kurze Hinweise oder Formatbeispiele gedacht, nicht als Ersatz für eine permanente Beschriftung.

Ohne korrekte Labels fehlt die essenzielle programmatische Verknüpfung zwischen der Beschreibung und dem Eingabefeld [16].

Problembeschreibung und Code

Der aktuelle Code zeigt Eingabefelder ohne zugehörige <label>-Elemente.

Die Standardmethode und robusteste Lösung zur Bereitstellung von Beschriftungen für Formularfelder ist die Verwendung des <label>-Elements. Durch die Verknüpfung des for-Attributs des Labels mit der id des entsprechenden Eingabeelements (<input>, <textarea>, <select>) wird eine eindeutige programmatische Verbindung hergestellt [16]. Diese Verbindung ermöglicht es assistiven Technologien, das Label korrekt vorzulesen, wenn das Feld den Fokus erhält. Zusätzlich profitieren Mausnutzer davon, da ein Klick auf das Label den Fokus in das zugehörige Eingabefeld setzt.

Problemstelle

Ausschnitt aus dem Kontaktformular ohne Labels

<div class="contact-form">
  <div>
    <input type="text" placeholder="Your Name" />
  </div>
  <div>
    <input type="email" placeholder="Your Email Address" />
  </div>
  <div>
    <textarea rows="6" placeholder="Your Message"></textarea>
  </div>
  <div>
    <button class="submit-button" type="button">Send Message</button>
  </div>
</div>

Code, wie er richtig wäre:

Beispiel für ein Kontaktformular mit Labels

<div class="contact-form">
  <div class="form-group">
    <label for="contact-name">Your Name</label>
    <input
      type="text"
      id="contact-name"
      name="contact-name"
      placeholder="z.B. Max Mustermann"
      required
      autocomplete="name"
    />
  </div>

  <div class="form-group">
    <label for="contact-email">Your Email Address</label>
    <input
      type="email"
      id="contact-email"
      name="contact-email"
      placeholder="z.B. [entfernte E-Mail-Adresse]"
      required
      autocomplete="email"
    />
  </div>
  <div class="form-group">
    <label for="contact-message">Your Message</label>
    <textarea
      id="contact-message"
      name="contact-message"
      rows="6"
      placeholder="Was können wir für Sie tun?"
      required
    ></textarea>
  </div>
  <div>
    <button class="submit-button" type="submit">Send Message</button>
  </div>
</div>

warnung

Hier wurden zusätzlich name-Attribute für die Formularübermittlung, required für Pflichtfelder und autocomplete gemäß SC 1.3.5 [68] ergänzt. Der Placeholder kann weiterhin als zusätzlicher Hinweis dienen, ersetzt aber nicht das Label.

To-Dos:

• Füge für jedes <input> und <textarea>-Element im Kontaktformular ein sichtbares <label>-Element hinzu.
• Gib jedem Eingabefeld eine eindeutige id.
• Setze das forAttribut jedes <label>-Elements auf die id des zugehörigen Eingabefeldes, um die programmatische Verknüpfung herzustellen [16].
• Falls zusätzliche Anweisungen notwendig sind (z.B. über erforderliche Formate oder Längen), stelle diese als sichtbaren Text in der Nähe des Feldes bereit (z.B. unterhalb des Labels oder Inputs) und verknüpfe sie ggf. zusätzlich über aria-describedby (siehe auch SC 3.3.1 [69] und 3.3.3). Verwende Placeholder nur für kurze, nicht-essentielle Hinweise oder Beispiele.

Nicht-erfüllt: Fehler-Vorschlag – WCAG 2.2, 3.3.3 (AA)

• Bei leeren Pflichtfeldern, bietest Du einen Hinweis (z. B. „Dieses Feld darf nicht leer sein“)? (Fehlererkennung fehlt generell, daher Annahme: Nein)
• Wenn ein bestimmtes Datenformat gefordert wird, schlägst Du eine Korrektur vor?
• Wenn nur bestimmte Werte zulässig sind (z. B. eine Auswahlliste), gibst Du einen entsprechenden Hinweis oder Vorschlag? (Keine solchen Felder vorhanden)

Da keine Fehlererkennung implementiert ist (siehe 3.3.1 [69]), werden auch keine Korrekturvorschläge gemacht [70]. Wenn ein Nutzer beispielsweise eine ungültige E-Mail-Adresse eingibt, würde er (voraussichtlich) keine spezifische Meldung erhalten, die ihm hilft, den Fehler zu korrigieren (z.B. "Bitte geben Sie eine gültige E-Mail-Adresse im Format name@domain.de ein.").

Erfüllt: Fehlervermeidung (Rechtlich, Finanziell, Daten) – WCAG 2.2, 3.3.4 (AA)

• Bei rechtlich oder finanziell relevanten Aktionen (z. B. Kauf, Steuererklärung) bietest Du Änderungs- oder Widerrufsmöglichkeiten? (Nicht anwendbar)
• Wenn Nutzerdaten gelöscht oder verändert werden, kann man das rückgängig machen oder bestätigen lassen? (Nicht anwendbar)
• Bei Tests (z. B. Prüfungen, Fragebögen) gibst Du die Möglichkeit, Antworten zu überprüfen oder zu ändern, bevor sie endgültig abgeschickt werden? (Nicht anwendbar)

Erfüllt: Redundante Eingabe – WCAG 2.2, 3.3.7 (A)

• Vermeidest Du doppelte Eingaben innerhalb eines Prozesses oder füllst Du vorher eingegebene Daten automatisch aus? (Nicht anwendbar für das einfache Kontaktformular)

Erfüllt: Barrierefreie Authentifizierung (Minimum) – WCAG 2.2, 3.3.8 (AA)

• Vermeidest Du reine kognitive Prüfungsschritte (z. B. komplizierte Passwörter, Rätsel), oder bietest Du Alternativen? (Keine Authentifizierung vorhanden)

Ist Deine Website robust genug?

Der vierte und letzte Grundpfeiler der Barrierefreiheit ist die Robustheit [3].

Dieser Aspekt stellt sicher, dass Deine Website auch mit zukünftigen Technologien kompatibel bleibt und von einer Vielzahl von Benutzeragenten, einschließlich assistiver Technologien, korrekt interpretiert wird.

Indem Du auf sauberes HTML achtest und Webstandards einhältst, erhöhst Du die Langlebigkeit und Zugänglichkeit Deiner Website.

Maximiere die Kompatibilität mit allen Technologien, die Nutzer verwenden.

Nicht-erfüllt: Parsing – WCAG 2.2, 4.1.1 (A)

warnung

Dieses Kriterium ist in WCAG 2.2 [1] formal veraltet, da moderne Browser sehr fehlertolerant sind. Dennoch ist valides HTML eine wichtige Grundlage für Robustheit [71]. Die hier genannten Punkte beziehen sich eher auf die korrekte Verwendung von HTML gemäß Spezifikation, was unter 1.3.1 [72] und 4.1.2 [73] abgedeckt wird. Wir markieren es hier als "nicht erfüllt" aufgrund der massiven semantischen Fehler.

• Sind Elemente gemäß ihrer Spezifikation verschachtelt, haben Start- und End-Tags und keine doppelten Attribute/IDs?

Obwohl keine explizite Validierung durchgeführt wurde, deuten die massiven semantischen Fehler (Verwendung von div für alles) darauf hin, dass die HTML-Struktur wahrscheinlich nicht den Spezifikationen für die korrekte Verwendung von Elementen entspricht. Valides Parsing ist zwar wahrscheinlich gegeben, aber die korrekte Anwendung von HTML ist fundamental verletzt.

To-Dos:

• Code mit einem HTML-Validator prüfen (z.B. W3C Nu HTML Checker).
• Korrekte semantische Elemente verwenden (siehe 1.3.1).

Nicht-erfüllt: Name, Rolle, Wert – WCAG 2.2, 4.1.2 (A)

• Nutzt Du standardisierte UI-Komponenten (z. B. HTML-Formulare) gemäß WHATWG HTML-Spezifikation [74], damit Name/Rolle erkennbar sind?
• Wenn Du Standardkomponenten umwidmest oder neu skriptest, achtest Du auf korrektes Auszeichnen von Name/Rolle?
• Wenn Du Standardkomponenten in einer Programmiersprache nutzt, stellst Du sicher, dass Name/Rolle via API auslesbar sind? (Nicht anwendbar)
• Wenn Du eigene UI-Komponenten programmierst, exponierst Du Name/Rolle/Zustand über ARIA oder Accessibility-APIs? (ARIA wird nicht verwendet)

Dieses Kriterium wird an vielen Stellen verletzt [75], [76]:

• Navigation & Footer Links: <div> und <span> werden anstelle von <a> verwendet. Rolle ("Link") ist nicht vorhanden.
• Überschriften: <div> anstelle von <h1><h6>. Rolle ("Überschrift") fehlt.
• FAQ: <div> wird als interaktiver Trigger verwendet, anstelle von <button>. Rolle ("Button") und Zustand (aria-expanded) fehlen. - Formularfelder: Fehlende <label> führen dazu, dass der zugängliche Name der Felder nicht korrekt bestimmt werden kann. - Slider/Marquee: Keine Rollen (z.B. role="region", aria-live) oder Zustände definiert, die die Funktion für assistive Technologien verständlich machen.
• Formularfelder: Fehlende <label> führen dazu, dass der zugängliche Name der Felder nicht korrekt bestimmt werden kann.
• Slider/Marquee: Keine Rollen (z.B. role="region", aria-live) oder Zustände definiert, die die Funktion für assistive Technologien verständlich machen.

To-Dos:

• Native HTML-Elemente für ihren vorgesehenen Zweck verwenden (Links, Buttons, Überschriften, Listen, Formularelemente).
• Wo native Elemente nicht ausreichen (z.B. für benutzerdefinierte Widgets wie das FAQ-Akkordeon), korrekte ARIA-Rollen, -Eigenschaften und -Zustände (role, aria-label, aria-expanded, aria-controls etc.) implementieren.
• Sicherstellen, dass alle Formularfelder einen zugänglichen Namen durch korrekt verknüpfte <label>-Elemente erhalten.

Nicht-erfüllt: Statusmeldungen – WCAG 2.2, 4.1.3 (AA)

• Gibst Du Statusmeldungen (z. B. „Erfolg“ oder „Daten gespeichert“) so aus, dass Assistive Technologien sie ohne Fokus erhalten? (Keine Statusmeldungen implementiert)
• Erscheinen Fehlermeldungen oder Warnungen (z. B. Validierungsfehler) ebenfalls programmatisch wahrnehmbar (role="alert" o. ä.)?
• Wird ein Fortschritt (z. B. Ladebalken) live per Rolle oder Live-Region angekündigt (etwa role="progressbar" oder role="log")?** (Keine Fortschrittsanzeigen implementiert)

Wie früher beschrieben, fehlt eine Fehlerbehandlung. Wenn Fehlermeldungen hinzugefügt werden, müssen sie so implementiert werden, dass sie von assistiven Technologien (wie Screenreadern) automatisch wahrgenommen werden, ohne dass der Nutzer den Fokus manuell dorthin bewegen muss. Dies geschieht typischerweise durch Verwendung von role="alert" oder aria-liveRegionen [77].

To-Dos:

• Dynamisch erscheinende Status- und Fehlermeldungen (z.B. nach Formularabsendung) in einem Container mit role="alert" oder role="status" (je nach Dringlichkeit) platzieren, damit sie Screenreadern angekündigt werden.

Jetzt wurden alle 55 Anforderungen der WCAG 2.2 auf Deiner Website geprüft. Die Website hat 20 aus 55 Kriterien der WCAG 2.2 nicht erfüllt. Deswegen besteht für Deine Website noch keine Konformitätsvermutung [78].

Alle To-Dos zusammengefasst

Bildalternativen & Medien

Alt‑Text / Dekorative Bilder

• Sinnvolle Alternativtexte für alle informativen Bilder (Hero, Slider, Features, Alternierende Sektionen, How it Works) erstellen und im altAttribut hinterlegen [4], [5].
• Prüfen, ob einzelne Bilder tatsächlich rein dekorativ sind und diese explizit mit alt="" markieren [6].

Semantische Struktur & HTML‑Fehler

HTML‑Validierung & Struktur

• Code mit einem HTML-Validator prüfen (z.B. W3C Nu HTML Checker) und Fehler beheben [71].
• Korrekte semantische HTML-Elemente für die Seitenstruktur verwenden (<header>, <nav>, <main>, <section>, <footer>, <article>) [10].
• Überschriften mit <h1> - <h6> hierarchisch korrekt auszeichnen [12], [13].

Listen & Gruppierungen

• Navigationsmenüs, Feature-Listen, Schritt-Listen, FAQ-Listen etc. als HTML-Listen (<ul>/<ol> mit <li>) strukturieren [14].

Sektionen & Landmarks

• Alle wichtigen inhaltlichen Sektionen prüfen und ggf. mit aria-label bzw. aria-labelledby als Landmarks kennzeichnen, wenn native Elemente wie <nav>, <main> nicht ausreichen [10].

ARIA‑Attribute & Interaktive Elemente

Interaktive Elemente optimieren

• Interaktive Elemente (Navigationslinks, FAQ-Trigger, Footer-Links) als native Links (<a> mit href) oder Buttons (<button>) implementieren [31], [44].
• Für interaktive Komponenten wie das FAQ-Akkordeon ARIA-Attribute (aria-expanded, aria-controls, role="region" für den Inhalt) verwenden [15].
• Dynamisch erscheinende Status- und Fehlermeldungen (z.B. nach Formularabsendung) in einem Container mit role="alert" oder role="status" platzieren [77].

Navigation & Tastaturzugänglichkeit

Schnellzugriff & Navigation

• Einen "Skip-to-Content"-Link ("Zum Inhalt springen") als erstes fokussierbares Element implementieren (visuell verborgen bis Fokus) [40].
• Sicherstellen, dass der Zweck jedes Links (über sichtbaren Linktext oder ARIA‑Attribute) eindeutig erkennbar ist (nach Umwandlung in <a>) [43].
• Mindestens einen weiteren Weg zur Navigation bereitstellen (Sitemap, Suche oder konsistente Menüs) [45], [46], [47].

Fokus & Tastaturbedienung

• Deutlich sichtbare :focusStile für alle interaktiven Elemente (Links, Buttons, Formularfelder, etc.) im CSS definieren [50].
• Sicherstellen, dass alle interaktiven Elemente per Tastatur erreichbar und bedienbar sind (Navigation, FAQ, Slider-/Marquee-Controls) [31].

Kontrast, Design & visuelle Anforderungen

Text- & Non‑Text‑Kontrast

• Farbkontraste für Text (Platzhalter, Buttons, Hero) gemäß WCAG AA (4.5:1 für normalen, 3:1 für großen Text) anpassen [23], [24].
• Kontrast für Bedienelemente (Formularfeld-Ränder, Fokusindikator) gemäß WCAG AA (3:1) sicherstellen [28], [29].

Animation & Bewegung

• Für Slider und Marquee Steuerelemente zum Anhalten/Pausieren hinzufügen, die per Tastatur bedienbar sind [34], [35].
• CSS-Media-Query prefers-reduced-motion respektieren und Animationen ggf. deaktivieren.

Formulare & Eingabefelder

Beschriftung & Eingabezweck

• Für jedes Eingabefeld im Kontaktformular ein sichtbares <label>-Element hinzufügen und korrekt verknüpfen (for/id) [16].
• Passende autocompleteAttribute für Felder wie Name (name) und E-Mail (email) hinzufügen [20].

Fehlerbehandlung

• Eine robuste Fehlerbehandlung für das Kontaktformular implementieren [63].
• Fehlerhafte Felder programmatisch kennzeichnen (aria-invalid="true") [62].
• Fehlermeldungen textuell bereitstellen, mit dem Feld verknüpfen (aria-describedby) [65] und Korrekturvorschläge anbieten [70].
• Fehlermeldungen via role="alert" o.ä. für Screenreader ankündigen [77].

Sonstiges & Systemweite Maßnahmen

Hilfe

• Einen konsistenten Hilfe-Mechanismus auf allen Seiten bereitstellen (z.B. Link zu FAQ/Kontakt im Footer) [60].

Dokumentation

• Eine (ehrliche) Barrierefreiheitserklärung erstellen und auf der Website veröffentlichen.

Wenn Du alle diese To-Dos umsetzt, wird Deine Website Konformitätsvermutung sehr wahrscheinlich erreichen können.

Fazit

Insgesamt wurden 55 einzelne Kriterien aus der WCAG 2.2 A und AA überprüft, die zur Einhaltung der gesetzlichen Anforderungen erforderlich sind [1].

• Erfüllte Kriterien: 35
• Nicht erfüllte Kriterien: 20

Die Website weist gravierende Mängel in Bezug auf Barrierefreiheit auf und erfüllt die Anforderungen der WCAG 2.2 AA bei weitem nicht [78]. Die Probleme ziehen sich durch alle vier Prinzipien der Barrierefreiheit (Wahrnehmbar, Bedienbar, Verständlich, Robust) [3]:

• Wahrnehmbarkeit: Fehlende Textalternativen für Bilder, unzureichende Farbkontraste, mangelhafte semantische Struktur, die Beziehungen und Informationen verschleiert.
• Bedienbarkeit: Wichtige Teile der Website (Navigation, FAQ) sind nicht per Tastatur bedienbar, der Fokus ist nicht sichtbar, bewegte Inhalte (Slider, Marquee) können nicht gestoppt werden, und es fehlt ein Skip-Link.
• Verständlichkeit: Formulare sind nicht korrekt beschriftet, Fehler werden nicht oder unzureichend kommuniziert, und es fehlen alternative Navigationswege sowie konsistente Hilfe.
• Robustheit: Die fehlerhafte Verwendung von HTML und das Fehlen von ARIA, wo nötig, führen dazu, dass assistive Technologien die Seite nicht korrekt interpretieren können.

Diese Demo-Website ist in ihrem aktuellen Zustand hochgradig unzugänglich. Sie illustriert jedoch sehr gut typische Barrieren, die in realen Webprojekten auftreten können. Die Umsetzung der aufgelisteten To-Dos würde eine grundlegende Überarbeitung der Codebasis erfordern, insbesondere die Einführung korrekter semantischer HTML-Strukturen und die Implementierung von Standard-Interaktionsmustern für Navigation, Formulare und dynamische Inhalte.

Ich hoffe, dieser Bericht hilft Dir, die identifizierten Barrieren nachzuvollziehen und die notwendigen Schritte zur Verbesserung der Zugänglichkeit aufzuzeigen. Bei Fragen melde Dich gerne.

Haftung

• Kein Rechtsersatz: Dieses Audit stellt keine Rechtsberatung dar. Alle Inhalte und Empfehlungen wurden sorgfältig geprüft und nach bestem Wissen erstellt, jedoch kann keine Gewähr für Vollständigkeit, Aktualität und Richtigkeit übernommen werden.
• Verantwortung für Umsetzung: Für die ordnungsgemäße, vollständige und korrekte Umsetzung der Empfehlungen ist allein der Auftraggeber verantwortlich.
• Haftungsumfang: Jegliche Haftung wird auf vorsätzliches oder grob fahrlässiges Verhalten beschränkt. Insbesondere sind Schadensersatzansprüche, die durch leichte Fahrlässigkeit verursacht werden, ausgeschlossen.

Solltest Du Fragen zum Lizenzumfang, zur Nutzung der Inhalte oder zur Haftung haben, melde Dich gern bei mir.

---

1. W3C, „Web Content Accessibility Guidelines (WCAG) 2.2“. 2023. [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/ ⤴
2. Bundesministerium der Justiz und für Verbraucherschutz, „Gesetz zur Umsetzung der Richtlinie (EU) 2019/882 des Europäischen Parlaments und des Rates über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen (Barrierefreiheitsstärkungsgesetz – BFSG)“. 2023. [Online]. Verfügbar unter: https://www.gesetze-im-internet.de/bfsg/ ⤴
3. W3C Web Accessibility Initiative, „Understanding the Four Principles of Accessibility“. 2022. [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG21/quickref/ ⤴
4. W3C, „G94: Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G94 ⤴
5. W3C, „H37: Using alt attributes on img elements“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H37 ⤴
6. W3C, „H67: Using null alt text and no title attribute on img elements for images that assistive technology should ignore“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H67 ⤴
7. W3C, „ARIA10: Using aria-labelledby to provide a text alternative for non-text content“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA10 ⤴
8. W3C, „G141: Organizing a page using headings“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G141 ⤴
9. W3C Web Accessibility Initiative (WAI), „W3C Karussell-Tutorial: Seitenregionen“. 2023. [Online]. Verfügbar unter: https://www.w3.org/WAI/tutorials/page-structure/regions/ ⤴
10. W3C, „ARIA11: Using ARIA landmarks to identify regions of a page“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA11 ⤴
11. W3C, „ARIA16: Using aria-labelledby to provide a name for user interface controls“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA16 ⤴
12. W3C, „H42: Using h1-h6 to identify headings“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H42 ⤴
13. W3C, „H69: Providing heading elements at the beginning of each section of content“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H69 ⤴
14. W3C, „H48: Using ol, ul and dl for lists or groups of links“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H48 ⤴
15. W3C Web Accessibility Initiative, „WAI-ARIA Authoring Practices 1.2“. 2021. [Online]. Verfügbar unter: https://www.w3.org/TR/wai-aria-practices/ ⤴
16. W3C, „H44: Using label elements to associate text labels with form controls“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H44 ⤴
17. W3C, „G57: Ordering the content in a meaningful sequence“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G57 ⤴
18. W3C, „G96: Providing textual identification of items that otherwise rely only on sensory information to be understood“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G96 ⤴
19. W3C, „G214: Using a control to allow access to content in different orientations which is otherwise restricted“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G214 ⤴
20. W3C, „H98: Using HTML autocomplete attributes“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H98 ⤴
21. W3C, „G14: Ensuring that information conveyed by color differences is also available in text“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G14 ⤴
22. W3C, „G170: Providing a control near the beginning of the web page that turns off sounds that play automatically“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G170 ⤴
23. W3C, „G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G18 ⤴
24. W3C, „G145: Ensuring that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G145 ⤴
25. W3C, „G142: Using a technology that has commonly-available user agents that support zoom“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G142 ⤴
26. W3C, „C32: Using media queries and grid CSS to reflow columns“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/css/C32 ⤴
27. W3C, „G206: Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G206 ⤴
28. W3C, „G17: Ensuring that a contrast ratio of at least 7:1 exists between text (and images of text) and background behind the text“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G17 ⤴
29. W3C, „G195: Using an author-supplied, visible focus indicator“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G195 ⤴
30. W3C, „C35: Allowing for text spacing without wrapping“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/css/C35 ⤴
31. W3C, „G202: Ensuring keyboard control for all functionality“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G202 ⤴
32. WHATWG, „HTML Standard — The tabindex attribute“. 2024. [Online]. Verfügbar unter: https://html.spec.whatwg.org/multipage/interaction.html#attr-tabindex ⤴
33. W3C, „H97: Grouping related links using the nav element“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H97 ⤴
34. W3C Web Accessibility Initiative (WAI), „WAI-ARIA Authoring Practices 1.2: Karussell-Muster“. 2023. [Online]. Verfügbar unter: https://www.w3.org/WAI/ARIA/apg/patterns/carousel/ ⤴
35. W3C, „G4: Allowing the content to be paused and restarted from where it was paused“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G4 ⤴
36. W3C Web Accessibility Initiative (WAI), „WAI-ARIA 1.2: aria-live“. 2021. [Online]. Verfügbar unter: https://www.w3.org/TR/wai-aria-1.2/#aria-live ⤴
37. W3C, „G21: Ensuring that users are not trapped in content“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G21 ⤴
38. W3C, „G133: Providing a checkbox on the first page of a multipart form that allows users to ask for longer session time limit or no session time limit“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G133 ⤴
39. W3C, „G15: Using a tool to ensure that content does not violate the general flash threshold or red flash threshold“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G15 ⤴
40. W3C, „G1: Adding a link at the top of each page that goes directly to the main content area“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G1 ⤴
41. W3C, „G88: Providing descriptive titles for web pages“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G88 ⤴
42. W3C, „G59: Placing the interactive elements in an order that follows sequences and relationships within the content“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G59 ⤴
43. W3C, „G91: Providing link text that describes the purpose of a link“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G91 ⤴
44. W3C, „H30: Providing link text that describes the purpose of a link for anchor elements“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H30 ⤴
45. W3C, „G125: Providing links to navigate to related web pages“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G125 ⤴
46. W3C, „G64: Providing a Table of Contents“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G64 ⤴
47. W3C, „G63: Providing a site map“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G63 ⤴
48. W3C, „G130: Providing descriptive headings“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G130 ⤴
49. W3C, „G131: Providing descriptive labels“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G131 ⤴
50. W3C, „G165: Using the default focus indicator for the platform so that high visibility default focus indicators will carry over“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G165 ⤴
51. W3C, „G210: Ensuring that drag-and-drop actions can be cancelled“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G210 ⤴
52. W3C, „G208: Including the text of the visible label as part of the accessible name“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G208 ⤴
53. W3C, „G213: Provide conventional controls and an application setting for motion activated input“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G213 ⤴
54. W3C, „H57: Using the language attribute on the HTML element“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H57 ⤴
55. W3C, „H58: Using language attributes to identify changes in the human language“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H58 ⤴
56. W3C, „G107: Using ‚activate‘ rather than ‚focus‘ as a trigger for changes of context“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G107 ⤴
57. W3C, „G80: Providing a submit button to initiate a change of context“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G80 ⤴
58. W3C, „G61: Presenting repeated components in the same relative order each time they appear“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G61 ⤴
59. W3C, „G197: Using labels, names, and text alternatives consistently for content that has the same functionality“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G197 ⤴
60. W3C, „G220: Provide a contact-us link in a consistent location“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G220 ⤴
61. W3C, „G73: Providing a long description in another location with a link to it that is immediately adjacent to the non-text content“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G73 ⤴
62. W3C, „ARIA19: Using ARIA role=alert or Live Regions to Identify Errors“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA19 ⤴
63. W3C, „G83: Providing text descriptions to identify required fields that were not completed“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G83 ⤴
64. W3C, „G85: Providing a text description when user input falls outside the required format or values“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G85 ⤴
65. W3C, „ARIA21: Using aria-invalid to Indicate An Error Field“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA21 ⤴
66. W3C, „Success Criterion 4.1.3 Status Messages“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#status-messages ⤴
67. W3C, „G167: Using an adjacent button to label the purpose of a field“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G167 ⤴
68. W3C, „Success Criterion 1.3.5 Identify Input Purpose“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#identify-input-purpose ⤴
69. W3C, „Success Criterion 3.3.1 Error Identification“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#error-identification ⤴
70. W3C, „G177: Providing suggested correction text“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G177 ⤴
71. W3C, „G134: Validating web pages“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G134 ⤴
72. W3C, „Success Criterion 1.3.1 Info and Relationships“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#info-and-relationships ⤴
73. W3C, „Success Criterion 4.1.2 Name, Role, Value“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#name-role-value ⤴
74. WHATWG, „HTML Living Standard“. 2024. [Online]. Verfügbar unter: https://html.spec.whatwg.org/ ⤴
75. W3C, „G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/general/G108 ⤴
76. W3C, „ARIA4: Using a WAI-ARIA role to expose the role of a user interface component“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA4 ⤴
77. W3C, „ARIA22: Using role=status to present status messages“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA22 ⤴
78. W3C, „WCAG 2.2 - 5. Conformance“. 2023. [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#conformance-to-wcag-2-2 ⤴