Wir entwickeln für Unternehmen barrierefreie Websites, die sich auch mit Tastatur, Screenreader oder starker Vergrößerung vollständig bedienen lassen. Kontraste, Struktur, Formulare und Fokus planen wir vom ersten Entwurf an mit und prüfen sie vor dem Livegang nach WCAG 2.2 AA.
Anforderungen aus WCAG 2.2 AA · Auswahl
Kurz erklärt
Eine barrierefreie Website lässt sich auch mit Tastatur, Screenreader oder starker Vergrößerung vollständig bedienen, weil Struktur, Kontraste und Formulare dafür angelegt sind. Beim Erstellen gilt WCAG 2.2 Stufe AA als Maßstab, von der Gestaltung über die Entwicklung bis zur Prüfung vor dem Livegang. Ein nachträglich eingebundenes Overlay mit Bedienleiste für Schriftgröße oder Kontrast ersetzt diese Arbeit im Code nicht.
Von Anfang an mitentwickelt
Eine barrierefreie Website lässt sich nicht als Schicht am Ende auflegen, weil sie in denselben Arbeitsschritten entsteht wie Gestaltung und Code. Struktur, Kontraste, Tastaturbedienung, Screenreader-Ausgabe und Formulare planen wir vom ersten Entwurf an mit und prüfen sie nach WCAG 2.2 AA.
Echte Überschriften, Listen und Tabellen mit Kopfzellen geben jeder Seite eine Gliederung, die Screenreader vorlesen und in der Nutzer gezielt springen können. Die Seitensprache steht im Code, und fremdsprachige Passagen sind eigens ausgezeichnet, damit sie richtig ausgesprochen werden.
Text erreicht mindestens 4,5 : 1 gegenüber seinem Hintergrund, Bedienelemente und Grafiken erreichen mindestens 3 : 1. Zu geringer Kontrast ist laut WebAIM Million 2026 der häufigste Fehler und findet sich auf 83,9 % der geprüften Startseiten.
Menüs, Akkordeons, Formulare und Dialoge lassen sich vollständig mit Tab, Enter, Leertaste und Pfeiltasten bedienen, ganz ohne Maus. Der Fokus bleibt dabei jederzeit sichtbar und wird weder von der Kopfzeile noch vom Cookie-Banner verdeckt.
Bilder erhalten passende Alternativtexte, Bedienelemente einen eindeutigen Namen und eine Rolle, und Bestätigungen werden als Statusmeldung angesagt. Dekorative Grafiken bleiben für Screenreader ausgeblendet, damit die Ausgabe kurz, eindeutig und gut verständlich bleibt.
Jedes Feld hat eine sichtbare Beschriftung, und Fehlermeldungen stehen als Text direkt am betroffenen Feld. Mehrstufige Formulare fragen Angaben, die bereits in einem früheren Schritt eingegeben wurden, nicht ein zweites Mal ab.
WCAG 2.2 ist seit dem 5. Oktober 2023 eine Empfehlung des W3C und ergänzt neun Erfolgskriterien, sechs davon auf den Stufen A und AA. Die neuen Kriterien verlangen einen nicht verdeckten Fokus, eine Alternative zu Ziehbewegungen und Klickziele ab 24 × 24 Pixel oder mit ausreichendem Abstand. Dazu kommen Hilfe an gleicher Stelle auf allen Seiten, Formulare ohne doppelte Eingabe und eine Anmeldung, die keinen Gedächtnis- oder Rätseltest ohne Alternative verlangt. Da Inhalte nach WCAG 2.2 laut W3C zugleich WCAG 2.1 und 2.0 erfüllen, arbeiten wir direkt nach der neuen Fassung.
ARIA-Attribute ergänzen HTML um Angaben für Hilfsmittel, wenn ein Element diese Angaben nicht von selbst mitbringt. In der WebAIM Million 2026 hatten Startseiten mit ARIA im Schnitt 59,1 erkannte Fehler und Seiten ohne ARIA 42, wobei WebAIM darin keinen Ursachennachweis sieht. Für uns ist das ein Grund, zuerst native Elemente wie Button, Beschriftung und Tabelle einzusetzen und ARIA nur dort, wo HTML allein nicht ausreicht.
Leistungsumfang
Eine barrierefreie Website entsteht aus vielen Entscheidungen in Gestaltung, Code und Redaktion, die zusammenpassen müssen. Wir fassen sie in acht Bausteinen zusammen und planen alle von Beginn an gemeinsam.
Zu Beginn erfassen wir alle Funktionen der Website, von Anfrage und Bewerbung bis zu Login, Bestellung oder Terminbuchung, dazu eingebundene Drittanbieter und PDFs. So ist von Beginn an klar, welche Teile der Website in Gestaltung, Entwicklung und Prüfung einbezogen werden.
Farben, Schriftgrößen, Fokus-Stil und Klickziele legen wir schon im Entwurf nach WCAG 2.2 AA fest. Ob jede Textfarbe den nötigen Kontrast erreicht, prüft vor dem Livegang zusätzlich axe auf jeder einzelnen Seite.
Wir entwickeln mit Astro schlankes HTML mit echten Überschriften, benannten Seitenbereichen, Tabellenköpfen und ausgezeichneter Sprache. Zusätzliche ARIA-Attribute setzen wir nur dort ein, wo natives HTML allein für Hilfsmittel wie Screenreader nicht ausreicht.
Menüs, Akkordeons, Slider, Dialoge und Cookie-Banner lassen sich vollständig per Tastatur bedienen, ohne dass der Fokus irgendwo festhängt. Der Fokus ist jederzeit sichtbar und wird von fixierten Elementen wie der Kopfzeile nicht verdeckt.
Jedes Feld hat eine sichtbare Beschriftung, Fehlermeldungen stehen als Text am Feld, und mehrstufige Formulare fragen nichts doppelt ab. Das gilt für Anfrage- und Bewerbungsformulare ebenso wie für Bestellung und Login, also für alle Wege, über die Kunden und Bewerber Kontakt aufnehmen.
Bilder erhalten passende Alternativtexte und Bedienelemente einen eindeutigen Namen, während dekorative Grafiken für Screenreader ausgeblendet bleiben. Bestätigungen und Fehlermeldungen werden als Statusmeldung angesagt, ohne dass der Fokus dafür an eine andere Stelle springen muss.
Im Redaktionssystem ist der Alternativtext ein Pflichtfeld, sodass kein Bild ohne Beschreibung für Screenreader erscheint. So bleibt die barrierefreie Struktur erhalten, auch wenn das Team später selbst Texte, Bilder und Tabellen einpflegt.
Jede Seite prüfen wir automatisch mit axe nach WCAG 2.2 AA und mit Lighthouse auf Desktop und Smartphone. Danach folgt die Prüfung von Hand, vor allem die Bedienung per Tastatur und die Darstellung auf schmalen Bildschirmen.
Auswählen, um den Baustein zu öffnen
Barrierefreiheit in NRW und im Netz
In Nordrhein-Westfalen hatten Ende 2025 knapp zwei Millionen Menschen einen Schwerbehindertenausweis, und 80 Prozent von ihnen waren älter als 54 Jahre. Dazu kommen alle, deren Sehen oder Hören ohne amtliche Anerkennung nachlässt, und alle, die ihr Smartphone unterwegs bei hellem Sonnenlicht bedienen. Gleichzeitig fand die WebAIM Million 2026 auf fast allen geprüften Startseiten erkennbare Fehler, auf Astro-Seiten im Schnitt deutlich weniger.
knapp 2 Mio.
Menschen mit Schwerbehindertenausweis in Nordrhein-Westfalen
IT.NRW, Stand 31.12.2025
95,9 %
der Startseiten mit erkannten WCAG-Fehlern, bei einer Million geprüfter Websites
WebAIM Million 2026, Daten Februar 2026
9,0
erkannte Fehler im Schnitt auf Astro-Startseiten, gegenüber 56,1 über alle Seiten
WebAIM Million 2026 · Korrelation, keine Ursache
Ablauf
Eine barrierefreie Website dauert je nach Umfang vier bis zehn Wochen und wird zum Festpreis angeboten. Barrierefreiheit läuft dabei in jedem Schritt mit, statt am Ende als eigener Prüfabschnitt angehängt zu werden.
15 Minuten zu Zielen, Funktionen und Nutzern
Farben, Schrift, Fokus und Klickziele im Entwurf
Astro, Tastaturbedienung und Screenreader-Struktur
axe, Lighthouse und Prüfung von Hand
Pflichtfelder im Redaktionssystem
Automatische Werkzeuge wie axe und Lighthouse finden vor allem, was fehlt, etwa einen Alternativtext oder eine Feldbeschriftung. Ob ein Alternativtext das Bild sinnvoll beschreibt, ob die Tab-Reihenfolge logisch ist oder ob ein Kalender vollständig per Tastatur funktioniert, zeigen sie nicht. Das W3C hält dazu fest, dass Werkzeuge nicht alle Aspekte automatisch prüfen können und menschliches Urteil nötig bleibt. Auf hhcreative.de fand ein Technik-Check am 29.09.2026 trotz fester Prüfroutine fünf Befunde, darunter zu helle Grautöne wie #8c8c8c mit 3,36 : 1. Alle Befunde sind behoben, und die Grautöne ersetzt seitdem ein einheitliches #5a5a5a mit 6,9 : 1 auf Weiß. Heute meldet axe nach WCAG 2.2 AA null Befunde (Stand 05.10.2026), und Lighthouse bewertet die Barrierefreiheit mit 100 Punkten. Beides ist für uns die Voraussetzung für die Prüfung von Hand und kein Ersatz für sie.
Je nach Umfang dauert ein Projekt vier bis zehn Wochen. Den Terminplan mit allen Freigaben legen wir in der ersten Projektwoche fest, und die Prüfung vor dem Livegang ist darin von Anfang an eingeplant.
Kosten
Jedes Projekt hat einen Festpreis, den wir nach dem Erstgespräch für den konkreten Umfang schriftlich nennen. Die Unternehmenswebsite mit Startseite, sechs Unterseiten, Impressum und Datenschutz beginnt bei 2.229 €.
Festpreis-Paket · Unternehmenswebsite
Enthaltene Seiten
2.229 €
Einmaliger Festpreis
+ ab 29 € / Monat
Hosting, Wartung und Datensicherung
Live in 4–10 Wochen
Von der Beauftragung bis zur Veröffentlichung
Den Festpreis für das konkrete Projekt nennen wir schriftlich nach dem Erstgespräch.
Overlays
Overlays sind Zusatzskripte mit einer Bedienleiste für Schriftgröße, Kontrast oder Vorlesen, die nachträglich auf eine fertige Website gesetzt werden. Sie setzen erst auf der fertigen Seite an und ersetzen nicht die Arbeit an Struktur, Kontrasten und Bedienung im Code. Wir bauen Barrierefreiheit deshalb direkt in Inhalte, Gestaltung und Code ein, sodass sie auch ohne zusätzliches Skript besteht.
Schema · Wo Barrierefreiheit entsteht
Hier bauen wir Barrierefreiheit ein
Wie die Website barrierefrei wird, klären wir im Erstgespräch.
Im 15-minütigen Erstgespräch per Videocall besprechen wir Funktionen, Nutzergruppen und Umfang der Website, und danach erhält das Unternehmen ein Angebot zum Festpreis.
Häufige Fragen
Nach Themen sortiert.
Jedes Projekt hat einen Festpreis, den wir nach dem Erstgespräch für den konkreten Umfang schriftlich nennen. Die Unternehmenswebsite mit Startseite, sechs Unterseiten, Impressum und Datenschutz beginnt bei 2.229 €.
Der Aufwand einer Nachrüstung hängt vor allem vom bestehenden Code ab, von der Zahl der Seiten und interaktiven Elemente und vom eingesetzten Page Builder. Aktion Mensch schreibt, dass es sich bei sehr alten Seiten in der Regel lohnt, die Website barrierefrei komplett neu zu erstellen.
Wir entwickeln und prüfen nach WCAG 2.2 auf Stufe AA, der aktuellen Fassung der W3C-Richtlinien von Oktober 2023, aktualisiert im Dezember 2024. Inhalte, die WCAG 2.2 erfüllen, erfüllen laut W3C zugleich die älteren Fassungen WCAG 2.1 und WCAG 2.0.
Vor dem Livegang prüfen wir jede Seite automatisch mit axe nach WCAG 2.2 AA, auch bei geöffneten Menüs, und mit Lighthouse auf Desktop und Smartphone. Von Hand folgen vor allem die Bedienung per Tastatur und die Darstellung auf schmalen Bildschirmen.
Nein, denn Lighthouse bewertet nur automatisch prüfbare Regeln, und manuelle Prüfungen fließen laut Dokumentation nicht in den Wert ein. Ob die Tab-Reihenfolge logisch ist oder ein Alternativtext das Bild sinnvoll beschreibt, zeigt der Wert deshalb nicht. Wir nutzen 100 Punkte und null Befunde in axe als Voraussetzung für die Prüfung von Hand, nicht als ihren Ersatz.
Aktion Mensch schreibt dazu: „Website-Overlays versprechen Barrierefreiheit auf einen Klick. Leider funktioniert es so einfach in der Regel nicht.“ Das Overlay Fact Sheet, unterzeichnet unter anderem von Mitwirkenden an WCAG, ARIA und HTML, hält fest, dass ein Overlay allein keine vollständige Einhaltung der Zugänglichkeitsstandards erreicht. Wir bauen Barrierefreiheit deshalb direkt in Inhalte, Gestaltung und Code ein, statt sie nachträglich über die fertige Website zu legen.
Jedes neue Bild, jede Tabelle und jedes PDF verändert den Stand der Website, deshalb sichern feste Regeln im Redaktionssystem die Struktur. Der Alternativtext ist dort ein Pflichtfeld, sodass kein Bild ohne Beschreibung veröffentlicht wird.
Laut John Mueller von Google ist Barrierefreiheit kein direkter Rankingfaktor, wobei er im März 2022 ergänzte, das könne sich mit der Zeit ändern. Alternativtexte nutzt Google laut eigener Dokumentation aber, um zusammen mit Bildanalyse und Seiteninhalt zu verstehen, was ein Bild zeigt. Ein guter Alternativtext hilft damit zugleich Menschen mit Screenreader und der Einordnung des Bildes in der Google-Bildersuche.
Eine andere Frage? Wir antworten in der Regel am selben Tag.
hello@hhcreative.de