Barrierefreie Webentwicklung: bestehenden Code WCAG 2.2 AA konform machen
Wir machen Ihre bestehende Website im vorhandenen Code barrierefrei — semantisches HTML, ARIA, Tastaturbedienung und Screenreader-Support nachgerüstet statt teurem Neubau. Remediation im Bestandscode ab 2.480 € netto, Zielkonformität WCAG 2.2 AA.
EN 301 549
Prüfgrundlage
28.06.2025
BFSG-Pflicht in Kraft
100.000 €
Bußgeld-Rahmen (BFSG §37)
50+
betreute Web-Projekte
Der Beweis läuft vor Ihren Augen
Nicht jede Website muss neu gebaut werden, um barrierefrei zu sein. In den meisten Fällen liegen die Barrieren im Markup, in fehlender ARIA-Auszeichnung, in der Tastaturführung und in Farbwerten — alles Punkte, die sich im vorhandenen Code korrigieren lassen. Wir machen Ihre bestehende Website im bestehenden System barrierefrei: semantisches HTML nachziehen, ARIA korrekt ergänzen, Tastaturbedienung und Fokusführung herstellen und Kontraste auf WCAG-Niveau heben. Bestehendes Design, Inhalte und Ihr Content-Management-System bleiben dabei erhalten. Wo ein Nachrüsten technisch nicht mehr wirtschaftlich ist, begleiten wir alternativ den barrierefreien Neubau — die Entscheidung treffen wir gemeinsam nach einer Sichtung des Codes. Zusätzlich befähigen wir Ihr Team über Code-Reviews, Schulungen und barrierefreie Komponentenbibliotheken.
Remediation im Bestandscode
- Barrieren im vorhandenen Code behoben — Design und CMS bleiben erhalten
- Semantisches HTML, WAI-ARIA 1.2, Tastaturbedienung und Fokusführung
- Screenreader-Test auf NVDA, JAWS und VoiceOver inklusive
- Abschluss mit Kurz-Audit und Nachweis der WCAG-2.2-AA-Konformität
Fester Angebotspreis nach kurzer Sichtung Ihres Codes. Größerer Umfang als KMU-Komplettpaket ab 4.900 € netto. Ein vollständiger barrierefreier Neubau ist ebenfalls ab 4.900 € möglich, wenn er technisch sinnvoller ist als das Nachrüsten.
Die Grundpfeiler barrierefreier Webentwicklung
Ob Neubau oder Nachrüsten im Bestandscode — barrierefreie Webentwicklung ruht auf vier technischen Grundpfeilern, die zusammenwirken, um eine Website für alle Nutzer zugänglich zu machen. Jeder Grundpfeiler adressiert spezifische Nutzerbedürfnisse und ist für die Konformität mit WCAG 2.2 AA unverzichtbar.
Semantisches HTML
Die korrekte Verwendung von HTML5-Elementen ist die Grundlage jeder barrierefreien Website. Überschriften (h1-h6) bilden eine logische Hierarchie, Landmarks (header, nav, main, aside, footer) ermöglichen schnelle Navigation, Listen (ul, ol, dl) strukturieren Aufzählungen und Formulare verwenden korrekte label-for-Zuordnungen. Screenreader nutzen diese Semantik, um Nutzern einen Überblick über die Seitenstruktur zu geben und effiziente Navigation zu ermöglichen.
WAI-ARIA 1.2
Wo natives HTML nicht ausreicht, ergänzt ARIA die fehlende Semantik. Rollen (role="tablist", role="dialog"), Zustände (aria-expanded, aria-selected) und Eigenschaften (aria-label, aria-describedby) machen interaktive Widgets für assistive Technologien verständlich. Wichtig: ARIA ist ein Ergänzungswerkzeug, kein Ersatz für semantisches HTML. Die erste Regel von ARIA lautet: Verwende kein ARIA, wenn ein natives HTML-Element die Aufgabe erfüllt (Quelle: W3C WAI).
Tastaturnavigation
Alle interaktiven Elemente müssen per Tastatur erreichbar und bedienbar sein (WCAG 2.1.1). Die Tab-Reihenfolge muss der visuellen Lesereihenfolge entsprechen. Fokus-Indikatoren müssen sichtbar sein und einen ausreichenden Kontrast aufweisen. Modale Dialoge müssen den Fokus korrekt einfangen und beim Schließen zum auslösenden Element zurücksetzen. Dropdown-Menüs müssen per Pfeiltasten navigierbar sein.
Screenreader-Kompatibilität
Eine Website ist erst dann barrierefrei, wenn sie mit echten Screenreadern nutzbar ist. NVDA und JAWS auf Windows sowie VoiceOver auf macOS und iOS interpretieren HTML und ARIA unterschiedlich. Wir testen und optimieren für alle drei Plattformen und stellen sicher, dass Inhalte, Navigation und interaktive Elemente korrekt ausgegeben und bedienbar sind.
Nachrüsten im Bestandscode statt teurem Neubau
Barrierefrei ohne das Projekt neu zu starten
Eine bestehende Website muss nicht neu gebaut werden, um barrierefrei zu sein. In den meisten Fällen liegen die Barrieren in Markup, ARIA-Auszeichnung, Fokusführung und Farbwerten — allesamt im vorhandenen Code korrigierbar. Wir arbeiten in Ihrer produktiven Codebasis, halten Design und Funktionsumfang und heben die Konformität gezielt an, statt das Projekt von vorne zu beginnen. So bleibt die Investition in Ihre heutige Website erhalten, während die Zugänglichkeit auf WCAG-2.2-AA-Niveau steigt.
- Remediation im Bestandscode ab 2.480 € netto (bis 15 Seiten)
- Kein Rebuild: bestehendes Design und CMS bleiben erhalten
- Kompletter barrierefreier Neubau nur, wenn technisch sinnvoller — ab 4.900 €
Barrierefreie Komponentenentwicklung
Moderne Websites bestehen aus wiederverwendbaren Komponenten: Navigation, Tabs, Akkordeons, Modale, Dropdowns, Karusselle, Tooltips und Formulare. Jede dieser Komponenten hat spezifische Barrierefreiheitsanforderungen, die in den WAI-ARIA Authoring Practices 1.2 definiert sind (Quelle: W3C WAI-ARIA Practices). Wir korrigieren diese Komponenten direkt im Bestandscode oder entwickeln sie neu, sodass sie die Patterns korrekt implementieren und sich nahtlos in Ihr Design-System einfügen.
Navigation und Menüs
Barrierefreie Hauptnavigation mit korrektem role="navigation", aria-label und Unterstützung für Untermenüs per Tastatur (Pfeiltasten, Enter, Escape). Mobile Hamburger-Menüs mit aria-expanded und korrekter Fokussteuerung beim Öffnen und Schließen.
Tabs und Akkordeons
Implementierung nach WAI-ARIA Authoring Practices: Tabs mit role="tablist"/"tab"/"tabpanel", Pfeiltastennavigation und automatischem Fokusmanagement. Akkordeons mit aria-expanded, aria-controls und korrekter Überschriftensemantik.
Modale Dialoge
Modale mit role="dialog", aria-modal="true", korrekter Fokus-Falle (Focus Trap), die den Tab-Fokus innerhalb des Modals hält, Schließen per Escape-Taste und Rücksetzung des Fokus auf das auslösende Element nach dem Schließen.
Autovervollständigung und Comboboxen
Suchfelder mit Autovervollständigung als role="combobox" mit aria-expanded, aria-activedescendant und role="listbox" für die Vorschlagsliste. Pfeiltastennavigation durch Vorschläge und ARIA-Live-Ankündigung der Ergebnisanzahl.
Dynamische Statusmeldungen
ARIA-Live-Regionen (aria-live="polite" oder "assertive") für Statusmeldungen, Formularvalidierung, Ladefortschritt und Benachrichtigungen. Korrekte Verwendung von role="alert", role="status" und role="log" je nach Dringlichkeit und Kontext.
Formulare und Validierung
Barrierefreie Formulare mit sichtbaren Labels, aria-required für Pflichtfelder, aria-invalid und aria-describedby für Fehlermeldungen, Gruppierung zusammengehöriger Felder mit fieldset/legend und aussagekräftige Fehlertexte mit Korrekturhinweisen.
Farbkontraste und visuelle Barrierefreiheit
Kontrast ist messbar, nicht Geschmackssache
Farbwerte auf WCAG-Niveau, ohne das Design zu verlieren
WCAG 2.2 fordert einen Mindestkontrast von 4,5:1 für normalen Text und 3:1 für großen Text (ab 18pt oder 14pt fett, Erfolgskriterium 1.4.3). Darüber hinaus dürfen Informationen nicht allein durch Farbe vermittelt werden (1.4.1), der Textabstand muss anpassbar sein (1.4.12) und Inhalte müssen bei 200 Prozent Zoom ohne horizontales Scrollen nutzbar bleiben (1.4.10). Beim Nachrüsten passen wir die Farbwerte Ihrer bestehenden Palette so an, dass diese Verhältnisse erfüllt sind und der visuelle Charakter Ihrer Marke erhalten bleibt.
Fokus-Indikatoren nicht vergessen
Automatisierte Barrierefreiheitstests in CI/CD
Damit die einmal hergestellte Barrierefreiheit erhalten bleibt, verankern wir Prüfungen im Entwicklungsprozess statt in einem nachgelagerten Schritt. Automatisierte Tests in Ihrer CI/CD-Pipeline erkennen WCAG-Verstöße bereits beim Commit, lange bevor sie die Produktion erreichen — so fällt eine neue Barriere sofort auf und nicht erst bei der nächsten Prüfung.
Automatisiert plus manuell
Responsive und mobile Barrierefreiheit
Mobile Barrierefreiheit stellt zusätzliche Anforderungen: Touch-Zielgebiete müssen gemäß WCAG 2.5.8 mindestens 24x24 CSS-Pixel groß sein. VoiceOver auf iOS und TalkBack auf Android interpretieren HTML und ARIA teilweise anders als Desktop-Screenreader. Gesten-basierte Navigation (Wischen, Drehen) muss für Nutzer verfügbar sein, die Bedienungshilfen aktiviert haben. Wir testen auf realen Geräten mit aktivierten Screenreadern, nicht nur in Browser-Emulatoren.
Mit echten Screenreadern getestet
Was der Screenreader ansagt, entscheidet
Ein bestandenes automatisiertes Ergebnis bedeutet noch nicht, dass eine Seite mit einem Screenreader gut nutzbar ist. Deshalb prüfen wir Ihre nachgerüsteten Komponenten manuell mit NVDA und JAWS auf Windows sowie VoiceOver auf macOS und iOS und hören, was tatsächlich angesagt wird: sind Rolle, Name und Zustand jedes Elements korrekt? Erst wenn Navigation, Formulare und Statusmeldungen auf allen drei Plattformen schlüssig ausgegeben werden, gilt eine Komponente als fertig.
- Test auf echten Geräten statt nur im Emulator
- Rolle, Name und Zustand jedes interaktiven Elements geprüft
- Ausgabe auf NVDA, JAWS und VoiceOver abgeglichen
Responsive Design und Barrierefreiheit überschneiden sich in mehreren Bereichen. Die Reflow-Anforderung (WCAG 1.4.10) verlangt, dass Inhalte bei 400 Prozent Zoom (entspricht 320 CSS-Pixel Viewport-Breite) ohne horizontales Scrollen nutzbar bleiben. Mobile-First-Entwicklung mit flexiblen Layouts erfüllt diese Anforderung in der Regel automatisch. Darüber hinaus müssen Touch-Event-Handler auch Tastaturinteraktionen unterstützen, und Hover-Effekte brauchen Touch-Äquivalente für mobile Nutzer.
Frameworks und Bibliotheken barrierefrei einsetzen
Moderne Webanwendungen basieren auf JavaScript-Frameworks wie React, Vue, Angular oder Svelte. Diese Frameworks bringen eigene Herausforderungen für die Barrierefreiheit mit: clientseitiges Routing unterbricht die natürliche Seitennavigation von Screenreadern, dynamisch gerenderte Inhalte werden möglicherweise nicht von assistiven Technologien erkannt, und virtuelle DOM-Implementierungen können Fokusmanagement komplizieren.
Wir kennen die barrierefreiheitsrelevanten Besonderheiten der gängigen Frameworks und wissen, wie man sie im Bestandscode korrekt adressiert. Unabhängig vom Framework gilt: clientseitiges Routing muss den Seitentitel aktualisieren und den Fokus korrekt setzen, dynamische Inhalte müssen per ARIA-Live-Region angekündigt werden und Zustandsänderungen müssen an assistive Technologien kommuniziert werden. Diese Anpassungen nehmen wir gezielt in Ihrer vorhandenen Anwendung vor, ohne die Architektur umzuwerfen.
Single-Page-Applications barrierefrei gestalten
Single-Page-Applications (SPAs) ersetzen das traditionelle Seitenlade-Modell durch clientseitiges Routing. Klickt ein Nutzer auf einen Link, wird keine neue Seite geladen, sondern der Inhalt dynamisch ersetzt. Screenreader erkennen diesen Wechsel nicht automatisch: Blinde Nutzer wissen nicht, dass sich der Inhalt geändert hat. Die Lösung ist aktives Fokusmanagement bei jedem Routenwechsel.
- 1
Routenwechsel erkennen
Der Router signalisiert den Wechsel. Hier setzt das Fokusmanagement an, statt sich auf das native Seitenladen zu verlassen.
- 2
Seitentitel aktualisieren
Der document.title wird auf den neuen Inhalt gesetzt, damit Screenreader und Verlauf den Kontext korrekt wiedergeben.
- 3
Fokus setzen
Der Fokus springt auf den neuen Hauptinhalt (oder eine h1), damit die Tastaturnavigation am richtigen Punkt fortsetzt.
- 4
Wechsel ankündigen
Eine ARIA-Live-Region (aria-live="polite") meldet den neuen Seitenkontext, ohne den Lesefluss abrupt zu unterbrechen.
| Statusmeldung | ARIA-Mechanismus | Verhalten |
|---|---|---|
| Ladevorgang | role="status" | höflich, unterbricht nicht |
| Erfolgsmeldung | aria-live="polite" | informiert nach aktuellem Lesefluss |
| Fehlermeldung | role="alert" / aria-live="assertive" | sofort, unterbricht |
| Formularvalidierung | aria-invalid + aria-describedby | Feld und Fehlertext verknüpft |
Diese Patterns erfordern ein systematisches Konzept für die Statusmeldungsarchitektur der gesamten Anwendung, nicht nur punktuelle Korrekturen.
Ihre bestehende Website barrierefrei machen
Wir prüfen Ihren Code, beheben die Barrieren im vorhandenen System und weisen die WCAG-2.2-AA-Konformität nach — ohne Neubau, zum Festpreis nach Sichtung.
Design-Systeme mit Barrierefreiheit als Kernprinzip
Wenn Ihr Unternehmen ein Design-System oder eine Komponentenbibliothek nutzt, ist die Integration von Barrierefreiheit auf dieser Ebene der effizienteste Ansatz. Einmal korrekt implementierte barrierefreie Komponenten werden in jeder Instanz automatisch barrierefrei, ohne dass Entwickler bei jeder Verwendung manuell ARIA-Attribute hinzufügen müssen. Wir unterstützen bei der Entwicklung barrierefreier Komponentenbibliotheken, die die WAI-ARIA Authoring Practices korrekt implementieren: Tabs mit automatischem Fokusmanagement, Modale mit korrekter Fokus-Falle, Dropdown-Menüs mit Pfeiltastennavigation und Formulare mit programmatisch verknüpfter Validierung.
Ein barrierefreies Design-System dokumentiert für jede Komponente nicht nur die visuellen Spezifikationen (Farben, Abstände, Typografie), sondern auch die Barrierefreiheitsanforderungen: welche ARIA-Rollen und -Attribute erforderlich sind, wie die Tastaturinteraktion funktioniert, welche Screenreader-Ausgabe erwartet wird und welche Varianten für verschiedene Kontexte verfügbar sind. Langfristig reduziert ein barrierefreies Design-System die Kosten für Barrierefreiheitsprüfungen und Remediationen erheblich, da systemische Probleme an einer zentralen Stelle behoben werden.
Performance und Barrierefreiheit: Zwei Seiten einer Medaille
Barrierefreie Webentwicklung und Performance-Optimierung gehen Hand in Hand. Sauberer, semantisch korrekter Code ist leichter zu parsen, leichter zu cachen und erzeugt weniger Reflows im Browser. Korrekte Überschriftenhierarchien und Landmarks reduzieren komplexe CSS-Selektoren und JavaScript-basierte Layoutanpassungen, und der Verzicht auf ARIA-Workarounds zugunsten nativer HTML-Elemente verkleinert die JavaScript-Payload.
LCP
Largest Contentful Paint profitiert von optimierten Bildern mit korrekten Dimensionsattributen, die auch für Alt-Texte relevant sind.
CLS
Cumulative Layout Shift verbessert sich durch korrekte Bildgrößen und stabile Layouts, die zugleich die Reflow-Anforderung WCAG 1.4.10 erfüllen.
INP
Interaction to Next Paint wird durch effiziente Event-Handler verbessert, die Maus- und Tastaturereignisse gleichermaßen korrekt verarbeiten.
Wir optimieren Websites daher immer ganzheitlich: Barrierefreiheit und Performance als gemeinsames Ziel, nicht als konkurrierende Anforderungen.
Dokumentation und Wissenstransfer
Barrierefreie Webentwicklung erfordert spezialisiertes Wissen, das im Team geteilt werden muss. Deshalb legen wir großen Wert auf Dokumentation und Wissenstransfer. Für jede barrierefreie Komponente, die wir im Bestandscode korrigieren oder neu entwickeln, erstellen wir eine Dokumentation, die Folgendes umfasst: die ARIA-Rollen und -Attribute mit Erklärung, das erwartete Tastaturverhalten mit einer Übersicht aller unterstützten Tasten, die erwartete Screenreader-Ausgabe mit Transkripten für NVDA und VoiceOver, visuelle Spezifikationen für Fokus-Indikatoren und Kontrastverhältnisse sowie Varianten und Zustände der Komponente.
Barrierefreie Webentwicklung ist keine Einschränkung der kreativen oder technischen Möglichkeiten, sondern eine Erweiterung der Qualitätsansprüche. Teams, die Barrierefreiheit als selbstverständlichen Bestandteil ihres Handwerks begreifen, entwickeln besseren Code: sauberer, semantischer, wartbarer und performanter. Die Investition in barrierefreie Entwicklungskompetenz zahlt sich über Jahre hinweg aus, denn sie verbessert nicht nur die Zugänglichkeit, sondern die gesamte technische Qualität jedes Projekts. Kontaktieren Sie uns, um über die barrierefreie Überarbeitung Ihrer bestehenden Website zu sprechen.
Das Wichtigste in Kürze
- Barrierefreie Webentwicklung als Remediation im bestehenden Code — kein Neubau, ab 2.480 € netto (bis 15 Seiten)
- Vier Grundpfeiler: semantisches HTML, WAI-ARIA 1.2, Tastaturbedienung und Screenreader-Kompatibilität
- Automatisierte Tests in der CI/CD-Pipeline decken 30 bis 50 Prozent der Barrieren ab (WebAIM 2024) — den Rest prüfen wir manuell
- Getestet auf echten Geräten mit NVDA, JAWS und VoiceOver, Ziel ist WCAG 2.2 AA
- Der Beweis: Diese Website erfüllt selbst WCAG 2.2 AA — nachzulesen in der Barrierefreiheitserklärung