Das europäische Gesetz zur Barrierefreiheit: Wie Du Deinen Online-Shop fit machst

Für uns bei Kiwee ist das Erstellen barrierefreier Websites seit jeher eine zentrale Mission. Wir sind überzeugt: Die digitale Welt sollte für alle offen sein. Mit der Richtlinie (EU) 2019/882, besser bekannt als European Accessibility Act (EAA), oder Rechtsakt zur Barrierefreiheit, die am 28. Juni 2025 in Kraft tritt, erhält dieses Prinzip nun auch eine breite gesetzliche Anerkennung. Der EAA rückt Barrierefreiheit ins Zentrum der Webseitengestaltung und macht klar: Das Thema betrifft längst nicht mehr nur öffentliche Institutionen. Jeder Website-Betreiber sollte Barrierefreiheit jetzt in seine Entscheidungsprozesse integrieren – ganz im Sinne guter, inklusiver Praxis.

Die digitale Welt ist voller Hürden – die meisten davon sind für Menschen, die nicht auf assistive Technologien angewiesen sind, unsichtbar. Kann Deine Website ohne Maus bedient werden? Versteckt sie lesbare Inhalte vor Screenreadern? Nutzt sie Farbe als einziges Signal für Fehler? Damit schließt Du potenziell mehr als ein Viertel aller Nutzer:innen1 in der EU aus. Barrierefreiheit ist kein bloßes Kontrollkästchen oder eine lästige Pflicht aus dem European Accessibility Act – sie ist essenzieller Bestandteil guten Designs. Organisationen müssen ihre Nutzer:innen verstehen und sich in ihre Lage versetzen. Nutze Deine Website so, wie es Deine Nutzer:innen tun – gestalte nicht einfach nur für sie. Wie das gelingt? Indem Du die zentralen WCAG-2.2-Prinzipien berücksichtigst: Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit.

Zugängliche Online Shops: 10 Grundprinzipien für den European Accessibility Act

Im Folgenden stellen wir zehn Prinzipien für barrierefreies Webdesign vor – für alle Entwickler:innen, egal ob beim Aufbau eines neuen Shops oder bei der Optimierung bestehender Seiten. Diese praxisnahen Techniken und Tools helfen Dir, Deinen Onlineshop zugänglich und inklusiv zu gestalten – und die Anforderungen des European Accessibility Act zu erfüllen.

1. Semantisches HTML ist grundlegend

Viele Website-Betreiber:innen glauben, es sei schwierig, Entwickler:innen mit Barrierefreiheits-Know-how zu finden. Doch wusstest Du, dass ein Großteil der Arbeit einfaches Befolgen der Grundregeln des semantischen HTML ist? So geht’s:

Nutze passende Tags: <button>, <a>, <label>,<fieldset> usw.

Diese Tags bieten eingebaute Barrierefreiheitsfunktionen wie Tastaturinteraktion und Rollen. Die Wahl des passenden semantischen Tags ist oft der einfachste und robusteste Weg, Webinhalte zugänglich zu machen. Damit nutzt Du die Fähigkeiten des Browsers – und sparst Dir komplexe, fehleranfällige ARIA-Workarounds. Gleichzeitig schaffst Du ein vorhersehbares Nutzererlebnis.

Vermeide generische Container wie <div> und <span> für interaktive Elemente

Solche Container besitzen keine semantische Bedeutung oder Barrierefreiheitsfunktionen und benötigen ARIA, um korrektes Verhalten nachzuahmen. Zum Beispiel:

<div onclick="doSomething()">Hier klicken</div>
<span onclick="submitForm()">Absenden</span>

Mit diesem Ansatz erkennen assistive Technologien wie Screenreader diese Elemente nicht als interaktive Steuerelemente (z. B. Button oder Link). Nutzer:innen, die darauf angewiesen sind, können die Funktion des Elements nicht erfassen. Die bessere Alternative: Verwende semantische HTML-Elemente wie <button> und <a>. Diese sind von Haus aus tastaturbedienbar, fokussierbar und mit Enter/Leertaste aktivierbar – und kommunizieren ihre Rolle automatisch an assistive Technologien.

Verwende Überschriften- und Listenelemente korrekt für eine logische Dokumentstruktur

Stell Dir vor, Du suchst Informationen in einem langen Dokument ohne Kapitelüberschriften oder Zwischenüberschriften – genau dieses Problem entsteht für Screenreader-Nutzer:innen bei falschen oder fehlenden Überschriften. Ebenso sollten Listenelemente wie <ul>, <ol> und <li> korrekt eingesetzt werden, um Listen zu strukturieren. Mit sauberer Überschriftenstruktur und Listenelementen können Screenreader und andere Hilfsmittel die Hierarchie klar vermitteln.

2. Tastaturbedienbarkeit

Warum ist Tastaturbedienbarkeit so wichtig? Sie gehört zum WCAG-Prinzip „Bedienbar“ und bedeutet, dass alle Funktionen einer Website per Tastatur erreichbar sein müssen. Das ist essenziell für Menschen mit motorischen Einschränkungen, die keine Maus nutzen können, aber auch für Screenreader-Nutzer:innen. Und: Auch fortgeschrittene Nutzer:innen bevorzugen oft Tastaturkürzel für mehr Effizienz. Fehlende Tastaturbedienbarkeit schließt Nutzer:innen aus – ein grundlegender Verstoß gegen die Anforderungen an Bedienbarkeit und damit auch gegen den European Accessibility Act.

Alle Funktionen müssen per Tastatur (z. B. Tab, Enter, Leertaste) bedienbar sein

Laut WebAIMs 10. Screenreader-Umfrage navigieren 71,6 % der Screenreader-Nutzer:innen hauptsächlich über Überschriften. Auch wenn es keine exakten Zahlen zur Tastaturnavigation gibt, ist klar: Wer per Überschriften navigiert, nutzt fast immer die Tastatur.

Teste die Fokusreihenfolge

Automatisierte Tools helfen, aber prüfe die Fokusreihenfolge auch manuell. Achte darauf, in welcher Reihenfolge interaktive Elemente (Buttons, Links, Formularfelder) beim Navigieren mit der Tastatur – meist per Tab – angesprungen werden. Die Fokusreihenfolge sollte logisch und intuitiv dem visuellen Lesefluss (oben–unten, links–rechts) folgen, sodass Nutzer:innen sich einfach zurechtfinden.

Sichtbare Fokusindikatoren bereitstellen

Für Tastaturnutzer:innen ist es entscheidend, jederzeit zu wissen, „wo“ sie sich auf der Seite befinden. Genau das fordert das WCAG-Kriterium „Fokus sichtbar“ (Level AA): Jede tastaturbedienbare Komponente braucht eine klare, sichtbare Markierung. Da WCAG 2.1.1 (Keyboard) verlangt, dass sämtliche Funktionen per Tastatur erreichbar sind, ist ein sichtbarer Fokus überall Pflicht.

Diese visuellen Hinweise – Fokusindikatoren – sind unverzichtbar, denn sie ergänzen die Fokusreihenfolge. Ist die Navigation korrekt, aber der aktuelle Fokus nicht sichtbar, verlieren Nutzer:innen schnell die Orientierung und Tastaturnavigation wird unmöglich.

Deshalb: Fokusindikatoren müssen auffällig und gut erkennbar sein. Jedes interaktive Element sollte klar anzeigen, wenn es Tastaturfokus hat. Wichtig: Nie die Standard-Fokusumrandung des Browsers (z. B. mit outline: none) entfernen, es sei denn, es gibt einen gleichwertigen, ebenso klaren Ersatz.

3. Farbe & Kontrast

Textkontrast muss den WCAG-2.2-Richtlinien entsprechen

Stelle sicher, dass Texte auch für Menschen mit Sehbehinderungen oder Farbenblindheit gut lesbar sind. Jeder Text auf einer Website oder digitalen Oberfläche muss Mindest-Kontrastwerte einhalten – das gilt für Buttons, Links und Labels, ausgenommen dekorativer Text.

• Normaler Text (kleiner als 18pt regulär oder 14pt fett) benötigt einen Kontrastwert von mindestens 4,5:1 zum Hintergrund.

• Großer Text (mindestens 18pt regulär oder 14pt fett) darf einen etwas niedrigeren Mindestkontrast von 3:1 haben.

Oft übersehen Entwickler:innen, Grafiker:innen, UX-Designer:innen und Produktverantwortliche die Kontrastwerte in verschiedenen Zuständen wie on-hover oder on-click. Ein typisches Beispiel: Der „In den Warenkorb“-Button verliert beim Überfahren mit der Maus oder im Fokus den nötigen Kontrast. Achte darauf, dass der Kontrast über die gesamte Nutzerreise hinweg erhalten bleibt. Die gleichen Anforderungen gelten für nicht-textliche Elemente, die Bedeutung transportieren – z. B. Fokusindikatoren oder Icons. Prüfe daher auch den Kontrast von Warenkorb-, Zahlungs- oder Wunschlisten-Icons.

Farbige Informationsvermittlung – und was ist mit Sehbehinderungen?

Farbe kann ein wirkungsvolles Mittel zur Informationsvermittlung sein, ist für viele Nutzer:innen jedoch schwer verständlich. Wenn Du z. B. Farbfelder zur Auswahl verschiedener Produktvarianten nutzt, sollten diese zusätzlich (sichtbare oder per aria-label hinterlegte) Textbeschriftungen haben. Farbenblinde Nutzer:innen können Rot und Grün nicht unterscheiden, Menschen mit Sehschwäche übersehen Farbsignale, und Screenreader nehmen visuelle Gestaltung gar nicht wahr. Bedenke:

• Farbenblinde Nutzer:innen machen rund 4,42 % Deiner Gesamtuser2 aus (etwa 1 von 12 Männern, 1 von 200 Frauen).

• Screenreader-Nutzer:innen nehmen visuelles Styling überhaupt nicht wahr.

• Nutzer:innen mit eingeschränktem Sehvermögen oder solche, die Monochrom-Displays verwenden, können Farbsignale ebenfalls übersehen. Selbst Menschen mit perfektem Sehvermögen haben in bestimmten Situationen Schwierigkeiten beim Lesen – etwa beim Einsatz eines Geräts in hellem Sonnenlicht. Ohne ausreichenden Kontrast sind Farben oft kaum erkennbar.

Das Thema Kontrast spielt auch bei der Verwendung von Farben für Fehlermeldungen eine Rolle. Farben als einziges visuelles Mittel zur Informationsvermittlung, zur Anzeige von Aktionen oder zur Unterscheidung von Elementen zu nutzen, entspricht nicht den Anforderungen an Barrierefreiheit. Eine einfache und effektive Verbesserung ist der Einsatz eines Icons, das den Fehler verdeutlicht – zum Beispiel ein Kreuzsymbol. Durch die Kombination aus Icon und Farbe können Nutzer:innen Fehler schneller erfassen.

Wenn Du diese Kontrast-Richtlinien beachtest, unterstützt Du nicht nur die Einhaltung von Barrierefreiheitsstandards – Du verbesserst auch die gesamte Nutzererfahrung. Das gilt besonders für Menschen mit Sehbeeinträchtigungen oder Farbsensitivität.

4. Alle Formulare und Eingabefelder korrekt beschriften

Aufbauend auf semantischem HTML sind eine sinnvolle Struktur und klare Kommunikation bei Formularen unerlässlich – besonders bei Formularen im Checkout-Prozess. Stelle sicher, dass Deine Formulare barrierefrei und konform mit dem European Accessibility Act sind, und achte dabei auf Folgendes:

• Beschrifte Formularfelder korrekt mit <label>, zum Beispiel in Adress- und Zahlungsformularen.

• Stelle klare, barrierefreie Fehlermeldungen bereit, die mit den jeweiligen Eingabefeldern verknüpft sind. Zeige zum Beispiel an, wenn eine Kartennummer ungültig ist oder ein Feld wie die Postleitzahl fehlt. Die Fehlermeldung sollte eindeutig zugeordnet und mit dem jeweiligen Eingabefeld verknüpft sein. Verwende dazu das Attribut aria-describedby.

• Nutze nach Möglichkeit native Formularelemente für eine bessere Unterstützung.

5. ARIA (Accessible Rich Internet Applications) mit Bedacht einsetzen

Semantisches HTML bildet das Fundament des Webs. Moderne Webanwendungen enthalten jedoch komplexe UI-Komponenten wie Dropdowns, Slider oder dynamische Inhaltsaktualisierungen, die mit Standard-HTML allein nicht ausreichend beschrieben werden können. Um diese Lücke zu schließen, können HTML-Elemente mit ARIA-Attributen ergänzt werden. Diese Attribute liefern wichtige zusätzliche semantische Informationen: Sie definieren die Rolle eines Elements (z. B. was es ist) und dessen aktuellen Zustand (z. B. erweitert, aktiviert). Außerdem legen sie Eigenschaften wie Name oder Pflichtstatus fest. So können Hilfstechnologien diese Komponenten korrekt erkennen und bedienen.

Bevor Du jedoch zu ARIA greifst, frage Dich: Lässt sich das auch mit Standard-HTML umsetzen? Elemente wie <button> oder <label> verfügen bereits über semantische Informationen, die von Hilfstechnologien verstanden werden. Damit minimierst Du das Risiko, dass ARIA-Rollen mit HTML-Semantik kollidieren oder mit Standardverhalten des Browsers in Konflikt geraten. Die beste Praxis: Setze ARIA nur dann ein, wenn native HTML-Mittel nicht ausreichen.

Häufig genutzte ARIA-Attribute (Rollen, Zustände & Eigenschaften):

Entwickler:innen sollten mit gängigen Attributen vertraut sein, die Bedeutung transportieren. Dazu gehören Rollen wie role="dialog" oder role="alert" sowie HTML-Attribute, die den Zustand oder die Eigenschaften beschreiben, beispielsweise: aria-expanded="true/false", aria-checked="true/false", aria-label="Beschreibung".

Seiteninhalte können sich ändern, ohne dass die Seite neu geladen wird – etwa bei Statusmeldungen, Formularfehlern oder Chat-Updates. Screenreader erkennen oder melden solche Änderungen nicht automatisch. Um Nutzer:innen darauf hinzuweisen, können Entwickler:innen aria-live-Regionen einsetzen. In einem Onlineshop ist das unerlässlich, um etwa das Hinzufügen von Artikeln zum Warenkorb, Aktualisierungen des Gesamtbetrags oder dynamische Änderungen der Verfügbarkeit zu kommunizieren. aria-live bietet zudem verschiedene Konfigurationsmöglichkeiten:

aria-live="polite": Meldet Änderungen auf der Seite, sobald Nutzer:innen gerade nichts anderes tun.

aria-live="assertive": Unterbricht Nutzer:innen sofort, um die Änderung anzukündigen.

Überlege Dir bei Benachrichtigungen immer, welche Funktion sie erfüllen: Müssen Nutzer:innen sofort reagieren, oder kann die Information warten, bis der Screenreader wieder frei ist?

Wie ARIA das Screenreader-Erlebnis beeinflusst, zeigt zum Beispiel ein Button mit einem X-Icon. Mit ARIA kann er so beschrieben werden: <button aria-label="Schließen"> X</button>. Der Screenreader liest dann „Schließen, Button“ statt „X, Button“ vor. Eine weiterführende Anwendung ermöglicht es, mit aria-describedby zusätzliche Kontextinformationen bereitzustellen, indem man auf die ID eines anderen Elements mit Beschreibung verweist.

6. Responsive & Mobile Accessibility

Sorge dafür, dass Deine Website responsiv und mobilfreundlich ist. Das ist nicht nur gute Praxis, sondern auch ein zentraler Bestandteil der umfassenden Barrierefreiheitsziele des European Accessibility Act.

Oberflächen müssen auf allen Geräten und Bildschirmgrößen funktionieren.

Nutze Tools wie die DevTools von Google Chrome, um schnell zu überprüfen, wie ein Design auf verschiedenen Geräten und Bildschirmgrößen wirkt.

Erlaube das Zoomen und respektiere die Texteinstellungen der Nutzer:innen.

Ein schwerwiegender Fehler im Webdesign ist es, Nutzer:innen auf eine bestimmte Zoomstufe oder Textgröße zu beschränken.

Vermeide reine Hover-Interaktionen oder biete Alternativen an.

Viele Websites nutzen Hover-Effekte wie :hover in CSS oder mouseenter/mouseleave-Events in JavaScript, um Informationen einzublenden, Aktionen auszulösen oder versteckte Schaltflächen wie „Zur Wunschliste hinzufügen“ anzuzeigen. Solche Effekte sind für Mausnutzer:innen ansprechend, können aber erhebliche Barrieren schaffen. Tastaturnutzer:innen sind von diesen Effekten ausgeschlossen, und auch für Nutzer:innen von Hilfstechnologien sind Hover-Zustände oft nicht oder nur schwer auslösbar.

Schriftgrößen sollten in relativen Einheiten angegeben werden, damit der Text mitskaliert.

Vermeide feste Pixelgrößen (px) bei Schriftarten. Sie lassen sich nicht gut skalieren, wenn Nutzer:innen die Standardgröße ihres Browsers für bessere Lesbarkeit anpassen. Jeder Browser verhält sich beim Zoomen von festen Pixelgrößen unterschiedlich, was für manche Nutzer:innen erhebliche Probleme verursachen kann.

Relative Einheiten wie rem oder em basieren auf anderen Werten und erlauben so ein proportionales Vergrößern oder Verkleinern.

Viele Entwickler:innen testen Websites, indem sie die Schriftgröße erhöhen. Es ist aber auch wichtig, zu prüfen, wie die Seite aussieht, wenn die Schriftgröße verringert wird – für Nutzer:innen, die kleinere Schrift bevorzugen als vom Designer vorgesehen.

7. Barrierefreie Multimedia-Inhalte

Videos mit Untertiteln und Audios mit Transkripten versehen

Multimedia-Inhalte bieten einen großen Mehrwert für die Nutzererfahrung, bergen aber auch erhebliche Barrieren, wenn sie nicht sorgfältig umgesetzt werden. Diese Barrieren zu adressieren ist nicht nur gute Praxis – konkrete Anforderungen an Untertitel, Audiodeskriptionen und barrierefreie Steuerelemente sind in Standards wie EN 301 549 festgelegt, die zur Erfüllung der Vorgaben des European Accessibility Act herangezogen werden können.

Untertitel werden oft nur für Menschen ohne Hörvermögen als hilfreich angesehen. Tatsächlich nutzen aber viele andere Nutzer:innen Untertitel – etwa in lauten Umgebungen oder wenn sie Inhalte lieber lesen als hören. Barrierefreiheit berücksichtigt all diese Nutzergruppen. Untertitel sollten daher so detailliert sein, dass Sprecher:innen und andere Geräusche eindeutig erkennbar sind.

Das reicht jedoch nicht: Für vollständige Barrierefreiheit sind neben Untertiteln auch Transkripte erforderlich. Transkripte geben den gesamten Inhalt wieder und ermöglichen einen nicht-linearen Zugang. Sie sind durchsuchbar und können von Braille-Geräten genutzt werden – ein großer Vorteil für Braille-Nutzer:innen. Für Videoinhalte gilt: Detaillierte Untertitel und Transkripte sind ein Muss.

Ein oft übersehener Bereich betrifft Audiodeskriptionen (AD). AD ist eine zusätzliche Tonspur, die wichtige Informationen für Menschen mit eingeschränktem oder fehlendem Sehvermögen liefert – etwa Szenenbeschreibungen oder visuelle Hinweise. Gerade für Produktvideos ist das unverzichtbar. Audiodeskriptionen sind ein zentrales Element barrierefreier Multimedia-Inhalte.

*Barrierefreie Mediensteuerung

Automatisch startende Inhalte wirken zwar ansprechend, sind aber für viele Nutzer:innen schwer verarbeitbar. Gib ihnen die Möglichkeit, Inhalte manuell zu starten – oder, falls Autoplay unverzichtbar ist, stelle sicher, dass sich die Inhalte schnell und einfach stoppen oder pausieren lassen.

Bedenke außerdem, dass Autoplay Nutzer:innen ablenken kann. Automatisch startende Medien stören häufig die Sprachausgabe von Screenreadern und erschweren blinden oder sehbehinderten Personen die Navigation. Unerwartete Geräusche oder Bewegungen können zudem sehr störend sein – besonders für Menschen mit kognitiven Einschränkungen oder Aufmerksamkeitsdefiziten, da sie die Konzentration auf die eigentliche Aufgabe erschweren.

Die Steuerelemente müssen umfassende Anforderungen erfüllen: Medienplayer-Bedienelemente (Untertitelumschaltung, Vollbild, Play/Pause, Fortschrittsbalken, Lautstärke) müssen per Tastatur bedienbar, klar beschriftet und mit sichtbaren Fokuszuständen versehen sein.

8. Immer beschreibende Alt-Texte für Produkte verwenden, leere Alt-Texte für Dekoration.

Für einen Online-Shop sind die meisten Produktbilder essenziell und müssen mit aussagekräftigen Alt-Texten versehen werden. Das Alt-Attribut sollte den Zweck und die Bedeutung des Bildes prägnant beschreiben. Eine gute Checkliste umfasst:

• Beschreibe, was zu sehen ist: Dazu gehören wichtige visuelle Details wie

• Farbe, Stil, Material oder besondere Merkmale.

• Sei knapp, aber informativ: Vermeide Keyword-Stuffing, denn Alt-Texte

• sind für die Nutzer:innen gedacht. Konzentriere dich darauf, das Bild visuell zu beschreiben.

• Verzichte auf Formulierungen wie Bild von ... oder Foto von ..., da Screenreader

• den Nutzer:innen bereits mitteilen, dass es sich um ein Bild handelt.

Gute Praxis: alt="Herrenpullover aus blauer Merinowolle mit Rundhalsausschnitt"

Schlechte Praxis: alt="Produktbild" oder alt="blauer Wollpullover Foto SKU12345"

Gute Alt-Texte helfen Nutzer:innen, Produkte zu verstehen. Das ermöglicht fundierte Kaufentscheidungen und reduziert Retouren. Es entspricht den inklusiven Grundsätzen des European Accessibility Act. Fehlende oder unbrauchbare Alt-Texte bei Produktbildern stellen dagegen ein großes und unnötiges Hindernis dar. Reduziere die kognitive Belastung, indem du dekorative Bilder korrekt kennzeichnest. Liefere außerdem alle wichtigen Informationen für inhaltliche Bilder – das ist ein zentraler Bestandteil von Barrierefreiheit.

Nicht alle Bilder sind für Screenreader bestimmt, insbesondere solche, die nur dekorativen Charakter haben. Vermeide unnötige Ablenkung für Nutzer:innen von unterstützenden Technologien. Überlege genau, welche Bilder wirklich eine Beschreibung benötigen. Hintergrund- und dekorative Bilder brauchen in der Regel keine Beschreibung. Die Reduzierung der kognitiven Belastung ist entscheidend für mehr Barrierefreiheit.

Das Markieren eines dekorativen Bildes ist einfach: Verwende ein leeres alt-Attribut: alt="", damit der Screenreader das Bild ignoriert.

9. Zeitlimits

Nutzerinnen sollten nicht durch künstliche Zeitbeschränkungen eingeschränkt werden – etwa durch ein Zeitlimit beim Eingeben eines Codes. In bestimmten Situationen lässt sich das nicht vermeiden, zum Beispiel bei Online-Banking-Timeouts oder Echtzeit-Events wie Auktionen. Ansonsten sollten Zeitlimits vermieden werden. Sie verursachen Stress bei allen Nutzerinnen und stellen für einige sogar erhebliche Barrieren dar.

Die WCAG geht darauf direkt in Richtlinie 2.2.1 ein: Wenn ein Zeitlimit durch den Inhalt gesetzt wird, müssen Nutzer:innen die Möglichkeit haben, dieses abzuschalten, anzupassen oder einfach zu verlängern – es sei denn, das Zeitlimit ist essenziell oder beträgt mehr als 20 Stunden. Wichtig: Es muss auch eine Warnung geben. Diese Warnung muss mindestens 20 Sekunden vor Ablauf erscheinen, sofern eine Verlängerung möglich ist.

10. Testen mit unterstützenden Technologien – Open Source Accessibility Toolkit

Der letzte Schritt ist das Testen mit verschiedenen unterstützenden Technologien. Das ist entscheidend für eine positive Nutzererfahrung und hilft dabei, die Einhaltung der technischen Standards des European Accessibility Act zu überprüfen und nachzuweisen.

Tools wie Axe und Lighthouse bieten automatisierte Prüfungen. Dennoch ist es am besten, Websites so zu testen, wie Nutzer:innen sie tatsächlich verwenden würden. Alle oben genannten Prinzipien lassen sich mit einem soliden Entwickler-Toolkit rund um Barrierefreiheit untermauern. Bei Kiwee nutzen wir regelmäßig diese Open-Source-Tools:

• Screenreader:

  • NVDA

  • JAWS

• Tools zur Barrierefreiheitsprüfung:

  • Axe DevTools

  • Lighthouse

  • pa11y

Wir setzen pa11y auch in unserer Pipeline ein, da es eine CLI bietet – bei jedem Update erhalten wir Hinweise, falls in puncto Barrierefreiheit etwas behoben werden muss.

• Farbkontrast-Checker:

  • Color Contrast Analyzer (CCA)

  • WhoCanUse

• Linting/CI-Tools:

  • ESLint-Plugins für a11y

  • jest-axe

Doch Softwaretools bringen dich nur ein Stück weiter. Ein wichtiger Teil der Barrierefreiheitsprüfung ist das manuelle Überprüfen des Quellcodes – verlasse dich nicht nur auf automatisierte Linting- oder CI-Tools. Auch die Navigation mit der Tastatur sollte gründlich getestet werden: Können Nutzer:innen alle Formulare ausfüllen, alle Elemente der Seite erreichen? Funktioniert die Bedienung sämtlicher Pop-ups?

Teste im Online-Shop die gesamte User Journey: Können Nutzer:innen Produkte finden und Details einsehen? Lassen sich Optionen auswählen, Produkte in den Warenkorb legen und der Checkout erfolgreich abschließen? Vergiss vor allem nicht die unsichtbaren Behinderungen. Eine Website, die mit unterstützenden Technologien voll zugänglich ist, kann dennoch erhebliche Barrieren für neurodivergente Personen aufweisen, etwa durch zu hohe kognitive Belastung, Informationsüberflutung, schlechte Schriftwahl oder übermäßigen Jargon. All das sind Aspekte, die der European Accessibility Act mit abdeckt.

Web-Accessibility ist unverzichtbar: Fazit für Entwickler innen und Shop-Betreiber innen

Eine Website barrierefrei zu gestalten, ist keine reine Pflichtübung – es erfordert sorgfältige Planung und konsequente Umsetzung. Für echte Wirkung muss Barrierefreiheit als zentraler Wert im Unternehmen verankert sein. Einzelne Maßnahmen reichen nicht aus, wenn nicht systematisch und von Grund auf daran gearbeitet wird, diese wichtigen Aktivitäten dauerhaft zu etablieren.

Denk daran: Barrierefreiheit betrifft nicht nur sichtbare Behinderungen. Es gibt viele einfache Verbesserungen, und wer von Anfang an nach WCAG-Standards gestaltet, erfüllt nicht nur Nutzerbedürfnisse, sondern auch gesetzliche Anforderungen wie die des European Accessibility Act. Außerdem gilt: Eine barrierefreie Website erleichtert allen Nutzer:innen den Zugang zu den gewünschten Informationen.

Quellen

1. Eurostat - Population with disability
2. Deane B. Judd, "Facts of Color-Blindness*," J. Opt. Soc. Am. 33, 294-307 (1943)