Accessibility im Webdesign – Ein praxisnaher Leitfaden

Stell dir vor, du baust ein schickes Café – mit cooler Einrichtung, gutem Kaffee, WLAN und allem drum und dran.

Nur: Der Eingang hat zehn Stufen, das Menü gibt’s nur auf Latein und die Bestellung funktioniert ausschließlich über Morsezeichen.

Klingt absurd? Willkommen im Internet, wie es für viele Menschen täglich aussieht.

Barrierefreiheit im Web – klingt erstmal nach Bürokratie oder Extraarbeit, oder? Tatsächlich geht’s dabei um etwas ziemlich Grundlegendes:
Dass alle Menschen deine Website nutzen können.

Egal ob mit Screenreader, mit zittriger Hand, bei Sonnenlicht auf dem Handy oder einfach mit weniger Geduld für unnötige Spielereien.

In diesem Artikel schauen wir uns an, was Accessibility wirklich bedeutet, warum sie viel mehr Menschen betrifft als du denkst – und wie du mit ein paar Tricks nicht nur netter zu deinen Nutzer:innen wirst, sondern auch Google, deiner Conversion und deinem Karma einen Gefallen tust. Los geht’s – barrierefrei natürlich!

Ziel der Barrierefreiheit ist es, Barrieren abzubauen, die manche Nutzer:innen sonst ausschließen würden.

Das umfasst zum Beispiel technische Barrieren (etwa eine Website, die ohne Maus nicht bedienbar ist), gestalterische Barrieren (wie Text in unzureichendem Kontrast), inhaltliche Barrieren (komplizierte Sprache oder fehlende Erklärungen) und auch Barrieren in den Werkzeugen (z.B. ein Video ohne Untertitel).

Kurz gesagt: Barrierefreies Webdesign stellt sicher, dass jeder – ob mit oder ohne Behinderung – auf die Inhalte und Funktionen einer Website zugreifen kann.

Warum ist Accessibility wichtig?

Reale Nutzungsszenarien:
Wer profitiert von Barrierefreiheit?

Am offensichtlichsten profitieren natürlich Menschen mit Behinderungen direkt von barrierefreien Websites.

Für eine blinde Person ist ein Onlineshop ohne korrekte Alternativtexte und Navigationsstruktur praktisch unbenutzbar – mit Barrierefreiheit hingegen kann sie problemlos einkaufen, indem ein Screenreader ihr alle Inhalte vorliest.

Eine gehörlose Person kann ein erklärendes Video auf deiner Website nur verstehen, wenn Untertitel oder ein Transkript vorhanden sind.

Jemand im Rollstuhl benötigt vielleicht keine speziellen technischen Hilfen zum Websurfen, profitiert aber von gut sichtbaren Fokusmarkierungen, um per Tastatur zu navigieren.

Nicht nur Menschen mit dauerhaften Behinderungen ziehen Nutzen aus Accessibility.

Temporäre Einschränkungen und situative Barrieren sind ebenfalls wichtige Szenarien:
Stell dir vor, du hast dir den Arm gebrochen – plötzlich bist du darauf angewiesen, Websites ohne Maus nur mit der Tastatur oder per Spracheingabe zu bedienen (ähnlich wie jemand mit motorischer Behinderung).

Oder denk an eine Umgebung mit grellem Sonnenlicht, in der du auf dem Handy kaum etwas erkennst – ein höherer Kontrast auf der Website wird jetzt zum Segen, fast so als hättest du eine Seheinschränkung. Auch ein langsames Internet oder ein kleines Smartphone-Display können ehemals triviale Dinge erschweren. Barrierefreie Websites federn solche Umstände besser ab​

Kurz:
Alle Nutzer:innen profitieren von einem zugänglichen, flexiblen Webdesign – sei es dauerhaft oder nur in bestimmten Situationen.

Auch ältere Menschen gewinnen durch Barrierefreiheit. Mit dem Alter lässt oft die Sehkraft nach, man wird vielleicht unsicherer im Umgang mit neuen Technologien oder reagiert empfindlicher auf animierte Inhalte. Eine Webseite, die für ältere Nutzer optimiert ist (größere Schriften, klare Sprache, einfache Bedienung), folgt fast immer den Prinzipien der Barrierefreiheit. Ebenso gibt es viele Menschen, die nicht mit digitaler Technik aufgewachsen sind („technikfern“) – auch ihnen kommen klare, verständliche und gut strukturierte Webseiten entgegen.

Rechtliche Anforderungen und Standards (WCAG, BITV, EU-Richtlinien)

Neben den vielen menschlichen Gründen gibt es auch handfeste rechtliche Anforderungen für Accessibility.

In vielen Ländern – so auch in Deutschland – sind öffentliche Stellen gesetzlich verpflichtet, ihre Websites und Apps barrierefrei zu gestalten. Grundlage dafür sind oft die WCAG-Standards. WCAG steht für Web Content Accessibility Guidelines, ein internationaler Richtlinienkatalog des W3C (World Wide Web Consortium). Die WCAG definieren technische und inhaltliche Erfolgskriterien für Barrierefreiheit und dienen weltweit als Referenzstandard​

In Deutschland konkretisiert die BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung) die gesetzlichen Pflichten. Sie verpflichtet Bundesbehörden und teilweise auch Landesbehörden, ihre Webangebote nach dem Stand der Technik barrierefrei zu machen​

Auf EU-Ebene gibt es seit 2016 die EU-Webseitenrichtlinie 2016/2102, welche für öffentliche Stellen Barrierefreiheit verbindlich vorschreibt. Sie wurde in Deutschland eben durch die BITV umgesetzt​

Darüber hinaus wurde 2019 der European Accessibility Act (EAA) beschlossen – ein europäisches Gesetz, das ab Juni 2025 auch viele private Unternehmen in die Pflicht nimmt. Der EAA verlangt, dass bestimmte Produkte und Dienstleistungen barrierefrei sein müssen, darunter zum Beispiel E-Books, Bankdienstleistungen, E-Commerce (Onlineshops) und Ticketing im Transportwesen​.

Das heißt, nicht nur Behörden, sondern z.B. auch Online-Händler, Banken oder Verkehrsbetriebe müssen künftig ihre digitalen Angebote für alle zugänglich machen.

Für Webdesigner:innen und Agenturen bedeutet das:

Accessibility ist nicht mehr optional, sondern wird zunehmend zur Pflicht.

Es lohnt sich also, frühzeitig Know-how aufzubauen, um den gesetzlichen Anforderungen gerecht zu werden – und um Abmahnungen oder Klagen vorzubeugen (in einigen Ländern wie den USA sind Klagen gegen nicht-barrierefreie Websites bereits häufig, und auch in Europa zieht die Durchsetzung an).

Accessibility als Qualitätsmerkmal –
Vorteile für alle

Unabhängig von gesetzlichen Vorgaben ist Barrierefreiheit aber auch ein echtes Qualitätsmerkmal und bringt viele Vorteile mit sich!

Eine barrierefreie Website ist meist besser strukturiert, durchdachter gestaltet und technisch sauberer umgesetzt – eben weil man auf Details wie sauberen Code, klare Navigation und verständliche Inhalte achtet.

Dies wirkt sich positiv auf die allgemeine Usability aus:

Alle Besucher – nicht nur Menschen mit Behinderung – finden sich leichter zurecht.

Ein Beispiel ist die zuvor erwähnte Tastaturnavigation:
Wenn das Menü mit der Tabulatortaste bedienbar ist und fokussierte Elemente deutlich hervorgehoben sind, freut das den Power-User ohne Maus ebenso wie den Benutzer eines Screenreaders.

Ein oft genannter Nebeneffekt ist SEO (Search Engine Optimization):
Barrierefreiheit und SEO gehen in vielen Bereichen Hand in Hand. Suchmaschinen sind im Grunde „blinde“ Nutzer – sie lesen den Code einer Seite aus, ähnlich wie ein Screenreader. Eine semantisch korrekte Überschriftenstruktur, ALT-Texte für Bilder und aussagekräftige Linktexte helfen nicht nur Screenreader-Nutzern, sondern auch Google & Co., den Inhalt besser zu verstehen.

Zudem führen barrierefreie Websites oft zu schnellerer Ladezeit und mobiler Optimierung, was ebenfalls Ranking-Faktoren sind. Studien zeigen, dass Unternehmen nach der Implementierung barrierefreier Funktionen verbesserte SEO-Leistungen und mehr Reichweite feststellen​

Barrierefreiheit kann also direkt die Sichtbarkeit deiner Website erhöhen.

Auch wirtschaftlich zahlt es sich aus, niemanden auszuschließen. Menschen mit Behinderungen machen einen bedeutenden Anteil der Bevölkerung aus (man spricht oft von ca. 15% der Menschen weltweit, die eine Form von Behinderung haben). In Deutschland sind es Millionen potenzieller Kund:innen, die durch Barrieren ggf. abwandern, wenn eine Website nicht nutzbar ist. Laut einer aktuellen Umfrage glauben 74% der befragten Unternehmen, bereits Kunden aufgrund fehlender Barrierefreiheit verloren zu haben​.

Umgekehrt berichten 38% über gesteigerte Umsätze oder bessere Conversion-Rates, nachdem sie Barrierefreiheit umgesetzt haben​.

Diese Zahlen verdeutlichen:

Man verzichtet auf Umsatz und Erfolg, wenn man Accessibility ignoriert.

Nicht zuletzt profitiert das Image. Eine Firma, die auf Barrierefreiheit achtet, zeigt Verantwortung und sendet ein positives Signal aus. Barrierefreiheit wird zunehmend als Teil von Corporate Social Responsibility gesehen – man zeigt, dass man alle Kunden wertschätzt. Unternehmen, die ihre Websites zugänglich gestalten, werden als sozial verantwortlich und fortschrittlich wahrgenommen​

Dies stärkt die Marke und kann auch in der PR-Kommunikation als Pluspunkt hervorgehoben werden.

Zusammengefasst:
Accessibility ist wichtig, weil es das Richtige ist (niemanden ausschließen), weil es gesetzlich gefordert ist und weil es praktische Vorteile für Benutzerfreundlichkeit, Reichweite und Geschäftserfolg bringt.

Barrierefreiheit sollte daher von Anfang an als Qualitätsmerkmal bei jedem Web-Projekt mitgedacht werden – nicht als lästige Pflicht, sondern als Chance, bessere Websites zu bauen.

Zielgruppen:
Für wen gestalten wir barrierefrei?

Wenn wir von barrierefreiem Webdesign sprechen, denken viele zuerst an blinde Menschen, doch die Zielgruppe ist viel breiter. Wer genau profitiert also von einer barrierefreien Gestaltung?

Menschen mit unterschiedlichen Beeinträchtigungen

Sehbehinderungen

Das Spektrum reicht von vollständiger Blindheit über starke Sehrest-Einschränkungen bis zu milderen Sehschwächen oder Farbenfehlsichtigkeit. Blinde Menschen nutzen Screenreader oder Braille-Ausgabegeräte, um Websites wahrzunehmen. Für sie sind Alt-Texte für Bilder unverzichtbar, ebenso eine klare Überschriften-Struktur.

Menschen mit Sehrest vergrößern oft die Darstellung oder nutzen hohe Kontraste – hier helfen flexible Layouts und kontrastreiche Farben. Farbfehlsichtige können bestimmte Farbkombinationen nicht unterscheiden; daher sollte Information nie nur durch Farbe vermittelt werden.

Hörbehinderungen

Gehörlose oder schwerhörige Menschen profitieren insbesondere bei Multimedia-Inhalten von Barrierefreiheit. Videos sollten Untertitel haben, damit auch ohne Ton alle Informationen ankommen. Für Audio-Inhalte sind Transkripte wichtig. Akustische Hinweise auf Websites sollten immer durch sichtbare Hinweise ergänzt werden.

Motorische Einschränkungen

Hierzu zählen Menschen, die aufgrund einer Behinderung oder Krankheit die Hände oder Arme nicht gut nutzen können. Für sie ist die Tastaturbedienbarkeit einer Website oft entscheidend – viele nutzen entweder nur die Tastatur oder Spezial-Eingabegeräte.

Barrierefreies Design sorgt für ausreichend große Klickflächen, vermeidet aufwändige Drag-and-Drop-Interaktionen und stellt sicher, dass alles auch ohne Maus erreichbar ist.

Kognitive Beeinträchtigungen

Diese heterogene Gruppe umfasst Menschen mit Lernschwierigkeiten, geringer Literacy, geistigen Behinderungen oder mit Aufmerksamkeits- und Konzentrationsstörungen. Für diese Nutzer:innen ist verständliche Sprache extrem wichtig – komplizierte Schachtelsätze und Fachbegriffe können eine unüberwindbare Barriere darstellen.

Hier hilft es, Inhalte klar zu gliedern und in leicht verständlichen Worten zu schreiben. Auch Übersichtlichkeit und Vorhersehbarkeit der Seite spielen eine Rolle: Eine konsistente Navigation, eindeutige Beschriftungen und das Vermeiden überladener Layouts können Menschen mit kognitiven Einschränkungen das Leben enorm erleichtern

Temporäre Einschränkungen & situative Barrieren

Wie schon angedeutet, können alle Menschen zeitweise in Situationen geraten, in denen sie eingeschränkt sind. Man spricht hier auch von temporären Behinderungen oder situativen Einschränkungen.

Einige Beispiele:

• Jemand mit Armbruch oder Verletzung kann vielleicht 6 Wochen lang keine Maus bedienen – plötzlich ist man auf Keyboard-Navigation oder Sprache angewiesen.
• In einer lauten Umgebung (z.B. im Zug neben lautem Gespräch) versteht man den Ton eines Videos nicht – hier hilft ein Untertitel genau so wie bei einer Person, die gar nicht hören kann.
• Im hellen Sonnenlicht auf dem Smartphone-Screen ist der Kontrast schlecht – wer hier einen höheren Kontrastmodus nutzen kann oder dank guter Farbwahl trotzdem etwas erkennt, hat einen Vorteil (das gleicht einer Sehschwäche).
• Schlechtes Netz oder begrenztes Datenvolumen kann auch zur Barriere werden: Wenn eine Seite nur als 5-MB-Video präsentiert wird ohne Textalternative, schaut jemand mit Edge-Verbindung in die Röhre. Eine barrierefreie (und damit meist auch performant gebaute) Website lädt dagegen auch unter schlechten Bedingungen brauchbar.

Situative Faktoren sind wichtig, um Kund:innen nicht zu verlieren – eine Website sollte z.B. auch offline einigermaßen funktionieren oder zumindest Fehlermeldungen sinnvoll anzeigen, damit Nutzer mit instabiler Verbindung nicht frustriert abbrechen. Solche Aspekte überschneiden sich mit technischer Qualität und Responsive Design, sind aber Teil eines ganzheitlichen barrierefreien Ansatzes.

Ältere Nutzer und technikferne Zielgruppen

Die Bevölkerung altert, und mit zunehmendem Alter treten oft leichte Einschränkungen in Kombination auf:
das Sehvermögen lässt nach, das Hörvermögen evtl. auch, motorische Geschicklichkeit vielleicht ebenso (die Hand zittert etwas mehr, die Treffsicherheit mit der Maus nimmt ab).

Ältere Menschen sind deshalb eine Kernzielgruppe für Barrierefreiheit. Sie profitieren von größerer Schrift, guten Kontrasten, klarer Struktur und auch von unterstützenden Technologien (viele kennen z.B. die Zoom-Funktion im Browser oder spezielle Lesebrillen für den Computer).

Gleichzeitig sind nicht alle Älteren in Technikfragen versiert. Eine barrierefreie Seite sollte daher auch intuitiv sein – keine überfordernden Interaktionen verlangen und zum Beispiel auf allzu spielerische Interface-Gimmicks verzichten. Ein schlichtes, klar verständliches UI ist hier gold wert.

Technikferne Nutzer:innen – das müssen nicht unbedingt ältere Menschen sein – können z.B. auch jüngere Leute sein, die einfach wenig Erfahrung mit dem Web haben oder Angst haben, „etwas falsch zu machen“. Ihnen hilft ein barrierefreies, fehlertolerantes Design. Das heißt, wenn jemand z.B. ein Formular falsch ausfüllt, sollten klare Fehlermeldungen auftauchen und erklären, was zu tun ist (anstatt die Person mit kryptischen roten Markierungen alleine zu lassen). Solche Hilfestellungen kommen wiederum allen zugute, aber besonders denen, die sich unsicher fühlen.

Fazit für die Zielgruppen:
Barrierefreiheit im Webdesign richtet sich nicht an einen kleinen Personenkreis, sondern an eine breite Palette von Nutzenden. Von dauerhaft behinderten Menschen über temporär eingeschränkte bis hin zu Älteren oder Unerfahrenen – jedes zusätzliche Quäntchen Barrierefreiheit öffnet deine Website für mehr Menschen.

Anstatt zu fragen „Wie viele Blinde besuchen schon meinen Online-Shop?“, sollte man erkennen, dass Barrierefreiheit universelle Design-Grundsätze bedeutet:

Mach es robust, flexibel und verständlich – dann machst du es automatisch für alle besser.

Grundprinzipien der barrierefreien Webgestaltung (WCAG)

Die WCAG-Richtlinien basieren auf vier grundlegenden Prinzipien, auch bekannt unter dem Akronym POUR: wahrnehmbar (perceivable), bedienbar (operable), verständlich (understandable) und robust (robust). Diese Säulen bilden das Fundament barrierefreier Websites und sind in der EU-Richtlinie sowie der BITV verankert.

Wahrnehmbar

Alle Informationen und Elemente einer Website müssen für Nutzer:innen sinnlich erfassbar sein. Ein Screenreader-Nutzer benötigt Alternativtexte für Bilder, während farbenblinde Personen mehr als nur Farbkodierungen brauchen – etwa zusätzliche Symbole oder Muster in Diagrammen. Was für Sehende selbstverständlich erscheint, erfordert für andere alternative Wahrnehmungswege.

Bedienbar

Jedes Element einer Website muss unabhängig von körperlichen Einschränkungen bedienbar sein. Besonders wichtig ist die Tastaturbedienbarkeit: Alle Funktionen müssen auch ohne Maus nutzbar sein. Wenn ein Dropdown-Menü oder ein Slider keinen Tastaturfokus erhält, bleibt es für viele Nutzer:innen unerreichbar. Bedienbarkeit bedeutet auch, dass Websites keine zeitkritischen Reaktionen erzwingen oder durch hektische Animationen die Orientierung erschweren sollten.

Verständlich

Sowohl Inhalte als auch Bedienkonzepte müssen leicht verständlich sein. Nutzer:innen sollten intuitiv erfassen, was gemeint ist und wie etwas funktioniert. Verständlichkeit baut kognitive Barrieren ab – niemand sollte rätseln müssen, was ein Begriff bedeutet oder wie die Navigation funktioniert. Regelmäßige Tests mit echten Nutzern helfen, betriebsblinde Formulierungen zu erkennen und zu korrigieren.

Robust

Die technische Basis muss stabil und kompatibel sein. Eine Website sollte von verschiedenen Browsern und assistiven Technologien wie Screenreadern korrekt interpretiert werden können. Robustheit ist das Fundament: Selbst die besten Alternativtexte und Untertitel nützen nichts, wenn die Webapplikation im Browser abstürzt oder mit Screenreadern nicht funktioniert. Sauberer Code ist daher essenziell für echte Barrierefreiheit.

Diese vier Prinzipien greifen ineinander und schaffen gemeinsam die Grundlage für ein Web, das wirklich für alle zugänglich ist.

Praktische Umsetzung in Design und Code

Jetzt wird’s konkret: Wie setzt du Accessibility ganz praktisch um? In diesem Abschnitt gehen wir durch wichtige Bereiche wie Farbgestaltung, HTML-Struktur, Navigation, Formulare, Medien und mehr. Ziel ist es, dir praxisnahe Tipps zu geben, die du direkt im nächsten Projekt anwenden kannst.

Tipp:
Du musst nicht sofort alles perfekt machen. Schon kleine Verbesserungen in diesen Bereichen können die Zugänglichkeit deutlich erhöhen. Schnapp dir einen Bereich nach dem anderen.

Farbwahl und Kontraste richtig einsetzen

Farben sind ein zentrales Designelement – und sie spielen in der Barrierefreiheit eine große Rolle. Zwei Hauptpunkte solltest du beachten: ausreichender Kontrast und keine alleinige Informationsvermittlung über Farbe.

Kontrast prüfen:

Text und wichtige grafische Elemente sollten sich deutlich vom Hintergrund abheben. Die WCAG geben hierfür klare Messwerte vor: Für Fließtext wird ein Kontrastverhältnis von mindestens 4,5:1 empfohlen (Level AA)​

Für großen Text (ab 18pt bzw. 14pt fett) genügt 3:1. Wie misst man das? Es gibt Tools wie den WebAIM Contrast Checker oder Browser-Plugins (z.B. in den Chrome DevTools oder in Firefox die Accessibility-Ansicht), wo du Vorder- und Hintergrundfarbe eingibst und den Kontrastwert erhältst. Beispiel: Schwarzer Text auf weißem Grund hat 21:1 (maximal), hellgrau (#aaa) auf weiß hat nur ~2.5:1 – deutlich zu wenig. Auch für Grafiken und Icons gilt: wenn sie essentiell sind, achte auf Kontrast.

(Beispiel: Ein Screenshot eines Contrast-Checker-Tools mit zwei Farbwerten könnte hier veranschaulichen, wie man das Verhältnis prüft.)

Farbenblindheit mitdenken:

Nicht alle Menschen nehmen Farben gleich wahr. Bei Rot-Grün-Schwäche etwa kann Rot nicht gut von Grün unterschieden werden. Wenn du also z.B. ein Diagramm mit roten und grünen Balken erstellst, wäre das allein problematisch. Verwende zusätzliche Kennzeichnungen – unterschiedliche Muster, direkte Beschriftungen der Balken oder Symbole. Es gibt Tools, mit denen du deine Seite in verschiedenen Farbfehlsichtigkeits-Ansichten betrachten kannst (z.B. die Chrome-DevTools haben einen Emulator für Farbenblindheit, oder Online-Tools wie Coblis). So erkennst du, ob noch genügend Unterschied erkennbar ist. Ein einfaches Mittel: Verwende nicht Farbton alleine, sondern spiele mit Helligkeit und Sättigung. Ein dunkelblauer und ein hellorangefarbener Bereich sind auch in Graustufen noch unterscheidbar, ein mittleres Rot und Grün dagegen könnten in Graustufen fast gleich aussehen.

Keine Information nur über Farbe:

Stell dir ein Formular vor, bei dem ein Pflichtfeld, das vergessen wurde, rot umrandet wird – aber ohne weitere Erklärung. Ein farbenblinder oder auch ein Screenreader-Nutzer (für den Farbinformation nicht verfügbar ist) würde diesen Hinweis verpassen. Besser ist: zusätzlich ein Icon oder Text „Bitte ausfüllen“ anzeigen. Genauso in Tabellen oder Grafiken: Nicht nur „die rote Linie bedeutet X, die blauge Linie Y“ im Text schreiben, sondern z.B. die Linien direkt beschriften oder unterschiedlich zeichnen (Strichlinie vs. durchgezogen).

Als Designer:in kannst du dir angewöhnen, den Kontrast schon im Styleguide zu berücksichtigen. Definiere Farbpaare, die geprüft sind. Es gibt Plugins für Figma, Sketch etc., die Kontraste prüfen. Ebenso kannst du mit Designsystemen arbeiten, die Farben vordefiniert haben (meist mit entsprechenden WCAG-Hinweisen). Und natürlich: Teste auch mal selbst. Lass jemanden mit Sehschwäche oder in ungünstiger Beleuchtung auf dein Design schauen.

Struktur und Semantik: HTML sauber nutzen

Eine der mächtigsten Zutaten für Barrierefreiheit ist kostenlos und liegt direkt vor uns: HTML-Semantik. HTML bietet von Haus aus eine Reihe an Elementen, die – richtig eingesetzt – deiner Seite sofort mehr Zugänglichkeit verleihen, ohne dass du viel Extraaufwand hättest.

Was bedeutet semantisches HTML? Es heißt, dass du Elemente entsprechend ihrer inhaltlichen Bedeutung wählst, nicht nur nach Optik. Viele Entwickler:innen haben beispielsweise den Reflex, <div> und <span> für alles zu nutzen und das Design komplett via CSS zu machen. Visuell klappt das, aber semantisch weiß kein Mensch (bzw. kein Computer) mehr, was was ist.

Hier ein paar Best Practices:

• Überschriften-Hierarchie:
  Verwende <h1> bis <h6> für Überschriftenebenen. Jede Seite sollte idealerweise eine <h1> (Hauptüberschrift) haben, und darunter Überschriften in logischer Reihenfolge. Nicht zur Optik die Reihenfolge mischen (also nicht <h3> nehmen, weil es kleiner aussieht, obwohl es eigentlich eine Hauptüberschrift wäre – lieber CSS zum Stylen nutzen). Eine gute Überschriftenstruktur ist wie das Inhaltsverzeichnis des Webs. Screenreader können sich eine Liste der Überschriften ausgeben lassen. Wenn diese Struktur klar ist, verschafft das allen Nutzern Überblick.
• Listen, Tabellen, Zitate:
  Nutze <ul>/<ol> für Aufzählungen, nicht einfach Zeilenumbrüche mit Bullet-Symbolen. Nutze <table> für tabellarische Daten, nicht CSS-Grid mit Divs – sonst fehlt die row/col Zuordnung für Screenreader. Verwende <blockquote> für Zitate, <q> für kurze Zitate im Fließtext, <cite> für Quellen usw. Jedes dieser Elemente trägt Bedeutung in sich (z.B. ein Screenreader könnte ein <blockquote> mit „Zitat“ ankündigen).
• Formularelemente korrekt verwenden:
  <label> gehört zum <input> (via for-Attribut bzw. um das Input herum gruppiert). Überschriften (<legend>) für Gruppen von Feldern in einem <fieldset>, z.B. bei Radiobutton-Gruppen. Buttons mit <button> (oder <input type="submit">) statt Divs mit Klick-Events. All das gewährleistet, dass Browser und Hilfsmittel die Funktion erkennen („Ah, hier ist ein Formularfeld mit Beschriftung XY“).
• Bereiche und Landmarks:
  HTML5 brachte Elemente wie <nav>, <main>, <header>, <footer>, <aside> – nutze sie. Sie helfen, Bereiche der Seite zu kennzeichnen (Navigation, Hauptinhalt, Randnotizen etc.). Für Screenreader werden dadurch sogenannte Landmarks verfügbar. Nutzer können z.B. schnell zur Navigation springen oder zum Hauptinhalt, wenn diese Bereiche entsprechend markiert sind. Falls du kein HTML5 nutzen kannst/darfst, kannst du zumindest ARIA-Rollen (role="navigation", role="main" etc.) setzen – aber in modernem HTML5 ist das oft schon eingebaut bei den genannten Elementen.
• Keine Layout-Tables oder redundante Divs:
  Früher war es üblich, Layout mit Tabellen oder verschachtelten Divs zu stricken. Heute geht das mit CSS deutlich besser. Jede unnötige Verschachtelung erschwert die Accessibility (und auch die Wartbarkeit). Versuche, HTML so klar und flach wie möglich zu halten. Eine Überschrift, dann ein Abschnitt, vielleicht unterteilt in Artikel etc., aber nicht fünf Ebenen von Containern ohne Not.

Ein Beispiel für gute Semantik: Stell dir einen Blogartikel vor. Du könntest ihn so strukturieren:

<article>
  <header>
    <h1>Mein Blogpost</h1>
    <p>31. März 2025 – von Max Mustermann</p>
  </header>
  <section>
    <h2>Einleitung</h2>
    <p>...Text...</p>
  </section>
  <section>
    <h2>Hauptteil</h2>
    <p>...Text...</p>
  </section>
  <footer>
    <p>Kategorie: Webdesign</p>
  </footer>
</article>

Mit solcher Strukturierung können Screenreader-Nutzer oder auch Google die Zusammenhänge viel besser erkennen als mit einer anonymen Div-Suppe. Das kostet dich kaum mehr Aufwand, bringt aber viel Nutzen.

(Hinweis: Hier könntest du ein Code-Snippet oder einen Screenshot aus den Entwickler-Tools zeigen, der eine Überschriftenstruktur oder Landmarks visualisiert. Beispielsweise das Firefox-Accessibility-Panel, das die Strukturebene einer Seite anzeigt.)

Barrierefreie Navigation (Tab-Reihenfolge, Fokus, Skip-Links)

Die Navigation einer Website ist oft der erste Ort, an dem Accessibility auffällt – ob positiv oder negativ. Wenn ein Nutzer mit Tab nicht mal zum Menü kommt, oder wenn er sich mit 20 Tabs durch zig Menüpunkte quälen muss, bevor er zum Inhalt gelangt, ist das frustrierend. Hier ein paar Punkte, um die Navigation zugänglich zu gestalten:

• Logische Tab-Reihenfolge:
  In den meisten Fällen ergibt sich diese aus dem DOM (Document Object Model), also der Reihenfolge im HTML. Das heißt: Achte bereits beim Code darauf, dass die Reihenfolge der interaktiven Elemente (Links, Buttons, Formulare) im HTML der visuellen Reihenfolge entspricht. Wenn du mit CSS absolute Positionierung ein wildes Layout baust, bei dem das HTML durcheinander gewürfelt ist, kriegen Tastaturnutzer Kopfschmerzen. Falls die natürliche Reihenfolge mal nicht passt, gibt es das Attribut tabindex – aber benutze es sparsam. Ein positives tabindex kann Elemente in die Tab-Reihenfolge bringen, die im HTML woanders stehen. Das ist aber schwierig zu pflegen, daher lieber HTML gleich richtig anordnen. Ein tabindex="-1" kann nützlich sein für Elemente, die fokussierbar sein sollen, aber nicht in der normalen Reihenfolge (z.B. modale Dialoge).
• Skip-Links (Sprungmarken):
  Ein Skip-Link ist ein versteckter Link am Anfang der Seite, der z.B. „Zum Inhalt springen“ heißt. Er wird sichtbar, sobald er fokussiert wird (per Tab erreicht). Mit Enter springt man dann direkt zum Hauptinhalt (z.B. an eine id="main" in deinem <main>-Bereich). Das erspart Tastaturnutzern und Screenreader-Nutzern, jedes Mal durch die ganze Navigation zu tabben, um zum Content zu kommen​bfit-bund.de. So ein Skip-Link ist einfach zu implementieren: Ein <a href="#main" class="skip-link">Zum Inhalt springen</a> am Seitenanfang, der per CSS position:absolute; left:-999px; aus dem Sichtfeld genommen wird, aber mit :focus sichtbar gemacht wird (z.B. eingeblendet oben). In vielen Frameworks oder CMS-Templates ist das schon drin, falls nicht: baue es ein, es ist wirklich ein großer Mehrwert.
• Mega-Menüs und Dropdowns:
  Komplexe Menüs müssen ebenfalls zugänglich sein. Wenn ein Menü per Hover ausklappt, sorge dafür, dass es auch per Tastatur ausklappt (z.B. via Fokus oder per Enter auf den Hauptmenüpunkt). Innerhalb des Menüs sollte man mit Pfeiltasten navigieren können (das geht dann schon in ARIA-Patterns rein, es gibt aber Best Practices dafür). Wichtig: Wenn das Menü ausgeklappt ist, schließe es entweder mit ESC oder wenn der Fokus den Menübereich verlässt. Nichts ist schlimmer als ein Tastaturnutzer, der aus Versehen ein Menü öffnet und dann nicht mehr raus findet, weil der Fokus in den Hintergrund nicht mehr erreichbar ist (Fokus-Falle).
• Fokus sichtbar, auch im Menü:
  Wie schon erwähnt: Der Fokusindikator (Focus Ring) muss gut sichtbar sein. Gerade in Menüs passiert es oft, dass Designer das Outline entfernt haben. Wenn dem so ist, setze wenigstens einen deutlichen Stil via CSS: z.B. .nav a:focus { outline: 2px solid #000; outline-offset: 2px; } oder eine Hintergrundmarkierung.
• ARIA für Navigation nutzen:
  Navigationslisten (z.B. ein <ul> mit Menüeinträgen innerhalb einer <nav>) können mit ARIA-Attributen wie aria-current="page" kenntlich machen, welcher Menüpunkt gerade aktiv ist (für Screenreader wird dann z.B. „Aktuelle Seite: Startseite“ gesagt). Auch aria-label am <nav> kann sinnvoll sein, falls mehrere Navigationsbereiche existieren, um sie zu benennen (z.B. aria-label="Hauptmenü" und aria-label="Fußnoten-Navigation").
• Breadcrumbs und Wegweiser:
  Falls du Brotkrumen-Navigation oder „Sie sind hier:“ Hinweise hast, gestalte sie ebenfalls semantisch (Liste von Links) und für Screenreader eventuell mit aria-label oder verstecktem Text klar („Navigationspfad:“) kenntlich machen. Das hilft bei der Orientierung.

Navigation ist das A und O – wenn man sich auf deiner Seite nicht zurechtfindet oder nicht hinkommt, wo man will, nützt der beste Inhalt nichts. Teste deshalb die Navigation immer mal wieder selbst mit der Tastatur: Komme ich überall hin? Wird etwas übersprungen? Bin ich irgendwo gefangen? Das sind wichtige Fragen.

(Möglicher Screenshot: Der sichtbar gemachte Skiplink „Zum Inhalt springen“ am oberen Rand einer Website, der beim Tab-Fokus erscheint.)

Formulare zugänglich machen

Formulare sind interaktive Herzstücke vieler Websites (Kontaktformulare, Bestellprozesse, Logins usw.), und sie bergen leider oft viele Barrieren. Hier einige Tipps, um Formulare barrierefrei zu gestalten:

• Jedem Feld sein Label:
  Ein triviales, aber häufig versäumtes Prinzip: Jedes Eingabefeld (<input>, <select>, <textarea>) braucht ein zugeordnetes <label>. Der sichtbare Label-Text (z.B. „E-Mail-Adresse“) hilft allen Nutzern, das Feld zu verstehen. Für Screenreader ist das Label noch wichtiger, da es damit das Feld ankündigt („Eingabe E-Mail-Adresse, Textfeld“). Die Verknüpfung passiert entweder über ein for-Attribut im Label, das auf die id des Feldes zeigt, oder indem man das Feld direkt innerhalb des <label> verschachtelt. Beide Methoden sind valide. Beispiel:

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

• Ohne korrektes Label würde ein Screenreader nur „Eingabefeld, Text“ ansagen, was natürlich unbrauchbar ist. Visuell sollte das Label in unmittelbarer Nähe des Feldes stehen (üblich: darüber oder links davon).
• Platzhalter nicht als Ersatz für Label:
  Oft werden Placeholder (der grau eingetragene Beispieltext im Feld) benutzt, um sich das Label zu sparen. Das ist aus mehreren Gründen schlecht: Der Platzhalter verschwindet, sobald man tippt – jemand mit kognitiven Problemen weiß dann vielleicht nicht mehr, was hier einzutragen war. Außerdem lesen Screenreader den Placeholder in der Regel nicht automatisch vor. Also: Placeholder höchstens als ergänzenden Hinweis nutzen („z.B. +49 123 456789“), aber nie statt einer Feldbeschriftung.
• Gruppiere zusammengehörige Felder:
  Wenn sich mehrere Inputs auf eine Sache beziehen (klassisches Beispiel: Radio-Buttons für eine Auswahl „Herr/Frau/Divers“, oder Checkboxen „Ich akzeptiere die AGB“), verwende <fieldset> und <legend>. Der Legend-Text dient als Gruppentitel (Screenreader lesen ihn beim Navigieren durch die Optionsfelder mit vor, sodass klar ist „Option 1 von X in Gruppe Y“). Visuell kann man Legenden gestalten (zur Not per CSS off-screen schieben, wenn es ins Design nicht passt, aber inhaltlich ist es wichtig).
• Fehlermeldungen klar und verbindend:
  Was passiert, wenn ein Formular fehlschlägt (z.B. Validierung)? Die Fehlermeldungen sollten textlich verständlich sein und am besten in Verbindung mit dem jeweiligen Feld stehen. Du kannst z.B. eine Liste aller Fehler oben anzeigen und bei jedem betroffenen Feld einen kleinen Fehlerhinweis (und das Feld rot hervorheben). Wichtig: Verbinde die Fehlermeldung per aria-describedby mit dem Feld oder platziere sie direkt im Label. aria-describedby="errorID123" am Feld und ein <div id="errorID123">Bitte geben Sie einen gültigen Wert ein</div> kann dafür sorgen, dass der Screenreader nach dem Feld auch die Fehlermeldung liest. Zusätzlich sollte der Fokus eventuell automatisch auf den ersten Fehler springen, damit der Nutzer nicht suchen muss.
• Hilfetexte und Hinweise:
  Ähnlich wie Fehlermeldungen können auch Hilfetexte (wie Formatvorgaben, Erklärung worum es geht) mit aria-describedby an das Feld gebunden werden. Beispiel: „Deine Telefonnummer (mit Ländervorwahl)“ kann im Label stehen und ein kleiner Text „Wir verwenden deine Nummer nur für Rückfragen.“ darunter mit aria-describedby verknüpft sein.
• Buttons eindeutig benennen:
  Statt einem generischen „Absenden“ kann ein spezifizierter Button-Text hilfreich sein, z.B. „Nachricht senden“ oder „Registrierung abschicken“. So wissen alle Benutzer besser, was passiert. Screenreader lesen auch den Button-Text laut vor.
• Keyboard-Reihenfolge und Fokus:
  Auch Formulare sollten in einer sinnvollen Reihenfolge durchtabbbar sein. Versteckte Felder (z.B. via CSS display:none) werden zum Glück automatisch übersprungen – gut so, denn sonst kämen Leute mit Tab an unsichtbare Elemente. Falls du live Inhalte einfügst (via JS z.B. zusätzliche Felder aufklappst), achte darauf, den Fokus nicht zu verlieren.
• Autocomplete nutzen:
  HTML5 bietet autocomplete-Attribute, um Browsern (und ggf. assistiven Tech) einen Hinweis zu geben, was für ein Feld das ist (z.B. autocomplete="email"). Das kann auch für Benutzer praktisch sein (der Browser schlägt was vor) und reduziert Fehlbedienung (was wieder Accessibility zuträglich ist).

Im Grunde gelten hier die gleichen Regeln wie sonst: Klarheit, Eindeutigkeit, Fehlertoleranz. Ein zugängliches Formular führt den Nutzer durch, statt ihn im Regen stehen zu lassen. Bonus-Tipp: Teste Formulare unbedingt mal nur mit der Tastatur und einem Screenreader. Dann merkst du schnell, wenn irgendwo ein Label fehlt oder die Reihenfolge merkwürdig ist.

(Ein Code-Beispiel oder Screenshot könnte hier hilfreich sein: z.B. HTML-Markup eines Formularfeldes mit Label und aria-describedby für einen Fehler, gegenübergestellt mit einer schlechten Variante ohne Label.)

Medien barrierefrei einbinden (Untertitel, Transkripte, Audio-Deskriptionen)

Multimediale Inhalte machen Websites lebendig – seien es Bilder, Videos, Audios oder interaktive Grafiken. Bei ihrer Einbindung sollte Barrierefreiheit mitgedacht werden, damit niemand vom Verständnis ausgeschlossen wird.

Bilder und Grafiken:

Für jedes informative Bild gilt die Regel:
Es braucht einen Alternativtext (im HTML das alt="..." Attribut). Dieser Text soll knapp beschreiben, was auf dem Bild zu sehen ist bzw. welche Funktion es hat.

Beispiel:
Ein Foto auf einer Team-Seite von dir könnte alt="Porträt von Max Mustermann" haben. Ein Icon, das als Button dient (z.B. ein Drucker-Icon für „Seite drucken“), sollte alt="Seite drucken" haben oder noch besser ganz ohne Bild als echter Button mit Text umgesetzt sein. Ist das Bild nur dekorativ (trägt also keine wichtige Info, z.B. ein rein ästhetischer Hintergrund), dann lässt man alt="" (leer) – der Screenreader überspringt es dann. Vorsicht: Lass das alt nie ganz weg, denn dann wird der Dateiname u.U. vorgelesen, was unschön ist. Also entweder sinnvollen Text oder bewusst alt="" für Deko-Bilder.

Videos:

Hier kommen gleich mehrere Anforderungen:

• Untertitel (Captions) für hörgeschädigte Menschen:
  Diese sollten alle gesprochenen Worte und relevante Sounds enthalten. Ideal ist es, wenn Videos einen Umschalter für Untertitel haben oder auf Plattformen wie YouTube gehostet sind, wo man die Untertitel anstellen kann. Du kannst Untertitel z.B. in HTML5 mit <track kind="subtitles" ...> einbinden.
• Transkript:
  Das ist eine Textversion des Videos. Warum Transkript, wenn es doch Untertitel gibt? Ein Transkript listet im Fließtext alle Dialoge und Beschreibungen der visuellen Handlung auf. Es hilft z.B. auch Leuten, die das Video nicht abspielen können (schlechtes Netz) oder schnell nach einer bestimmten Info darin suchen wollen. Zudem kann ein Transkript von Screenreadern vorgelesen oder mit Braille gelesen werden. Oft stellt man das Transkript direkt unter das Video als zusätzlichen Content bereit.
• Audiodeskription:
  Für wichtige visuelle Details, die in einem Video passieren (z.B. „der Täter hinterlässt am Tatort einen roten Koffer“ in einem Krimi), die aber nicht im Dialog erwähnt werden, brauchen blinde Nutzer eine Beschreibung. Manche Produktionen bieten gesprochene Audiodeskription auf einer zweiten Tonspur an. Im Web könnte man alternativ ein zweites Video mit integrierter Audiodeskription bereitstellen oder zumindest im Transkript solche visuellen Hinweise integrieren („[Im Bild ist zu sehen, wie …]“).
• Player-Bedienbarkeit:
  Der Videoplayer selbst muss auch zugänglich sein. Ein guter Web-Videoplayer lässt sich per Tastatur steuern (Play/Pause mit Leertaste, Buttons fokussierbar) und die Bedienelemente sind für Screenreader benannt (z.B. aria-label="Abspielen" am Play-Button). Hier hilft es, auf etablierte Lösungen zurückzugreifen, wie z.B. den HTML5-Standard-Player (die Browser-UI) oder Libraries, die Accessibility berücksichtigen (wie Video.js mit entsprechenden Plugins).

Audio (Inhalte ohne visuelle Komponente):

Bei reinen Audioinhalten (z.B. Podcasts) ist das Thema Untertitel irrelevant, aber ein Transkript ist wiederum sehr sinnvoll – für Gehörlose die einzige Möglichkeit, den Inhalt zu erfassen. Transkripte können hier auch direkt zum Download (z.B. als PDF/HTML) angeboten werden.

Andere Medien/Formate:

Denke auch an PDF-Dokumente oder eingebettete Widgets. PDF z.B. muss ebenfalls barrierefrei aufbereitet sein (Tags, Lesereihenfolge definieren, Alt-Texte für enthaltene Bilder etc.). Eingebettete Social-Media-Widgets oder Karten sollten zumindest einen Alternativzugang bieten (z.B. Link auf die Inhalte in Textform). Animierte Grafiken oder Canvas-Elemente sind knifflig – dort müsstest du individuell schauen, wie du die Info alternativ bereitstellst (z.B. ein Diagramm als Canvas gezeichnet -> zusätzlich eine datentabellarische Darstellung anbieten).

Im Alltag hilft es, sich folgende Frage bei jedem Medium zu stellen: „Was würde jemand mit Sinnesbeeinträchtigung jetzt davon mitbekommen?“ Wenn die Antwort ist „nichts“ oder „deutlich weniger als ein Sehender/Hörender“, dann musst du mit Alternativen nachlegen. Tools können übrigens automatisiert prüfen, ob Bilder ein Alt-Attribut haben, aber nicht, ob es sinnvoll ist – das bleibt deiner redaktionellen Sorgfalt überlassen.

Umgang mit ARIA: Do’s & Don’ts

Vielleicht hast du schon von WAI-ARIA gehört – das steht für Web Accessibility Initiative – Accessible Rich Internet Applications.

ARIA ist ein Satz von HTML-Attributen, mit denen man Elementen Rollen, Zustände und Eigenschaften zuweisen kann, um sie für assistive Technologien zugänglicher zu machen.

Beispiele:
role="dialog" um ein <div> als modales Dialogfenster zu markieren, aria-expanded="true/false" um den Zustand eines aufklappbaren Menüs anzugeben, aria-label="Mein Link" um einem Element einen unsichtbaren Beschreibungstext zu geben.

ARIA ist mächtig, aber man kann auch viel falsch machen. Hier die wichtigsten Leitlinien im Umgang mit ARIA:

• Native HTML first!
  Die oberste Regel: Verwende ARIA nur, wenn es ohne nicht geht. Viele Dinge lassen sich mit normalen HTML-Elementen erledigen, die von Hause aus zugänglich sind. Beispiel: Statt einen Klick-Listener auf ein <div> zu setzen und role="button" zu vergeben, nimm gleich ein <button> – das reagiert automatisch auf Enter/Leertaste, hat den richtigen Rollenwert und ist fokussierbar. Eine WAI-ARIA Devise lautet: „Don’t use ARIA when you can use HTML instead“​deque.com. Wenn man sich daran hält, vermeidet man schon viele Probleme.
• ARIA kann fehlendes HTML nicht 100% ersetzen:
  Manchmal muss man ARIA nutzen, z.B. für komplexe Widgets (eine Tabs-Navigation, modale Dialoge, Akkordeon-Komponenten). Hier solltest du dich an bewährte ARIA-Pattern halten. Das W3C dokumentiert in den ARIA Authoring Practices gängige Beispiele. Zum Beispiel: Für ein Tabs-Widget braucht es role="tablist" um die Gruppe zu markieren, jedes Tab hat role="tab" und ist mit aria-controls="IDdesTabPanels" dem zugehörigen Panel (role="tabpanel") zugewiesen, das aktive Tab hat aria-selected="true", etc. Solche Muster stellen sicher, dass ein Screenreader ansagt „Tab X von Y, ausgewählt“ und beim Wechseln entsprechend den Inhalt anzeigt. Wenn du eigene Widgets baust, studiere diese Patterns – oder nutze Frameworks/Bibliotheken, die das schon implementiert haben.
• Nicht doppelt moppeln:
  Ein häufiger Fehler ist, dass man mit ARIA etwas doppelt auszeichnet und dadurch Chaos stiftet. Beispiel: Du hast eine Überschrift <h2>Kontakt</h2>. Das ist bereits eine Überschrift für alle, Screenreader wissen das. Wenn du nun auf die Idee kämst, <h2 role="heading" aria-level="2">Kontakt</h2> hinzuzufügen, ändert sich faktisch nix, außer dass du mehr Code hast – im schlimmsten Fall irritiert es den Screenreader. Also: Nicht über-eifrig sein. ARIA sollte ergänzen, nicht duplizieren.
• aria-label und aria-labelledby gezielt einsetzen:
  Diese sind super nützlich, um z.B. einem Icon-Button ohne sichtbaren Text einen zugänglichen Namen zu geben (aria-label="Hilfe öffnen" an einem Fragezeichen-Icon-Button). Oder um komplexere Beschriftungen zusammenzusetzen (aria-labelledby="id1 id2" kann den Inhalt von zwei Elementen als Beschriftung kombinieren). Aber Vorsicht: Wenn ein Element sichtbaren Text hat, braucht es in der Regel kein aria-label, das würde den sichtbaren Text ersetzen. Beispiel: <button aria-label="Suche">🔍 Suchen</button> – hier würde der Screenreader nur „Suche“ sagen, das Icon und der Text „Suchen“ wären redundant. Besser: Das Icon per CSS als Hintergrund, oder wenn es ein SVG-Icon ist, ihm aria-hidden="true" geben, damit es den lesbaren Text nicht stört.
• aria-hidden="true" nur wenn wirklich verstecken gewollt:
  Dieses Attribut nimmt ein Element komplett aus der Wahrnehmung für Screenreader. Das ist manchmal nötig, z.B. um doppelte Informationen zu vermeiden (etwa in einem grafischen Chart will man vielleicht den visuellen Teil vor Screenreadern verstecken und nur die tabellarische Alternative zugänglich machen). Aber sei sehr vorsichtig: Wenn du aria-hidden an etwas setzt, was eigentlich Inhalt ist, wird es für blinde Nutzer unsichtbar. Klassiker: Ein Entwickler versteckt ein aufgeklapptes Menü im HTML (vielleicht weil es eine Weile sichtbar ist) per aria-hidden, vergisst es aber beim Öffnen auf false zu setzen – der Screenreader-Nutzer klickt Menü öffnen, sieht es visuell offen, aber der Screenreader findet keinen Inhalt (weil immer noch aria-hidden dran). Solche Fehler sind fatal.
• Live-Regionen sparsam verwenden:
  ARIA bietet mit aria-live die Möglichkeit, dynamische Content-Updates (z.B. AJAX-Ladespinner, Fehlermeldungen) ansagen zu lassen. Das ist super, z.B. um eine Validierungsfehlermeldung automatisch vorzulesen. Aber mach es nur dort, wo es sinnvoll ist – und stell das aria-live="assertive" (sofort laut) oder "polite" (wartet, bis der Nutzer gerade nix macht) bewusst ein, je nach Dringlichkeit. Und pack nicht zu viel rein, sonst redet der Screenreader ununterbrochen.

Zusammengefasst: ARIA ist so etwas wie ein scharfes Werkzeug – in den richtigen Händen behebt es Zugänglichkeitsprobleme, in den falschen schafft es neue. Wenn du unsicher bist, orientiere dich an zuverlässigen Quellen. MDN Web Docs hat gute Artikel zu ARIA, und das W3C stellt mit der ARIA-Practices-Doku konkrete Anleitungen bereit.

Mobile Accessibility

Heutzutage wird das Web zu einem großen Teil mobil genutzt – und auch hier gilt es, Barrieren abzubauen. Mobile Accessibility hat viel Überschneidung mit dem, was wir schon besprochen haben, aber es gibt ein paar zusätzliche Überlegungen:

• Touch-Ziele genügend groß:
  Auf Touchscreens ist es schwieriger, kleine Bedienelemente zu treffen, vor allem für Menschen mit motorischen Einschränkungen oder einfach größeren Fingern. Stelle also sicher, dass Buttons, Links, Checkboxen etc. groß genug sind (eine häufig genannte Mindestgröße ist etwa 44×44 Pixel für Touch-Targets). Wenn Elemente zu dicht nebeneinander liegen, kann das ebenfalls problematisch sein – also genug Abstand lassen.
• Bedienung mit Screenreader auf Mobilgeräten:
  Sowohl iOS (VoiceOver) als auch Android (TalkBack) haben eingebaute Screenreader. Deine mobile Website sollte damit navigierbar sein. Teste zum Beispiel auf einem iPhone mal deine Seite mit VoiceOver (Aktivierung unter Einstellungen > Bedienungshilfen). Das liest ähnlich wie am Desktop alles vor; Fokus erfolgt durch Wischen. Prüfe, ob alle interaktiven Elemente angesagt werden und logisch erreichbar sind.
• Zoom und Skalierung erlauben:
  Manche Entwickler versuchen, mit <meta name="viewport" content="user-scalable=no"> das Zoomen zu unterbinden, oft aus Designgründen. Das ist ein No-Go für Barrierefreiheit. Nutzer müssen zoomen dürfen, um Inhalte größer zu sehen. Also diese Einstellung vermeiden. Responsive Layouts sollten in sich flexibel sein, sodass auch mit Zoom nichts komplett auseinanderfällt.
• Kontraste und Farben im Sonnenlicht:
  Wie schon im Farbabschnitt erwähnt, ist gerade mobil das Thema hoher Kontrast wichtig, weil man öfter bei ungünstigen Lichtbedingungen das Gerät nutzt. Teste deine Farbpalette auch draußen oder simuliere den Graustufenmodus (den manche Telefone als „Bedienungshilfe“ anbieten, um Farbenblindheit zu simulieren).
• Onscreen-Tastatur und Formulare:
  Wenn ein Input den Typ hat (z.B. type="email" oder type="number"), zeigen Smartphones passende Tastaturen an (@-Zeichen verfügbar, Ziffernblock etc.). Das ist kein Muss für Barrierefreiheit, aber es erhöht die Usability enorm und verringert die Chance auf Fehleingaben (was wiederum Accessibility zugutekommt).
• Gesten-Alternativen:
  Mobile Web-Apps nutzen manchmal Touch-Gesten (Wischen, Pinch-Zoom, etc.). Bedenke, dass komplexe Gesten für viele schwierig sind. Mindestens sollten essentielle Aktionen nicht nur als Geste verfügbar sein (z.B. Menü öffnen nicht nur durch Wischgeste an der Seite, sondern auch per Button). In iOS gibt es z.B. AssistiveTouch, aber darauf sollte man nicht allein bauen – besser, die Web-App selbst bietet einfache Buttons als Alternative.
• Responsive vs. separate mobile Site:
  Falls du eine separate mobile Version hast, stelle sicher, dass alle A11y-Maßnahmen konsistent sind. Bei Responsive Design musst du hingegen aufpassen, dass Inhalte beim Umschalten nicht verschwinden oder unzugänglich werden (manche Designer verstecken z.B. auf Mobile bestimmte Inhalte – sorge dann dafür, dass diese wirklich verzichtbar sind oder biete zumindest eine Alternative an).

Das Gute: Wenn du die vorherigen Grundsätze (Kontrast, Fokus, etc.) einhältst, bist du auf Mobile schon weitgehend barrierefrei. Zusätzlich dann noch die Touch-Aspekte beachten, und natürlich auch mal auf echten Geräten testen. Denk auch an Tablets, die eine Mischform sind (mit Touch bedienbar, aber größerer Screen; manchmal im Desktop-Browser-Modus).

Tools und Tests:
Accessibility überprüfen

Niemand ist perfekt – selbst wenn du all diese Tipps beherzigst, kann sich irgendwo eine Barriere verstecken. Deshalb ist es wichtig, Webseiten mit einem Accessibility-Check zu prüfen. Glücklicherweise gibt es heute zahlreiche Tools und Methoden, die dich dabei unterstützen. Eine Kombination aus automatisierten Tests und manuellen Prüfungen hat sich bewährt.

Automatisierte Tools

Automatische Test-Tools können eine erste Bestandsaufnahme machen und offensichtliche Probleme finden. Sie sind schnell und einfach einzusetzen. Hier einige bekannte Werkzeuge:

• WAVE Web Accessibility Evaluation Tool
  Ein beliebtes kostenloses Tool (von WebAIM), das es als Online-Service und Browser-Extension gibt. WAVE zeigt visuell auf deiner Seite an, wo potenzielle Probleme liegen – z.B. markiert es fehlende Alt-Texte, zu niedrigen Kontrast, fehlende Formularlabels etc. Es liefert auch Erklärungen, warum etwas ein Problem sein könnte. (Website: wave.webaim.org)
• axe DevTools
  Ein von Deque Systems bereitgestelltes Testing-Tool, ebenfalls als Browsererweiterung (Chrome, Firefox) verfügbar. Mit einem Klick scannt es die Seite und listet Violations (Verstöße) gemäß WCAG auf. Axe hat den Ruf, sehr zuverlässig zu sein und wenige False Positives zu haben. Es integriert sich auch in viele Test-Frameworks (Selenium, Cypress etc.), falls du automatische Tests in die CI/CD-Pipeline einbauen willst.
• Lighthouse
  Eingebaut in Chrome (DevTools > Reiter „Lighthouse“ oder als eigenständiges Node-Tool). Lighthouse prüft u.a. auch Accessibility (neben Performance, SEO etc.) und gibt einen Score 0–100. Es spuckt eine Liste gefundener Probleme aus. Unter der Haube nutzt es ebenfalls teilweise axe. Der Score ist nett für einen groben Eindruck, aber wichtiger sind die konkreten Funde, die du beheben kannst.
• Weitere Scanner:
  Es gibt noch viele, z.B. Accessibility Insights (von Microsoft), Pa11y, Siteimprove Accessibility Checker, AChecker usw. Auch die Developer Tools von Firefox haben einen Accessibility-Tab, der Kontrastprobleme oder fehlende Texte anzeigt. Welches Tool du nutzt, ist gar nicht so entscheidend – Hauptsache, du nutzt überhaupt eins. Oft ist es Geschmacksache oder hängt vom Workflow ab (Browser-Plugin vs. CI-Tool etc.).

Wichtig ist zu wissen: Automatische Tools finden nicht alles. Sie entdecken vor allem technische und offensichtliche Mängel (z.B. kein Alt-Text, ARIA-Attribut falsch verwendet, Kontrast unter Schwelle). Aber Dinge wie „Ist der Alternativtext sinnvoll beschrieben?“ oder „Liest sich der Inhalt verständlich?“ können sie nicht beurteilen. Daher dienen sie als erste Orientierung, aber dürfen nicht deine einzige Prüfung sein.

Was sie jedoch super erledigen, ist Routinearbeit abnehmen. Auch in großen Projekten kannst du regelmäßig automatisiert scannen und bekommst einen „Wetterbericht“ der Barrierefreiheit, inkl. Verlauf, wenn du es trackst. Einige Tools können auch Reports erstellen, was praktisch für Kunden oder die Dokumentation ist.

(Tipp: Integriere einen solchen Checker bereits in der Entwicklungsphase. Viele IDEs/Editoren haben Plugins, die beim Coding schon Hinweise geben, z.B. bei fehlendem Alt-Attribut.)

Manuelle Tests mit Tastatur & Screenreader

Kein Tool der Welt ersetzt das eigene Ausprobieren, so solltest du als Entwickler:in oder Designer:in zumindest die Basics selbst testen:

Tastaturtest

Nimm die Hände weg von der Maus und versuche, deine Website nur mit der Tastatur zu bedienen. Kannst du alle Menüs öffnen, alle Links anklicken (mit Enter), alle Formularfelder erreichen und absenden? Bleibt nirgends der Fokus stecken? Falls du irgendwo nicht weiterkommst, hast du einen gravierenden Accessibility-Bug gefunden. Achte auch auf die Reihenfolge: Springt der Fokus logisch von oben nach unten, oder hüpft er z.B. plötzlich zum Footer und zurück? Letzteres deutet auf ungünstiges DOM oder tabindex-Missbrauch hin. Der Tastaturtest kostet nur wenige Minuten, deckt aber oft schon die schlimmsten Schnitzer auf.

Screenreader-Test

Dies erfordert etwas mehr Einarbeitung, lohnt sich aber sehr. Du musst nicht zum Profi-Screenreader-Nutzer werden, aber einmal deine Seite zu hören, öffnet die Augen (bzw. Ohren).

• Für Windows-PCs gibt es den kostenfreien NVDA (NonVisual Desktop Access). Den kannst du installieren und mit NVDA-Tastenkombinationen sowie Pfeiltasten durch die Seite navigieren. NVDA liest alles, was fokussiert wird, automatisch vor. Mit Tasten wie H springst du durch Überschriften, mit B durch Buttons etc. Probiere es mal aus: Navigiert NVDA deine Seite sinnvoll? Werden alle wichtigen Infos vorgelesen? Hört man, welches Element gerade fokussiert ist?
• Auf Mac ist VoiceOver bereits integriert. Du kannst es mit <kbd>Cmd + F5</kbd> aktivieren. Die Bedienung ist etwas anders (viel mit VO+Pfeil-Kombinationen), aber Apple hat gute Guides dazu, und online finden sich Tutorials. Für iPhone entsprechend in den Einstellungen > Bedienungshilfen aktivieren und dann mit typischen Gesten (Wischen rechts/links für nächstes Element, Doppeltipp zum „Klicken“) steuern.
• (Auf Android kannst du analog TalkBack testen.)

Wenn du das erste Mal mit einem Screenreader testest, wirst du vermutlich überwältigt sein (so viele Ansagen!). Das ist normal. Achte auf konkrete Dinge: Werden Bilder korrekt mit Alt-Text angekündigt? Haben Links sinnvolle Namen (kein „mehr lesen“ ohne Kontext)? Ist die Überschriftenstruktur intakt (du kannst dir z.B. alle Überschriften auflisten lassen)? Findet der Screenreader Formulareingabefehler?

Manuelle Tests zeigen dir auch Dinge, die ein Automat nicht merkt, z.B. ob eine Beschreibung sinnvoll ist. Sie machen die Benutzerperspektive erlebbar – was enorm lehrreich ist.

Checklisten und Praxis-Guides für dein Team

Gerade wenn man anfängt, ist es hilfreich, eine Checkliste zur Hand zu haben: Eine strukturierte Liste aller wichtigen Punkte zum Abhaken. Glücklicherweise gibt es hier einiges:

• Die WCAG-Checkliste:
  Entweder direkt beim W3C die Quick Reference (dort kann man auf Level AA filtern, Sprache Deutsch einstellbar) oder als herunterladbares Dokument. Allerdings ist die WCAG-Originalsprache manchmal etwas technisch/sperrig.
• Praxisorientierte Checklisten:
  z.B. die Schweizer Stiftung „Zugang für alle“ bietet eine sehr gute Accessibility-Checkliste 2.1 an, die in verständlicher Weise die notwendigen technischen, gestalterischen und redaktionellen Maßnahmen aufzeigt.
  Auch deutschsprachige Projekte wie barrierefreies.design stellen Checklisten bereit. Dort kann man Punkt für Punkt bewerten, wie barrierefrei die eigene Website ist.
• A11y Project Checklist (englisch):
  Das A11Y Project ist eine Community-Resource mit vielen Tipps. Sie haben eine bekannte Checklist (aktuell für WCAG 2.1), die alle Themen von Bildern über Navigation bis Struktur abdeckt.
• BITV-Test:
  In Deutschland gibt es den BITV-Test, der 60 Prüfschritte umfasst, angelehnt an WCAG 2.1 AA. Er ist sehr umfangreich, aber auch eine gute Lehrquelle – zu jedem Prüfschritt gibt es Erläuterungen. Man kann sich daran orientieren, um nichts Wichtiges zu vergessen.

Im Team könnt ihr solche Checklisten an eure Bedürfnisse anpassen. Macht euch vielleicht ein internes Wiki mit den wichtigsten Dos and Don’ts, konkreten Code-Beispielen („So sieht eine gute Fehlermeldung im Code aus“) und Tools, die ihr immer benutzt. So entsteht mit der Zeit euer eigener Accessibility-Guide, der in jedes neue Projekt einfließt.

Fazit & nächste Schritte für Webdesigner:innen und Agenturen

Barrierefreiheit im Webdesign mag zunächst überwältigend wirken – schließlich haben wir hier über so viele Aspekte gesprochen, von Farbe über Code bis zu Rechtlichem. Doch die wichtigste Erkenntnis ist: Accessibility ist machbar und lohnt sich. Du musst nicht über Nacht zum absoluten Experten werden. Fang mit kleinen Schritten an und integriere Barrierefreiheit Stück für Stück in deine Arbeit. Hier ein paar konkrete nächste Schritte:

• Accessibility von Anfang an mitdenken:
  Wenn du ein neues Projekt startest, plane Barrierefreiheit direkt ein, statt sie am Ende „draufzuschrauben“. Definiere im Design-Prozess schon Anforderungen (z.B. Farbkontrast, Font-Größen). In der Entwicklung lege gleich semantisches HTML an. Es ist viel einfacher, von Anfang an barrierefrei zu arbeiten, als später Fehler zu korrigieren.
• Nutze Checklisten und Tools regelmäßig:
  Mache es zur Gewohnheit, deine Entwürfe und Seiten mit den oben genannten Tools zu checken. Vielleicht baust du einen automatischen Accessibility-Test in euer Deployment ein, der Alarm schlägt, wenn z.B. neue Bilder ohne Alt-Text hinzugefügt wurden. Die Checkliste hilft dir beim Review von Websites – gehe sie z.B. durch, bevor ihr live geht.
• Schule dich und dein Team:
  Teile dein Wissen mit Kolleg:innen. Vielleicht kann man interne Workshops machen oder externe Trainer hinzuziehen, um wichtige Accessibility-Skills zu lernen. Oft hilft es auch, sich von Betroffenen berichten zu lassen – lade mal einen blinden User ein, der euch zeigt, wie er das Web nutzt. Das schafft Aha-Erlebnisse und motiviert, die eigenen Projekte zu verbessern.
• Kleine Maßnahmen – große Wirkung:
  Konzentriere dich zuerst auf ein paar Quick Wins. Zum Beispiel: Füge auf allen Websites einen Skip-Link ein. Prüfe die Farbpalette eurer Standard-Themes und passe sie an. Schreibt eine Richtlinie, dass jedes Bild ein Alt-Attribut bekommen muss. Solche einzelnen Punkte bringen schon viel Nutzen und sind schnell umgesetzt.
• Accessibility ins Daily Business integrieren:
  Accessibility sollte so normal werden wie Responsives Design oder Browser-Testing. Macht es zu einem festen Punkt in euren Abläufen: z.B. im Code-Review gibt es eine Check „Wurden alle Labels gesetzt?“. Oder in Design-Reviews fragt jemand „Erfüllen wir die Kontrastwerte?“. Wenn ihr agil arbeitet, nehmt Accessibility-Kriterien in die Definition of Done. Anfangs wirkt das vielleicht wie extra Aufwand, aber bald gehört es selbstverständlich dazu.
• Kunden überzeugen – Accessibility als Mehrwert verkaufen:
  Viele Auftraggeber denken nicht automatisch an Accessibility. Hier kommst du ins Spiel: Erkläre proaktiv die Vorteile (größere Reichweite, rechtliche Sicherheit, Imagegewinn, siehe Abschnitt 2). Untermauere deine Argumente gern mit Fakten oder Beispielen – etwa, wie andere Unternehmen durch Barrierefreiheit Erfolg hatten, oder dass ab 2025 ihr Onlineshop gesetzlich barrierefrei sein muss (Stichwort EAA). Wenn Kunden sehen, dass Barrierefreiheit kein „nice to have“, sondern ein Qualitätsmerkmal ist, sind sie eher bereit, dafür Budget und Zeit einzuplanen. Du kannst es auch so formulieren: Eine Website ohne Barrierefreiheit ist wie ein Ladenlokal ohne Rampe – man würde niemals die eigene Kundschaft bewusst ausschließen. Genauso verhält es sich online.

Zum Abschluss:

Barrierefreiheit ist ein Prozess, kein einmaliges Projekt.

Technologien ändern sich, Inhalte wachsen, neue Mitarbeiter kommen ins Team – man sollte die Accessibility einer Website immer mal wieder überprüfen und nachbessern. Aber keine Angst – wenn die Grundlagen stimmen, ist die Pflege nicht aufwändig. Im Gegenteil, barrierefreie Websites sind oft stabiler und zukunftssicherer, sodass du langfristig weniger Probleme hast.

Denke immer daran, warum du das tust: Damit alle Menschen die großartigen Websites, die du gestaltest, nutzen können. Es gibt kaum etwas Befriedigenderes als Feedback von jemandem, der dank deiner Arbeit Zugang zu Informationen oder Services hat, die ihm vorher verschlossen waren.

Barrierefreiheit öffnet Türen – mach mit und gestalte das Web ein Stück besser für alle!