Barrierefreie Webseiten umsetzen – Best Practices für Entwickler

Das Barrierefreiheitsstärkungsgesetz (BFSG) ist ab Juni 2025 in Kraft getreten. Es verpflichtet Anbieter digitaler Produkte und Dienstleistungen, diese barrierefrei zugänglich zu machen – dazu gehören auch Webseiten.

Grundlage dafür ist das Prinzip der vier Säulen der Web-Barrierefreiheit nach den WCAG-Richtlinien (Web Content Accessibility Guidelines):

• Wahrnehmbar: Inhalte müssen für alle Sinne zugänglich sein, z.B. hinsichtlich Farben, Kontrasten und Schriftgrößen
• Bedienbar: Inhalte müssen per Tastatur oder Assistenztechnik nutzbar sein.
• Verständlich: Inhalte und Navigation müssen klar und nachvollziehbar sein.
• Robust: Inhalte müssen mit möglichst vielen Geräten und Technologien funktionieren. Dazu gehören z.B. auch alte Browser

In diesem Artikel zeige ich die technischen Herausforderungen bei der Umsetzung barrierefreier Web-Oberflächen, insbesondere im Hinblick auf ARIA und UI-Komponenten.

Das BFSG selbst ist auf hoher Abstraktionsebene formuliert. Es verweist auf die EU-Norm EN 301 549, die wiederum die WCAG 2.1 als technischen Maßstab heranzieht. Das bedeutet: Webseiten müssen so gestaltet sein, dass sie den mittleren Konformitätslevel (AA) einhalten. Ob eine Webseite unter diese Richtlinie fällt, kann z.B. hier geprüft werden: https://bfsg-gesetz.de/check/

Schon bei der Auswahl oder Erstellung von UI-Komponenten kann viel für die Barrierefreiheit berücksichtigt werden.

Viele Entwickler stehen vor der Entscheidung: Nutze ich eine UI-Bibliothek wie Angular Material, PrimeVue oder Bootstrap, oder entwickle ich eigene Komponenten?
Letzteres bietet mehr Flexibilität, erfordert aber auch mehr Aufwand – insbesondere im Bereich Barrierefreiheit.

Frameworks und etablierte UI-Bibliotheken berücksichtigen viele Anforderungen automatisch: semantische Rollen, Fokusmanagement und ARIA-Attribute sind oft schon eingebaut.
Bei selbstgebauten Widgets musst du das manuell umsetzen – und hier kommt ARIA ins Spiel.

Ich erinnere mich noch an die erste Begegnung mit ARIA beim Bau einer Webseite. Damals erschien mir ein Vorschlag in einem Tutorial als Boilercode und ich entfernte die Direktiven aus Gründen der besseren Lesbarkeit. Die Bedeutung und Möglichkeiten wurden mir erst deutlich später bewusst.

ARIA steht für Accessible Rich Internet Applications. Es handelt sich um eine vom W3C empfohlene Spezifikation, die semantische Informationen zu HTML-Elementen hinzufügt – ohne das Layout zu verändern. ARIA richtet sich speziell an moderne, dynamische Webseiten mit benutzerdefinierten Widgets (z. B. Dropdowns, Tabs, Modals).

ARIA hilft bei der Umsetzung der vier Barrierefreiheitsprinzipien:

Wahrnehmbar

aria-label und aria-describedby helfen Screenreader-Nutzer, Informationen wahrzunehmen, die visuell vorhanden, aber technisch nicht sichtbar sind.

Codebeispiel:

<input type="text" aria-label="E-Mail-Adresse">

Bedienbar

aria-expanded, aria-controls, aria-haspopup helfen, interaktive Elemente wie Menüs, Dropdowns oder Tabs so zu kennzeichnen, dass sie tastatur- und screenreader-bedienbar sind und die Navigierbarkeit erhöht wird.

Codebeispiel:

<button aria-expanded="false" aria-controls="menu">Menü</button>

Verständlich

Durch aria-live, aria-invalid, aria-required werden dynamische Inhalte oder Formularzustände so kommuniziert, dass Nutzer Fehler und Rückmeldungen ohne visuelles Feedback verstehen können.

Codebeispiel:

<input aria-invalid="true" aria-describedby="error-msg">
<div id="error-msg">Dieses Feld darf nicht leer sein.</div>

Robust

ARIA hilft, nicht-native Komponenten (z. B. per JavaScript) so zu kennzeichnen, dass sie mit möglichst vielen Assistenztechnologien funktionieren. So bleiben sie zugänglich trotz unterschiedlicher Geräte, Browser oder Hilfsmittel.

Codebeispiel:

<div role="dialog"></div>

Das folgende Beispiel soll veranschaulichen, wie die ARIA-Attribute dabei helfen, UI-Komponenten barrierefrei aufzubauen. Ein selbstgebautes Dropdown benötigt mehrere ARIA-Attribute und Rollen, damit es verständlich und bedienbar wird:

<div 
  class="dropdown"
  role="combobox"
  aria-haspopup="listbox"
  aria-expanded="false"
>
  <button
    id="dropdown-button"
    aria-controls="dropdown-list">Auswahl treffen
  </button>

  <ul
    id="dropdown-list"
    role="listbox"
    tabindex="-1"
    aria-labelledby="dropdown-button">

    <li role="option" aria-selected="false">Option 1</li>
    <li role="option" aria-selected="false">Option 2</li>
    <li role="option" aria-selected="false">Option 3</li>
  </ul>
</div>

Die role zeigt auf, welche Funktion ein Element hat und wird von einem Screenreader entsprechend berücksichtigt. aria-haspopup=“listbox“ deutet darauf hin, dass es sich um ein erweiterbares Element handelt. Über tabindex=“-1“ lässt sich konfigurieren, dass das Element nicht per Tab erreicht werden kann, da der Button darüber die Funktion des Aufklappens übernimmt. aria-expanded und aria-selected sind aktuell auf "false" gesetzt und müssen entsprechend aktualisiert werden. Am besten über eine eigene Variable.

Wichtig ist dabei auch, die Tastatursteuerung (z. B. mit ArrowDown, Enter, Escape) über JavaScript umzusetzen, was hier aus Platzgründen weggelassen wurde.

Verwende, wenn möglich, etablierte UI-Bibliotheken, die Barrierefreiheit bereits berücksichtigen – und passe nur das Styling an, sofern es barrierefrei bleibt.

Wenn du eigene Komponenten baust, greife am besten auf semantisch passende HTML-Elemente zurück:

<!-- Statt einem selbstgebauten Kalender: -->
<input type="date" id="birthdate" name="birthdate"> 

Dadurch ersparst du dir viel ARIA-Logik – native Elemente sind bereits weitgehend barrierefrei.

Eigene ARIA Direktiven sind dann notwendig, wenn Standard-HTML nicht ausreicht. Typische Anwendungsfälle dafür sind:

• Eigene UI-Komponenten (Dropdowns, Tabs, Modals)
• Visuelle Labels durch Icons ersetzt
• Formulare, speziell Zustände wie Fehler oder Pflichtfelder anzeigen
• Dynamische Hinweise und Beschreibungen (Tooltips, Validierungen)

Beispiele:

<!-- Icon-only Button -->
<button aria-label="Suche">
  <svg><!-- Lupe --></svg>
</button>

<!-- Hinweis-Text -->
<input type="text" aria-describedby="hint">
<div id="hint">Geben Sie Ihre vollständige Adresse ein.</div>

Wer selbst keine Einschränkungen bei der Nutzung digitaler Medien erlebt, übersieht oft, wie viele Hürden es für andere Anwender gibt. Nachfolgend einige einfache Best practices die sich beim Testen der Barrierefreiheit bewährt haben.

1. Automatische Tests mit Lighthouse

Die Chrome-Erweiterung Lighthouse bietet eine schnelle Analyse der Barrierefreiheit mit konkreten Handlungsempfehlungen. Das Tool gibt einen sehr guten Überblick über die größten Baustellen auf der Seite und gibt an, zu wieviel % eine Seite barrierefrei ist.

2. Screenreader selbst ausprobieren

Nutze z. B. NVDA (Windows) oder VoiceOver (Mac) und lass dir deine Seite vorlesen. Ist die Struktur verständlich? Sind Schalter, Checkboxen etc. als solche erkennbar?

3. Tastaturtest

Lege die Maus beiseite:
Ist alles per Tastatur erreichbar (Tab, Enter, Escape, Pfeile)?
Kann man Formulare ausfüllen und Menüs bedienen?

Barrierefreiheit ist kein Nice-to-have, sondern ab Juni 2025 gesetzlich verpflichtend – und für Nutzer mit Einschränkungen essentiell. Unabhängig davon ist es ein gutes Gefühl, dass die eigene Webseite nun für deutlich mehr Menschen nutzbar ist.

Google schreibt dazu passend: "Barrierefreiheit im Internet ist für zehn Prozent der Bevölkerung unerlässlich, für mindestens 30 Prozent notwendig und für 100 Prozent hilfreich. Umgekehrt heißt das: wer seine Webangebote nicht barrierefrei gestaltet, schließt eine große Kundengruppe aus." (Quelle: blog.google)

Wer von Anfang an auf:

• gute UI-Praktiken
• semantisches HTML,
• und durchdachtes ARIA

achtet, spart sich später teure Nachbesserungen – und baut Webseiten, die für alle funktionieren.

Hast du bereits eine bestehende Webseite? Kein Problem wir bieten maßgeschneidertes Re-Engineering bestehender Softwarelösungen

---

Hier wurde ein kleiner Ausschnitt, der Möglichkeiten und Best Practices für Barrierefreiheit in der Softwareentwicklung gezeigt. Bereits im Design der Webseite kann vieles berücksichtigt werden, wie Kontrastverhältnisse, Farben oder Responsivität.

Welche Themen würdest du gerne noch sehen? An welcher Stelle hattest du die größten Herausforderungen?