Zum Inhalt springen

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.

Bestehender Code, kein Neubau WCAG 2.2 AA Eigene Erklärung zur Barrierefreiheit veröffentlicht Remediation ab 2.480 €

Kurz und einfach erklärt

Hier geht es um Ihre Webseite. Wir machen sie barrierefrei. Barrierefrei heißt: Alle Menschen können die Seite nutzen. Auch Menschen mit Behinderung.

Meist muss Ihre Seite dafür nicht neu gebaut werden. Wir ändern den Code, den es schon gibt. Design und Inhalte bleiben.

Man soll die Seite mit der Tastatur bedienen können. Auch Programme, die Text vorlesen, sollen sie gut lesen. Farben passen wir so an, dass man den Text gut sieht.

Ist ein Umbau nicht sinnvoll, ist auch ein neuer Bau möglich. Das klären wir mit Ihnen, wenn wir den Code kennen. Am Ende prüfen wir das Ergebnis.

Sie haben Fragen? Die erste Beratung kostet nichts. Schreiben Sie uns oder rufen Sie uns an.

Kennzahlen

EN 301 549

Prüfgrundlage

28.06.2025

BFSG-Pflicht in Kraft

100.000 €

Bußgeld-Rahmen (BFSG §37)

WCAG 2.2 AA

Zielniveau der Remediation

Eigener Stand, offen dokumentiert

Unsere eigene Website bewerten wir selbst nach WCAG 2.2 AA; Stand und bekannte Einschränkungen stehen in unserer Erklärung zur Barrierefreiheit. Barrierefreie Webentwicklung setzen wir dort um, wo sie zählt: in echtem, ausgeliefertem Produktionscode. Seit dem 28. Juni 2025 ist digitale Barrierefreiheit für viele Anbieter Pflicht (BFSG); bei Verstößen drohen behördliche Anordnungen und Bußgelder bis zu 100.000 € (BFSG §37).

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.

Barrierefreiheit von Grund auf · Retrofit im Bestandscode
Fünf Ebenen auf dem Weg zu WCAG 2.2 AA
Im bestehenden Code nachgerüstet — ohne Neubau, jede Ebene einzeln geprüft
1
Semantisches HTML
Landmarks header/nav/main/footer, saubere Überschriftenhierarchie
1.3.1
2
ARIA-Rollen & Zustände
Namen und Rollen dort ergänzt, wo natives HTML nicht ausreicht
4.1.2
3
Farbkontrast
Von 2,1 : 1 auf 8,4 : 1 angehoben — ohne das Design zu verlieren
1.4.3
4
Sichtbarer Fokus & Tastatur
Fokus-Indikator wiederhergestellt, logischer Tastaturpfad
2.4.7
5
Screenreader-Ausgabe
Gegenprüfung von Tastatur und Screenreader-Ausgabe, Desktop und Smartphone
4.1.3
Abschluss mit Kurz-Audit nach der UmsetzungZiel: AA in allen 4 Prinzipien
Remediation im Bestandscodeab 2.480 €
ZielkonformitätWCAG 2.2 AA
Fünf Ebenen der Remediation im bestehenden Code, ohne Neubau — je Ebene ein zugehöriges WCAG-Erfolgskriterium. Beispielhafte Darstellung — Werte illustrativ.

Remediation im Bestandscode

ab 2.480 € Festpreis netto · bis 15 Seiten
  • Barrieren im vorhandenen Code behoben — Design und CMS bleiben erhalten
  • Semantisches HTML, WAI-ARIA 1.2, Tastaturbedienung und Fokusführung
  • Prüfung von Tastatur und Ausgabe für Screenreader inklusive
  • Abschluss mit Kurz-Audit und dokumentiertem Stand nach WCAG 2.2 AA

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.

Preisstand: Oktober 2026.

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

Screenreader können nur ausgeben, was die Seite ihnen übergibt. Screenreader auf Windows, macOS und iOS interpretieren HTML und ARIA teils unterschiedlich; gemeinsame Grundlage ist, was der Browser an die Zugänglichkeitsschnittstelle übergibt. Diese Ausgabe prüfen und optimieren wir, damit Inhalte, Navigation und interaktive Elemente mit Name, Rolle und Zustand übergeben werden 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 Schritt für Schritt auf WCAG 2.2 AA hin verbessert wird.

  • 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 €
Relativer Aufwand je Weg zur Konformität (schematisch)Bestandscode günstiger
RemediationDauer-PatchNeubau
Remediation im Bestandscodeab 2.480 €bis 15 Seiten, netto
Kompletter Neubauab 4.900 €nur wenn sinnvoller

Barrierefreie Komponentenentwicklung

Moderne Websites bestehen aus wiederverwendbaren Komponenten: Navigation, Tabs, Akkordeons, Modale, Dropdowns, Karusselle, Tooltips und Formulare. Jede dieser Komponenten hat spezifische Barrierefreiheitsanforderungen, die im ARIA Authoring Practices Guide des W3C beschrieben sind (Quelle: W3C WAI). 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 Text muss sich ohne Verlust von Inhalt oder Funktion auf 200 Prozent vergrößern lassen (1.4.4). 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.

Zu wenig Kontrast
Hellgrauer Text auf Weiß2,1 : 1unter 4,5 : 1
Ausreichend Kontrast
Lesbarer Text auf Weiß8,4 : 1AA erfüllt
WCAG-Schwellen 1.4.3 und 1.4.11 (Level AA)
Normaltext≥ 4,5 : 1
Großtext ab 18 pt≥ 3 : 1
Bedienelemente & Fokus≥ 3 : 1

Fokus-Indikatoren nicht vergessen

Besondere Aufmerksamkeit erfordern Fokus-Indikatoren, Formular-Fehlerzustände und interaktive Elemente in den Zuständen hover, active und disabled. Jeder Zustand muss ausreichend kontrastreich sein, und der Fokus-Indikator muss auch auf komplexen Hintergründen sichtbar bleiben.

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 automatisch prüfbare WCAG-Verstöße bereits beim Commit, lange bevor sie die Produktion erreichen — so fallen solche Barrieren sofort auf und nicht erst bei der nächsten Prüfung.

Barrierefreiheit als Teil der Entwicklung
Jeder Commit wird automatisch mitgeprüft
Commit
Automatische Prüfung
Manuelle Hinweise
Merge freigegeben
94 %
Automatisierte Prüfung52 Regeln geprüft49 bestanden3 Hinweise manuell
Prüfschritte im Commit
Semantische Landmarks vorhanden
Alle Formularfelder mit Label
Tab-Reihenfolge logisch
Kontrast: 2 Farbpaare zur Sichtprüfung
Verstöße erkanntschon beim Commit
Automatisch erkennbarnicht alles (WebAIM 2026)
Barrierefreiheitstests laufen bei jedem Commit mit — Verstöße werden erkannt, bevor sie live gehen. Beispielhafte Darstellung — Werte illustrativ.

Messung plus Bewertung

Automatisierte Tests erkennen neue Barrieren sofort, ersetzen aber nicht die Bewertung je Kriterium: Nicht alle Konformitätsfehler lassen sich automatisch erkennen (WebAIM Million 2026). Deshalb kombinieren wir Pipeline-Tests mit regelmäßigen WCAG 2.2 Audits.

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. Mobile Screenreader 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 prüfen jede Ansicht auch in der Smartphone-Darstellung, einschließlich Zielgrößen und Umbruch.

Was Screenreader ansagen können

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 für jede nachgerüstete Komponente, was sie an Screenreader übergibt: sind Rolle, Name und Zustand jedes Elements korrekt? Erst wenn Navigation, Formulare und Statusmeldungen in der Desktop- und der Smartphone-Darstellung schlüssig übergeben werden, gilt eine Komponente als fertig.

  • Desktop- und Smartphone-Darstellung geprüft
  • Rolle, Name und Zustand jedes interaktiven Elements geprüft
  • Name, Rolle und Zustand je Element dokumentiert
Fokus
Anmelden
E-Mail-Adresse
Anmelden
Screenreader-Ausgabe
Hauptnavigation, Liste mit 4 Einträgen
E-Mail-Adresse, Eingabefeld, erforderlich
Anmelden, Schaltfläche
Name, Rolle, ZustandDesktop · Smartphone

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. 1

    Routenwechsel erkennen

    Der Router signalisiert den Wechsel. Hier setzt das Fokusmanagement an, statt sich auf das native Seitenladen zu verlassen.

  2. 2

    Seitentitel aktualisieren

    Der document.title wird auf den neuen Inhalt gesetzt, damit Screenreader und Verlauf den Kontext korrekt wiedergeben.

  3. 3

    Fokus setzen

    Der Fokus springt auf den neuen Hauptinhalt (oder eine h1), damit die Tastaturnavigation am richtigen Punkt fortsetzt.

  4. 4

    Wechsel ankündigen

    Eine ARIA-Live-Region (aria-live="polite") meldet den neuen Seitenkontext, ohne den Lesefluss abrupt zu unterbrechen.

StatusmeldungARIA-MechanismusVerhalten
Ladevorgangrole="status"höflich, unterbricht nicht
Erfolgsmeldungaria-live="polite"informiert nach aktuellem Lesefluss
Fehlermeldungrole="alert" / aria-live="assertive"sofort, unterbricht
Formularvalidierungaria-invalid + aria-describedbyFeld 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

Design-Systeme mit Barrierefreiheit als Kernprinzip

Wenn Ihr Unternehmen ein Design-System oder eine Komponentenbibliothek nutzt, ist die Integration von Barrierefreiheit auf dieser Ebene in der Regel der effizienteste Ansatz. Einmal korrekt implementierte barrierefreie Komponenten bringen Tastaturbedienung, Rollen und Zustände in jede Instanz mit, 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 kann ein barrierefreies Design-System die Kosten für Barrierefreiheitsprüfungen und Remediationen deutlich senken, da systemische Probleme an einer zentralen Stelle behoben werden.

Performance und Barrierefreiheit: Zwei Seiten einer Medaille

Barrierefreie Webentwicklung und Performance-Optimierung gehen oft Hand in Hand. Native HTML-Elemente bringen Semantik und Tastaturbedienung bereits mit; wer auf ARIA-Workarounds zugunsten nativer Elemente verzichtet, verkleinert damit häufig auch die JavaScript-Payload.

LCP

Largest Contentful Paint profitiert von optimierten Bildern; wer die Bildelemente ohnehin überarbeitet, kann im selben Schritt passende Alt-Texte ergänzen.

CLS

Cumulative Layout Shift verbessert sich durch korrekte Bildgrößen und stabile Layouts; ein flexibles Layout hilft zugleich bei der Reflow-Anforderung WCAG 1.4.10.

INP

Interaction to Next Paint wird durch effiziente Event-Handler verbessert, die Maus- und Tastaturereignisse gleichermaßen korrekt verarbeiten.

Wir behandeln Barrierefreiheit und Performance daher 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 Ausgabe für Screenreader: Name, Rolle und Zustand, 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 in der Regel besseren Code: sauberer, semantischer und wartbarer. Die Investition in barrierefreie Entwicklungskompetenz kann sich über Jahre hinweg auszahlen, denn sie verbessert nicht nur die Zugänglichkeit, sondern oft auch die technische Qualität eines Projekts insgesamt. Kontaktieren Sie uns, um über die barrierefreie Überarbeitung Ihrer bestehenden Website zu sprechen.

Technische Vertiefung zu häufigen Baustellen

Drei Themen, die in der Remediation häufig anfallen, haben wir ausführlich beschrieben: Tastaturnavigation in der Webentwicklung als Grundlage jeder Bedienbarkeit, ARIA-Rollen, -Zustände und Live-Regions für dynamische Komponenten und das Fokus-Management in Single-Page-Apps, wo Framework-Routing regelmäßig den Fokus verliert. Welche Schwerpunkte in Ihrem Umfeld gelten, ordnet die Übersicht Barrierefreiheit nach Branche ein.

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 erkennen nicht alle Konformitätsfehler (WebAIM Million 2026) — den Rest bewerten wir je Kriterium
  • Tastatur und Ausgabe für Screenreader geprüft, in der Desktop- und der Smartphone-Darstellung, Ziel ist WCAG 2.2 AA
  • Unsere eigene Website bewerten wir selbst nach WCAG 2.2 AA; Stand und bekannte Einschränkungen stehen in unserer Erklärung zur Barrierefreiheit

Häufige Fragen zur barrierefreien Webentwicklung

So könnte das Kundenportal von Stadtwerken aussehen

Der Entwurf zeigt Aufbau und Bedienung: kurze Wege zu Zählerstand und Abschlag, ein Formular mit Fehlerhinweis am Feld, Leichte Sprache und Schriftgröße im Kopf. Der Versorger darin ist erfunden.

Entwurf
Kommunaler Versorger

Kundenportal mit Selbstbedienung und Leichter Sprache

Ein Entwurf für ein Stadtwerke-Portal: Zählerstand melden, Abschlag ändern und Umzug eintragen liegen als sechs kurze Wege nebeneinander, das Formular prüft die Eingaben und stellt den Fehler als Text direkt an das Feld. Der Meldeweg bei Störungen steht in vier Schritten da, der Tarifvergleich als Tabelle mit beschrifteten Spalten und Zeilen. Schriftgröße und Leichte Sprache lassen sich im Kopf der Seite umschalten.

Leichte SpracheSchriftgrößeFormularprüfungStörungsmeldung

Exemplarische Layoutentwürfe zur Veranschaulichung. Die gezeigten Betriebe sind erfunden; es handelt sich nicht um Kundenprojekte.

Worum geht es?

Ein Klick genügt — alles Weitere ist freiwillig.

Erzählen Sie kurz vom Projekt

Alle Angaben hier sind freiwillig.

So, wie die Adresse im Browser steht, mit oder ohne https://.

Wann soll es losgehen? (optional)
Grober Budgetrahmen (optional)

Freiwillig — festlegen müssen Sie sich damit nicht.

Stichworte genügen. Wenn Sie etwas schreiben, bitte mindestens 5 Zeichen.

Wie erreichen wir Sie?

Wir melden uns in der Regel innerhalb eines Werktages.

Ihr Name oder Ihr Nachname, mindestens 2 Zeichen.

Nur nötig, wenn Sie einen Rückruf wünschen.

Die Adresse, an die unsere Antwort gehen soll, mit @ und Domain.

Mit dem Absenden stimmen Sie der Verarbeitung Ihrer Angaben zur Bearbeitung der Anfrage zu. Details in der Datenschutzerklärung.