Barrierefreie Website - Was Unternehmen konkret prüfen sollten

Eine Website wird nicht barrierefrei, nur weil sie modern aussieht oder in einem automatischen Test gut abschneidet.

Entscheidend ist, ob Menschen die wichtigsten Inhalte und Funktionen tatsächlich nutzen können: mit Tastatur, mit Screenreader, mit ausreichendem Kontrast, mit verständlichen Formularen und ohne versteckte Hürden.

Dieser Beitrag zeigt, welche Bereiche Unternehmen zuerst prüfen sollten. Nicht als vollständiger WCAG-Audit und nicht als Rechtsberatung, sondern als praktischer Einstieg: Wo entstehen auf Websites typischerweise Barrieren, was kann man selbst testen und wann reicht ein automatischer Check nicht mehr aus?

Kurz gesagt

Im Kern muss eine Website mit ihren zentralen Inhalten und Funktionen für unterschiedliche Nutzer:innen zugänglich sein.

Besonders wichtig sind:

• klare Struktur mit sinnvollen Überschriften
• Bedienbarkeit auch ohne Maus
• sichtbarer Tastaturfokus
• verständliche Formulare
• sinnvolle Alt-Texte für relevante Bilder
• ausreichende Kontraste
• eindeutige Links und Buttons
• robuste technische Umsetzung

Ein automatischer Test kann viele technische Probleme sichtbar machen. Ob eine Website wirklich verständlich, logisch und praktisch nutzbar ist, muss aber zusätzlich manuell geprüft werden.

Die vier WCAG-Prinzipien als Orientierung

Die WCAG, also die Web Content Accessibility Guidelines, beschreiben Barrierefreiheit über vier Grundprinzipien. Inhalte sollen:

• wahrnehmbar sein
• bedienbar sein
• verständlich sein
• robust sein

Diese Prinzipien setzen den Rahmen für die Analyse. Konkret für Unternehmen ergeben sich daraus die folgenden Kernfragen.

1. Sind Inhalte auch ohne Sehen verständlich?

Viele Websites sind stark visuell gedacht. Layout, Farben, Icons, Bilder und Positionen erklären, was wichtig ist und was man tun kann.

Das ist nicht automatisch ein Problem. Problematisch wird es, wenn diese Information nur visuell vorhanden ist.

Ein Icon-Button braucht einen zugänglichen Namen. Ein relevantes Bild braucht einen sinnvollen Alternativtext. Ein Formularfeld braucht ein echtes Label. Eine Fehlermeldung darf nicht nur rot sein, sondern muss auch textlich verständlich und technisch zugeordnet sein.

Digitaler Text ist dafür eine gute Grundlage, weil er von Browsern, Screenreadern und anderen assistiven Technologien verarbeitet werden kann. Das funktioniert aber nur zuverlässig, wenn die Website semantisch sauber aufgebaut ist: mit echten Überschriften, sinnvollen Linktexten, beschrifteten Formularfeldern und Alternativtexten für relevante Bilder.

Typische Probleme

• Bilder haben keinen Alternativtext.
• Bilder haben Alt-Texte wie bild.jpg, grafik oder image.
• Buttons bestehen nur aus Icons und haben keinen zugänglichen Namen.
• Links heißen nur „Mehr erfahren“, obwohl der Kontext fehlt.
• Informationen werden nur über Farbe vermittelt.
• Formularfelder haben nur Placeholder, aber keine echten Labels.
• Überschriften werden visuell groß gemacht, aber nicht als echte Überschriften ausgezeichnet.

Prüffragen

• Haben relevante Bilder sinnvolle Alternativtexte?
• Sind Buttons und Links auch ohne visuelle Umgebung verständlich?
• Werden Informationen nicht nur über Farbe vermittelt?
• Haben Formularfelder sichtbare und technisch verknüpfte Labels?
• Ist die Überschriftenstruktur logisch?
• Erkennt ein Screenreader, welche Inhalte zusammengehören?

Leitfrage

Ist die Information auch dann verständlich, wenn ich sie nicht sehen oder Farben nicht unterscheiden kann?

2. Ist die Website ohne Maus bedienbar?

Viele Barrieren fallen sofort auf, wenn man die Maus weglegt.

Eine Website muss nicht nur anklickbar sein. Die wichtigsten Funktionen müssen auch mit der Tastatur erreichbar sein: Navigation, Menüs, Buttons, Formulare, Modals, Cookie-Banner, Checkout, Buchung oder Kontaktformular.

Der einfachste Test dauert nur wenige Minuten:

1. Maus weglegen.
2. Mit Tab durch die Seite navigieren.
3. Mit Shift + Tab zurückgehen.
4. Mit Enter oder Space Elemente aktivieren.
5. Beobachten, ob der Fokus immer sichtbar bleibt.

Wenn du dabei die Orientierung auf deiner Seite verlierst, gibt es hier Verbesserungsbedarf.

Typische Probleme

• Der Tastaturfokus ist nicht sichtbar.
• Menüs lassen sich nur mit der Maus öffnen.
• Dropdowns sind mit Tab nicht erreichbar.
• Modals halten den Fokus nicht korrekt.
• Cookie-Banner blockieren die Navigation.
• Die Tab-Reihenfolge springt unlogisch über die Seite.
• Buttons sind visuell klickbar, aber technisch keine Buttons.
• Nutzer:innen kommen in einen Bereich hinein, aber nicht mehr heraus.

Prüffragen

• Kann ich alle wichtigen Funktionen ohne Maus erreichen?
• Ist der Fokus immer sichtbar?
• Ist die Reihenfolge logisch?
• Kann ich Menüs, Modals und Formulare bedienen?
• Kann ich ein Formular vollständig absenden?
• Kann ich Dialoge schließen und zur ursprünglichen Stelle zurückkehren?
• Funktionieren Cookie-Banner und andere Overlays mit Tastatur?

Leitfrage

Kann ich alle wichtigen Funktionen nutzen, ohne eine Maus zu verwenden?

3. Sind Formulare verständlich und fehlertolerant?

Formulare sind oft der Punkt, an dem Barrierefreiheit geschäftskritisch wird.

Kontaktformular, Anfrageformular, Login, Newsletter-Anmeldung, Checkout, Terminbuchung oder Kundenportal: Wenn diese Bereiche nicht funktionieren, betrifft das oft Leads, Umsatz, Support und Vertrauen.

Ein Formular ist nicht automatisch barrierefrei, nur weil es optisch sauber aussieht. Entscheidend ist, ob Nutzer:innen verstehen, was sie eingeben sollen, welche Felder verpflichtend sind, welche Fehler passiert sind und wie sie diese Fehler beheben können.

Typische Probleme

• Formularfelder haben nur Placeholder statt Labels.
• Pflichtfelder sind nur mit Farbe oder Sternchen markiert, aber nicht erklärt.
• Fehlermeldungen erscheinen irgendwo auf der Seite, aber nicht beim betroffenen Feld.
• Fehler werden nur farblich angezeigt.
• Nach dem Absenden springt der Fokus nicht zur Fehlermeldung.
• Screenreader bekommen nicht mit, dass ein Fehler aufgetreten ist.
• Eingabefelder sind technisch nicht mit ihren Labels verbunden.

Schlechtes Beispiel

<input placeholder="E-Mail" />

Das sieht vielleicht verständlich aus. Aber der Placeholder verschwindet beim Tippen, ist oft kontrastarm und ersetzt kein echtes Label.

Besser

<label for="email"> E-Mail-Adresse </label>
<input id="email" name="email" type="email" autocomplete="email" />

Wenn es einen Fehler gibt:

<label for="email"> E-Mail-Adresse </label>
<input
  id="email"
  name="email"
  type="email"
  aria-describedby="email-error"
  aria-invalid="true"
/>
<p id="email-error">Bitte gib eine gültige E-Mail-Adresse ein.</p>

Das ist nicht nur für Screenreader besser. Es ist auch für alle anderen Nutzer:innen klarer.

Prüffragen

• Hat jedes Formularfeld ein sichtbares Label?
• Ist das Label technisch mit dem Feld verbunden?
• Sind Pflichtfelder verständlich erklärt?
• Sind Fehlermeldungen klar formuliert?
• Ist erkennbar, welches Feld betroffen ist?
• Wird der Fokus nach Fehlern sinnvoll gesetzt?
• Kann ich das Formular nur mit Tastatur ausfüllen und absenden?

Leitfrage

Versteht eine Person, was sie tun soll, auch wenn sie das Formular nicht so sieht wie ich?

4. Sind Kontrast, Fokus und visuelle Hinweise erkennbar?

Barrierefreiheit betrifft nicht nur blinde Menschen oder Screenreader-Nutzung.

Viele Nutzer:innen sehen Inhalte, aber nicht unter idealen Bedingungen. Sie nutzen kleine Bildschirme, schlechte Lichtverhältnisse, ältere Geräte, vergrößerte Darstellung oder haben eingeschränktes Sehvermögen.

Deshalb müssen Texte, Bedienelemente und Zustände visuell ausreichend erkennbar sein.

Typische Probleme

• Text hat zu wenig Kontrast zum Hintergrund.
• Buttons sehen deaktiviert aus, obwohl sie aktiv sind.
• Links unterscheiden sich nur durch Farbe vom normalen Text.
• Der Fokusrahmen wurde mit outline: none entfernt.
• Fehlermeldungen sind nur rot, aber nicht textlich erklärt.
• Graue Hilfstexte sind kaum lesbar.
• Hover-Zustände haben keinen Tastatur-Äquivalentzustand.

Fokus ist kein Designfehler

Ein sichtbarer Fokus ist eine Orientierungshilfe.

Wer mit der Tastatur navigiert, muss jederzeit erkennen können, welches Element gerade aktiv ist. Wenn der Fokus unsichtbar ist, wird die Seite schnell unbenutzbar.

Schlecht:

button:focus {
  outline: none;
}

Besser:

button:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

Das konkrete Design kann natürlich anders aussehen. Wichtig ist: Der Fokus muss sichtbar sein.

Prüffragen

• Ist normaler Text gut lesbar?
• Sind Links klar als Links erkennbar?
• Sind aktive, fokussierte und deaktivierte Zustände unterscheidbar?
• Ist der Tastaturfokus immer sichtbar?
• Werden Fehler nicht nur farblich dargestellt?
• Bleibt die Seite auch bei Zoom oder größerer Schrift nutzbar?

Leitfrage

Kann ich wichtige Inhalte, Zustände und Interaktionen klar erkennen?

5. Ist die Seitenstruktur logisch aufgebaut?

Die semantische Struktur einer Website ist für viele Nutzer:innen und Systeme entscheidend. Es geht hier um die korrekte Anordnung der Elemente im Code und nicht explizit nur um deren visuelle Position auf der Seite.

Überschriften, Listen, Navigationen, Hauptbereiche, Formulare und Tabellen sollten nicht nur visuell, sondern auch semantisch an den richtigen Stellen als solche erkennbar sein.

Dies hilft obendrein auch immens bei der Optimierung für Suchmaschinen und KI-Assistenten.

Typische Probleme

• Es gibt keine eindeutige H1 Überschrift.
• Überschriftenebenen springen chaotisch von H1 zu H4.
• Text wird visuell wie eine Überschrift gestaltet, ist aber keine Überschrift.
• Listen werden mit Zeilenumbrüchen statt echten Listen gebaut.
• Tabellen werden für Layout statt für Daten verwendet.
• Navigation, Hauptinhalt und Footer sind nicht klar ausgezeichnet.
• Wiederkehrende Bereiche haben keine sinnvolle Struktur.

Prüffragen

• Hat jede Seite eine klare Hauptüberschrift?
• Sind H2, H3 und weitere Ebenen logisch aufgebaut?
• Werden Listen als echte Listen ausgezeichnet?
• Gibt es einen erkennbaren Hauptinhalt?
• Sind Navigation und Footer semantisch nachvollziehbar?
• Kann man die Seite über Überschriften grob verstehen?
• Sind Tabellen nur dort im Einsatz, wo wirklich tabellarische Daten dargestellt werden?

Leitfrage

Kann ich die Struktur der Seite verstehen, ohne das visuelle Layout zu sehen?

6. Sind Komponenten technisch robust umgesetzt?

Eine Website kann visuell funktionieren und trotzdem für assistive Technologien schwer interpretierbar sein.

Das passiert oft bei Custom-Komponenten: selbstgebauten Buttons, Dropdowns, Modals, Tabs, Akkordeons, Slidern, Cookie-Bannern oder komplexen Formularfeldern.

Wenn ein div wie ein Button aussieht, aber technisch kein Button ist, fehlen oft wichtige Eigenschaften: Tastaturbedienung, Rolle, Name, Zustand und erwartetes Verhalten.

Typische Probleme

• Klickbare div-Elemente statt echter Buttons oder Links.
• Icon-Buttons ohne zugänglichen Namen.
• Modals ohne korrektes Fokusmanagement.
• Tabs oder Akkordeons ohne Tastaturbedienung.
• Zustände wie „geöffnet“, „ausgewählt“ oder „ungültig“ werden nicht vermittelt.
• ARIA wird verwendet, obwohl ein normales HTML-Element besser wäre.
• Komponenten funktionieren mit Maus, aber nicht mit Tastatur oder Screenreader.

Grundregel

HTML zuerst. ARIA nur dann, wenn es wirklich nötig ist.

Ein echter Button bringt bereits viele Eigenschaften mit:

<button>Kontakt aufnehmen</button>

Ein div mit Klick-Handler muss dagegen vieles nachbauen:

<div onclick="submitForm()">Kontakt aufnehmen</div>

Das sieht vielleicht ähnlich aus, ist aber technisch nicht dasselbe.

Prüffragen

• Werden native HTML-Elemente verwendet, wo sie passen?
• Haben Buttons, Links und Formularfelder zugängliche Namen?
• Sind Custom-Komponenten mit Tastatur bedienbar?
• Werden Zustände korrekt vermittelt?
• Funktionieren Modals, Menüs und Dropdowns auch ohne Maus?
• Bleibt die Seite bei Zoom, mobilen Ansichten und geänderter Schriftgröße nutzbar?

Leitfrage

Können Browser und assistive Technologien zuverlässig erkennen, was ein Element ist und wie es bedient wird?

Was automatische Tests gut finden können

Automatische Tests sind ein guter Einstieg.

Sie finden viele technische Probleme schnell und zuverlässig, zum Beispiel:

• fehlende Alt-Attribute bei Bildern
• fehlende Formularlabels
• bestimmte Kontrastprobleme
• leere Links oder Buttons
• fehlende Dokument-Sprache
• problematische ARIA-Verwendung
• strukturelle HTML-Probleme

Genau dafür sind Tools sinnvoll. Sie geben einen schnellen Überblick und helfen, offensichtliche Fehler zu finden.

Für diesen ersten Überblick kannst du zum Beispiel einen automatischen Check mit barrieretest.at starten.

Was automatische Tests nicht sicher beurteilen können

Automatische Tests haben aber klare Grenzen.

Ein Tool kann erkennen, ob ein Bild ein Alt-Attribut hat. Es kann aber nicht zuverlässig beurteilen, ob der Alt-Text im konkreten Kontext sinnvoll ist.

Ein Tool kann erkennen, ob ein Button einen Namen hat. Es kann aber nicht sicher beurteilen, ob dieser Name für Nutzer:innen verständlich genug ist.

Ein Tool kann bestimmte Formularprobleme finden. Es kann aber nicht vollständig bewerten, ob ein Formular in einem echten Nutzerfluss logisch, verständlich und fehlertolerant ist.

Beispiele

Automatisch prüfbar:

Bild hat kein alt-Attribut.

Manuell zu bewerten:

Ist der vorhandene Alt-Text hilfreich oder nur formal vorhanden?

Automatisch prüfbar:

Formularfeld hat kein Label.

Manuell zu bewerten:

Versteht eine Person nach einer Fehlermeldung, was sie korrigieren muss?

Automatisch prüfbar:

Button hat keinen zugänglichen Namen.

Manuell zu bewerten:

Ist der Buttontext im Kontext eindeutig?

Mit dem Einsatz von KI verschwimmen die Grenzen dessen, was automatisch testbar ist. Der KI-Check von barrieretest.at überprüft einige dieser Punkte bereits mit. Dennoch braucht es hier oft menschliches Feingefühl für die Entscheidung, ob der Inhalt auch wirklich das aussagt was er soll.

Welche Bereiche Unternehmen zuerst prüfen sollten

Zu Beginn sollte man sich auf die wichtigsten Nutzerflüsse konzentrieren.

Besonders relevant sind:

• Startseite
• Kontaktformular
• Terminbuchung
• Checkout
• Login
• Kundenportal
• Produktdetailseite
• Produktfilter
• Newsletter-Anmeldung
• Downloadbereich
• Cookie-Banner
• zentrale Landingpages

Die Startseite allein reicht selten aus. Viele echte Barrieren entstehen dort, wo Menschen etwas tun müssen: Formular ausfüllen, Produkt kaufen, Termin buchen, ein Konto anlegen oder Informationen herunterladen.

Ein einfacher 10-Minuten-Check

Wenn du nur wenig Zeit hast, starte mit diesem Ablauf:

1. Automatischen Check starten
   Prüfe die Seite mit einem Tool wie barrieretest.at.
2. Maus weglegen
   Navigiere mit Tab, Shift + Tab, Enter und Space.
3. Fokus beobachten
   Ist immer sichtbar, wo du gerade bist?
4. Formular testen
   Fülle ein Formular absichtlich falsch aus. Sind Fehlermeldungen verständlich?
5. Überschriften prüfen
   Ergibt die Struktur der Seite Sinn?
6. Bilder ansehen
   Haben relevante Bilder sinnvolle Alt-Texte?
7. Screenreader kurz einschalten
   Höre dir an, wie die Seite klingt. Besonders wichtig: Navigation, Buttons, Formulare und Fehlermeldungen.

Dieser Test ersetzt keinen Audit. Aber er zeigt oft schneller als jede Diskussion, wo echte Probleme liegen.

Wann ein professioneller Audit sinnvoll ist

Ein manueller WCAG-Audit ist besonders sinnvoll, wenn:

• die Website geschäftskritisch ist
• ein Checkout, eine Buchung oder ein Login betroffen ist
• du B2C-Leistungen online anbietest
• BaFG- oder WCAG-Anforderungen relevant sein könnten
• du ein Redesign oder Relaunch planst
• bereits automatische Tests Probleme zeigen
• du eine priorisierte Liste mit konkreten Umsetzungsempfehlungen brauchst

Ein guter Audit ist nicht nur eine Liste von Fehlern. Er sollte erklären:

• welches Problem vorliegt
• welche Nutzer:innen betroffen sein können
• wie kritisch der Befund ist
• wie man ihn reproduziert
• wie er behoben werden kann
• welche Themen zuerst umgesetzt werden sollten

Die eigentliche Arbeit beginnt danach, und kann oft durch Expertenbegleitung wesentlich vereinfacht und beschleunigt werden.

Nächster Schritt

Wenn du einen ersten Überblick möchtest, starte mit einem automatischen Check:

Kostenlosen Barrierefreiheits-Check auf barrieretest.at starten

Wenn du wissen möchtest, welche Probleme wirklich kritisch sind und wie du sie sinnvoll behebst, ist eine manuelle Prüfung der nächste Schritt:

WCAG-Audit und Barrierefreiheitsprüfung bei Solasit ansehen