Barrierefreies Webdesign
Barrierefreies Webdesign —
BFSG-konform, WCAG 2.2 AA, ohne Panik
Seit dem 28. Juni 2025 verpflichtet das Barrierefreiheitsstärkungsgesetz (BFSG) viele Websites zu echter Barrierefreiheit. Wir auditieren deine Site nach WCAG 2.2 AA, beheben die Verstöße, schulen deine Redaktion — sachlich, rechtssicher, ohne unnötiges Drama.
Rechtslage
Warum Barrierefreiheit 2026 Pflicht ist
Das Barrierefreiheitsstärkungsgesetz, kurz BFSG, ist seit dem 28. Juni 2025 in Kraft. Es setzt die European Accessibility Act (EAA) der EU in deutsches Recht um und verpflichtet Anbieter bestimmter digitaler Dienstleistungen dazu, ihre Websites und mobilen Anwendungen barrierefrei zu gestalten. Konkret betroffen sind unter anderem Online-Shops aller Größen, Buchungs- und Reservierungsplattformen, Bankdienstleistungen, E-Book- und Telekommunikations-Anbieter sowie Personenbeförderungsdienste.
Eine Ausnahme gibt es für Kleinstunternehmen — also Anbieter mit weniger als 10 Mitarbeitenden und unter 2 Mio. € Jahresumsatz. Diese Ausnahme greift aber nur kumulativ, nicht alternativ. Wer eine der beiden Schwellen reißt, ist betroffen. Reine B2B-Sites ohne Verbraucher-Funktion sind formal nicht erfasst, sollten aber aus Compliance-Risiko-Sicht und wegen der starken Überlappung mit SEO-Foundations ebenfalls auf Barrierefreiheit ausgelegt sein.
Die Sanktionen sind nicht symbolisch: Marktüberwachungsbehörden der Bundesländer können Bußgelder bis 100.000 € pro Verstoß verhängen, gravierende Mängel führen zur behördlichen Anordnung der Marktrücknahme — also faktisch zur Abschaltung der Site oder App. Hinzu kommen zivilrechtliche Risiken durch Verbände und betroffene Nutzer, ähnlich der DSGVO-Abmahnwelle vor einigen Jahren. Wer länger als ein Jahr ohne Audit unterwegs ist, baut eine Risikoposition auf.
Die gute Nachricht: Barrierefreiheit ist kein „Add-on“, das man am Ende drüberbügelt, sondern ein Qualitätsmerkmal, das bei sauberer Bauweise weitgehend automatisch entsteht. Wer semantisches HTML, vernünftige Kontraste und saubere Form-Logik verwendet, hat einen großen Teil der WCAG-2.2-AA-Anforderungen ohnehin erfüllt — der Rest ist überschaubarer Aufwand. Mehr rechtliche Hintergründe haben wir im ausführlichen BFSG-Artikel zusammengefasst.
Eckdaten BFSG
- In Kraft seit 28.06.2025
- Standard: WCAG 2.2 AA
- Bußgeld bis 100.000 €
- Marktrücknahme möglich
- Ausnahme nur < 10 MA + < 2 Mio. €
- Pflicht-Erklärung zur Barrierefreiheit
- Feedback-Mechanismus erforderlich
Grundlagen
Was barrierefreies Webdesign konkret bedeutet
Die WCAG 2.2 ist die internationale Norm, an der sich auch das BFSG orientiert. Sie strukturiert Barrierefreiheit in vier Kern-Achsen, die das gesamte Spektrum digitaler Zugänglichkeit abdecken — von der Sehfähigkeit über die motorische Bedienbarkeit bis zur kognitiven Verständlichkeit und der technischen Robustheit gegenüber Hilfstechnologien.
Wahrnehmbar
Inhalte müssen so präsentiert werden, dass alle Nutzer sie wahrnehmen können — unabhängig davon, ob sie mit den Augen, mit Screen-Reader oder mit vergrößertem Kontrast arbeiten. Konkret: ausreichend Kontrast, Alt-Texte für Bilder, Untertitel für Video, skalierbare Schrift.
Bedienbar
Jede Funktion muss mit Tastatur erreichbar sein — ohne Tastatur-Fallen, mit sichtbarem Fokus, mit ausreichend Zeit für Eingaben. Wer eine Maus nicht zuverlässig bedienen kann, darf nicht ausgeschlossen werden. Auch Klick-Ziele müssen groß genug sein.
Verständlich
Sprache, Navigation und Interaktionen müssen vorhersehbar sein. Klare Beschriftungen, konsistente Menüs, sinnvolle Fehlermeldungen. Eine Website, die bei jedem Klick anders reagiert, ist für niemanden gut — für Menschen mit kognitiven Einschränkungen unbenutzbar.
Robust
Der Code muss so sauber sein, dass aktuelle und zukünftige Hilfstechnologien (Screen-Reader, Sprachsteuerung, Braille-Zeilen) ihn korrekt interpretieren. Semantisches HTML statt div-Wüste, ARIA nur dort, wo es nötig ist — und nie als Pflaster für falsches Markup.
Bausteine
10 Bausteine barrierefreies Webdesign
Die WCAG-Norm umfasst über 50 Erfolgskriterien — die folgenden zehn sind die Bausteine, an denen typische KMU-Sites am häufigsten scheitern. Wer diese sauber umsetzt, hat etwa 80 % der relevanten Befunde schon im Griff. Der Rest sind Detailfragen, die im Audit sichtbar werden.
Farbkontrast 4.5:1 / 3:1
Body-Text braucht mindestens 4.5:1 Kontrast zur Hintergrundfarbe, große Schrift (ab 18pt fett oder 24pt regulär) mindestens 3:1. Das beliebte #777-Grau auf weißem Hintergrund liegt bei nur 4.48:1 — formal durchgefallen. Wir prüfen jede Farbkombination mit dem Color-Contrast-Analyzer.
Sichtbare Fokus-Indikatoren
Wer sich mit der Tab-Taste durch die Seite bewegt, muss jederzeit sehen, wo er gerade steht. CSS-Reset, das outline: none setzt, ohne Ersatz zu liefern, ist ein klassischer WCAG-Verstoß. Wir nutzen :focus-visible mit klar erkennbaren Outline-Stilen — auch im Hover-Zustand.
Tastatur-Navigation ohne Fallen
Tab, Shift-Tab, Enter, Space, Esc müssen in jeder Komponente sinnvoll funktionieren. Modals dürfen Fokus nicht ins Nirgendwo verlieren, Dropdowns müssen schließbar sein, Karussells dürfen Nutzer nicht in einer Endlosschleife einsperren. Wir testen jede Seite Tab-only, ohne Maus.
Skip-Links zum Hauptinhalt
Ein „Zum Inhalt springen“-Link am Anfang jeder Seite spart Screen-Reader-Nutzern und Tastatur-Bedienern dutzende Tab-Stops durch das Menü. Der Link wird nur sichtbar, wenn der Fokus ihn erreicht — sonst unsichtbar. Pflicht, technisch trivial, oft vergessen.
Alt-Texte differenziert
Sinngebende Bilder bekommen einen beschreibenden Alt-Text, der den Bildinhalt im Kontext zusammenfasst. Reine Dekobilder bekommen ein leeres alt="" — sonst liest der Screen-Reader unnötig „Grafik“ vor. Logos, Buttons mit Bild, komplexe Diagramme: jeweils eigene Regeln, die wir in Schulungen erklären.
Form-Labels & Fehlermeldungen
Jedes Eingabefeld braucht ein <label>-Element, das mit der ID des Inputs verknüpft ist — Placeholder allein reichen nicht. Fehlermeldungen werden über aria-describedby an das Feld gebunden und nach Möglichkeit mit role="alert" angekündigt, damit Screen-Reader sie sofort vorlesen.
Heading-Hierarchie ohne Sprünge
Eine H1 pro Seite, danach H2 für Hauptsektionen, H3 für Untersektionen. Kein Sprung von H1 direkt zu H4, weil das im Screen-Reader-Outline wie ein fehlendes Glied wirkt. Headings sind Navigation, nicht Schmuck — viele Page-Builder verstoßen hier reihenweise.
ARIA nur wo nötig
Die erste Regel von ARIA: kein ARIA verwenden, wenn natives HTML reicht. Ein <button> ist immer besser als ein <div role="button">. ARIA wird gefährlich, wenn es falsch eingesetzt wird — falsches role="navigation" macht eine Seite schlechter, nicht besser. Wir setzen ARIA chirurgisch, nicht flächig.
Untertitel & Transkripte
Video-Inhalte mit Sprache brauchen Untertitel — nicht nur automatisch generierte, sondern korrigierte. Audio-Inhalte (Podcasts, eingebettete Aufnahmen) brauchen ein vollständiges Transkript. Das ist nicht nur Pflicht, sondern auch SEO-relevant: Suchmaschinen indexieren das Transkript.
Reduced-Motion respektieren
Nutzer, die in den System-Einstellungen „Bewegung reduzieren“ aktivieren, leiden oft an Vestibulär-Störungen oder Migräne. Animationen, Parallax-Effekte und große Übergänge müssen über @media (prefers-reduced-motion: reduce) abschaltbar sein — ohne dass Funktionalität verloren geht.
Leistungen
Was wir konkret liefern
Barrierefreiheit ist kein Tool-Klick, sondern ein strukturierter Prozess: Bestandsaufnahme, technische Umsetzung, Schulung und laufende Pflege. Unser Leistungspaket deckt alle vier Phasen ab — vom ersten Audit bis zum Re-Auditing nach sechs Monaten.
WCAG 2.2 AA Audit
Vollständige Prüfung deiner Website gegen den aktuellen WCAG-2.2-AA-Standard — die Stufe, die das BFSG implizit verlangt. Wir kombinieren automatisierte Tools (Lighthouse, axe DevTools) mit manuellen Tests (Tastatur-Navigation, Screen-Reader, Kontrast-Messung). Ergebnis: ein priorisierter Befundbericht.
Remediation & Code-Refactor
Wir beheben die gefundenen Verstöße direkt im Code: HTML-Semantik, ARIA-Anpassungen, Form-Labels, Fokus-Stile, Komponenten-Refactor. Bei stark verbauten Themes oder Page-Buildern bedeutet das oft den Austausch ganzer Komponenten — das sagen wir vorher klar an, statt am Ende zu überraschen.
Schulung der Redaktion
Eine barrierefreie Website verfällt schnell wieder, wenn die Redaktion nicht weiß, wie man Alt-Texte schreibt, Heading-Strukturen einhält und PDFs sauber exportiert. Wir bieten 2-3 Stunden Schulung mit Beispielen aus deiner eigenen Site und einer Checkliste für künftige Inhalte.
Erklärung zur Barrierefreiheit
Pflicht-Page nach BFSG: Stand der Konformität, dokumentierte Ausnahmen, Datum der letzten Prüfung, Feedback-Mechanismus. Wir erstellen die Seite passend zu deinem Audit-Ergebnis und in der Tonalität deiner restlichen Site — keine Copy-Paste-Vorlage von der Behörde.
Feedback-Mechanismus
Nutzer müssen Barrieren melden können. Das Kontaktformular dafür darf nicht selbst eine Barriere sein — also kein Captcha, keine reinen Bilder als Pflichtfeld, klare Labels. Wir verknüpfen die Meldungen direkt mit eurem Postfach und liefern eine Vorlage für die Reaktionsprozesse.
Monitoring & Re-Audit
Eine Website ist nicht statisch. Neue Inhalte, neue Plugins, neue Designs können Barrierefreiheit brechen. Wir bieten halbjährliches Re-Auditing — kürzer als ein Vollaudit, aber genug, um Regressionen früh zu finden, bevor sie rechtlich kritisch werden.
Werkzeuge
Audit-Tools, die wir nutzen
Kein einzelnes Tool reicht aus, um WCAG-Konformität zu beweisen — jedes hat blinde Flecken. Wir kombinieren mehrere automatisierte Werkzeuge mit manueller Prüfung. Diese Kombination ist die einzige Methode, mit der man heute belastbar zur AA-Stufe testen kann.
Lighthouse Accessibility
Ein guter Startpunkt, aber kein Endpunkt. Lighthouse misst nur einen Teil der WCAG-Kriterien — Kontrast-Probleme bei Hintergrundbildern, fehlerhafte ARIA-Konstrukte und Tastatur-Fallen erkennt es nicht zuverlässig. Wir nutzen es als ersten Filter, nicht als Abschlussbeleg.
axe DevTools
Deutlich tiefer als Lighthouse. axe erkennt deutlich mehr Verstöße — falsche Heading-Reihenfolgen, kaputte Form-Verknüpfungen, ARIA-Missbrauch. Trotzdem deckt auch axe nur etwa 30-40 % aller WCAG-Probleme automatisch ab, der Rest braucht Menschen.
Screen-Reader-Test
Wir testen mit NVDA (Windows, kostenfrei) und VoiceOver (macOS/iOS). So erleben wir die Site so, wie ein blinder Nutzer sie erlebt — und finden Stolperstellen, die kein automatisches Tool sieht: unklare Linktexte („hier klicken“), fehlende Landmarks, falsch angekündigte Buttons.
Tab-only-Navigation
Maus weglegen, einmal komplett durch die Seite tabben. Lässt sich jedes Menü öffnen? Bleibt der Fokus immer sichtbar? Komme ich aus jedem Modal wieder raus? Wir machen das auf jeder Pillar-Page der Site, nicht nur auf der Startseite.
Color-Contrast-Analyzer
Pixel-genaue Messung von Kontrast-Verhältnissen, auch auf komplexen Hintergründen wie Verlaufsbildern oder Halbtransparenzen. Genauer als Browser-DevTools, weil wir reale Screenshots messen — nicht nur die deklarierten CSS-Werte.
Manuelle WCAG-Checkliste
Am Ende geht jede Seite Punkt für Punkt durch unsere strukturierte Checkliste — alle 50 relevanten WCAG-2.2-AA-Erfolgskriterien. Was die Tools nicht prüfen können, prüfen Menschen. Das ist der Aufwandstreiber, aber auch der Qualitätsunterschied zu einem reinen Tool-Audit.
Praxis
BFSG-Konformität in der Praxis: typische Befunde
Was wir bei einem typischen KMU-Audit fast immer finden — und wie viel Aufwand die Behebung tatsächlich bedeutet. Die untere Schranke liegt bei 1-2 Tagen für eine kleine, sauber gebaute Site mit wenigen Befunden. Die obere Schranke kann bei stark verbauten Page-Builder-Sites bei 2-4 Wochen liegen — manchmal mit der wirtschaftlich besseren Alternative eines kompletten Redesigns.
60-80 % Bilder ohne sinnvolles Alt-Attribut
Entweder fehlen Alt-Texte komplett oder sie enthalten generische Strings wie „Bild“, „Grafik“ oder den Dateinamen. Häufig auf Page-Builder-Seiten und älteren WordPress-Installationen.
Skip-Links fehlen vollständig
Die meisten KMU-Themes liefern keine Skip-Links. Tastatur-Nutzer müssen sich auf jeder Seite durch das komplette Menü tabben, bevor sie den Hauptinhalt erreichen.
Kontrast-Probleme bei #777 auf #fff
Klassisches Problem mit „eleganten“ Grautönen: optisch schick, formal durchgefallen. Body-Text in #777 oder heller hat keine Chance, das 4.5:1-Kriterium zu erreichen.
Form-Labels fehlen oder sind nur visuell
Felder mit Placeholder als einzigem Hinweis, ohne <label>. Sobald der Nutzer tippt, ist der Hinweis weg — und Screen-Reader können das Feld nicht zuordnen.
Heading-Sprünge durch Page-Builder
Page-Builder rendern Überschriften oft nach optischer Größe, nicht nach semantischer Hierarchie. Resultat: H1 → H4 → H2 in einer einzigen Sektion. Screen-Reader-Outline wird unbrauchbar.
DOM-Bloat & verschachtelte div-Wüsten
Visual-Builder produzieren teilweise 5-10 verschachtelte Wrapper pro Element. Das macht ARIA-Anpassungen aufwendig und kostet Performance — Barrierefreiheit und Speed hängen technisch eng zusammen.
Aufwand realistisch einschätzen
Der Faktor, der Remediation-Kosten am stärksten beeinflusst, ist nicht die Größe der Site, sondern die Bauart. Eine 50-Seiten-Site auf einem sauber konfigurierten Standard-Theme ist oft in einer Woche komplett auf AA-Niveau. Eine 10-Seiten-Site, die mit einem Page-Builder zusammengeklickt wurde und tausende Inline-Styles enthält, kann den fünffachen Aufwand bedeuten — bis hin zu der ehrlichen Empfehlung, lieber neu zu bauen als zu reparieren.
Investition
Pricing-Indikation: drei Bänder
Konkrete Festpreise berechnen wir erst nach einem ersten Schnell-Audit, weil der Aufwand stark von der technischen Bauart deiner Site abhängt. Diese Bänder geben dir aber eine realistische Größenordnung, mit der du intern planen und budgetieren kannst.
Audit + Mini-Remediation
ab niedrigem 4-stelligen Bereich
Enthaltene Leistungen
- WCAG 2.2 AA Audit
- Top-Befunde priorisiert
- Code-Patches für die 10-20 wichtigsten Verstöße
- Erklärung zur Barrierefreiheit
Passt zu
Kleinere KMU-Sites, bei denen die Mehrheit der Befunde mit gezielten Code-Anpassungen behoben werden kann.
Audit + Voll-Remediation
low- bis mid-5-stellig
Enthaltene Leistungen
- Vollständiges WCAG-2.2-AA-Audit
- Komponenten-Refactor & Theme-Anpassungen
- Form-System neu (barrierefrei)
- Schulung Redaktion (2-3 Stunden)
- Erklärung zur Barrierefreiheit
- Feedback-Mechanismus + Re-Audit nach 6 Monaten
Passt zu
Mittelgroße Websites mit mehreren Templates, Shop-Funktionalität oder umfangreicher Redaktionsstruktur.
Voll-Redesign accessibility-first
vergleichbar mit regulärem Redesign
Enthaltene Leistungen
- Komplett-Neubau auf sauberer technischer Basis
- WCAG 2.2 AA von Anfang an
- Performance & Barrierefreiheit kombiniert
- Erklärung zur Barrierefreiheit
- Feedback-Mechanismus + Schulung
Passt zu
Sites, bei denen das technische Fundament so verbaut ist, dass Remediation teurer wäre als ein Neuaufbau — oder wenn ohnehin ein Relaunch ansteht.
Accessibility-first ist nicht teurer
Eine spannende Beobachtung aus der Praxis: Ein Voll-Redesign mit Barrierefreiheit von Anfang an kostet nicht nennenswert mehr als ein reguläres Redesign. Der Grund ist einfach — Barrierefreiheit und sauberes Webdesign überschneiden sich zu rund 80 %. Wer semantisch korrektes HTML, gute Kontraste und solide Komponenten ohnehin baut, hat die WCAG-AA-Stufe weitgehend mitgenommen. Die eigentlichen Mehrkosten entstehen nicht beim Bauen, sondern beim Reparieren von Sites, die ohne diesen Anspruch entstanden sind.
Region
Barrierefreies Webdesign in Rhein-Neckar
Wir betreuen Audits und Remediation-Projekte bundesweit — die meisten laufen vollständig remote über Video-Calls und Cloud-Tools. Für Kunden in der Region Rhein-Neckar (Mannheim, Heidelberg, Karlsruhe, Speyer, Ludwigshafen, Hockenheim) bieten wir bei Bedarf auch Vor-Ort-Termine an — gerade bei der Schulung der Redaktion kann der direkte Austausch gut funktionieren. Pflicht ist Vor-Ort-Präsenz nicht.
FAQ
Häufige Fragen zu barrierefreiem Webdesign
- Bin ich vom BFSG überhaupt betroffen?
- Das BFSG (Barrierefreiheitsstärkungsgesetz) gilt seit dem 28. Juni 2025 für alle B2C-Websites und mobilen Anwendungen, die digitale Dienstleistungen für Verbraucher anbieten. Konkret betroffen: Online-Shops aller Größen, Buchungs- und Reservierungsplattformen, Bankdienstleistungen, Telekommunikations- und E-Book-Anbieter, Personenbeförderungsdienste. Ausgenommen sind Kleinstunternehmen mit weniger als 10 Mitarbeitenden und unter 2 Mio. € Jahresumsatz — wobei diese Ausnahme nur greift, wenn beide Schwellen unterschritten werden. Reine B2B-Sites ohne Verbraucher-Funktion sind formal nicht betroffen, sollten aus Compliance- und SEO-Gründen aber trotzdem zugänglich sein. Im Zweifel: Im Rahmen eines kostenfreien Erstgesprächs prüfen wir gerne, ob deine konkrete Konstellation unter das Gesetz fällt.
- Was kostet Barrierefreiheit nachträglich?
- Das hängt fast vollständig von der technischen Basis ab. Eine sauber gebaute, semantische Site lässt sich oft mit zwei bis vier Wochen Arbeit auf WCAG-2.2-AA-Niveau bringen — das landet im niedrigen bis mittleren 5-stelligen Bereich. Eine stark mit einem Page-Builder verbaute Site mit DOM-Bloat, hardcoded Inline-Styles und kaputter Heading-Hierarchie kann teurer werden als ein Voll-Redesign — weil der Aufwand für jede einzelne Anpassung um den Faktor 3-5 steigt. Deshalb erkennen wir das im Audit und sagen vor Beginn der Umsetzung klar an, ob Remediation oder Redesign der wirtschaftlich bessere Weg ist.
- Reicht ein guter Lighthouse-Score nicht aus?
- Nein. Ein Lighthouse-Accessibility-Score von 100/100 ist ein notwendiges, aber bei weitem nicht hinreichendes Zeichen. Lighthouse prüft automatisiert nur etwa 30 % der WCAG-Erfolgskriterien — alles, was strukturell, kontextabhängig oder verhaltensbezogen ist, kann es nicht erkennen. Falsch geschriebene Alt-Texte, irreführende Linktexte, kaputte Tastatur-Navigation in Custom-Komponenten, falsche ARIA-Attribute, fehlende Untertitel: all das wird von Lighthouse nicht erkannt. Eine echte Konformitätserklärung braucht zwingend manuelle Prüfung — Tools sind ein Filter, nicht der Beweis.
- Welche Quote an Menschen mit Behinderung rechtfertigt den Aufwand?
- In Deutschland leben rund 7,8 Millionen Menschen mit anerkannter Schwerbehinderung — das sind etwa 9,4 % der Bevölkerung. Dazu kommen weitere Millionen mit nicht-anerkannten Einschränkungen wie Lesestörungen, motorischen Schwierigkeiten oder altersbedingt eingeschränktem Sehvermögen. Ehrlicher betrachtet: Barrierefreiheit hilft nicht nur dieser Zielgruppe, sondern auch Smartphone-Nutzern bei greller Sonne, älteren Nutzern mit kleineren Bildschirmen und letztlich Suchmaschinen, weil semantisches HTML ein direkter SEO-Faktor ist. Die Frage ist nicht, ob sich der Aufwand „rechtfertigen“ lässt — er ist seit Juni 2025 Pflicht und gleichzeitig ein Conversion-Hebel.
- Was passiert konkret, wenn ich das BFSG ignoriere?
- Drei Sanktionsstufen sind möglich. Erstens: Bußgelder bis 100.000 € pro Verstoß durch die Marktüberwachungsbehörden der Bundesländer. Zweitens: behördliche Anordnung zur Marktrücknahme, also Abschaltung der Website oder Sperrung der mobilen App, wenn die Mängel gravierend sind. Drittens: zivilrechtliche Klagen durch Verbände wie den Sozialverband VdK oder einzelne betroffene Nutzer, vergleichbar mit den DSGVO-Abmahnwellen. Realistisch wird der Vollzug in den ersten zwölf Monaten eher unauffällig sein, aber die rechtliche Risikoposition steigt mit jedem Audit-freien Monat. Für Online-Shops und größere Plattformen ist Compliance-Druck schon jetzt deutlich spürbar.
- Wie lange dauert ein WCAG-2.2-AA-Audit?
- Ein gründliches Audit für eine typische KMU-Website mit 5-10 Templates und 30-50 Inhaltsseiten dauert etwa 3-5 Werktage. Davon entfällt rund ein Drittel auf automatisierte Prüfungen mit Lighthouse und axe, ein Drittel auf manuelle Tests (Tastatur, Screen-Reader, Kontrast), und ein Drittel auf Dokumentation und Priorisierung der Befunde. Bei größeren Sites mit Shop-Funktion, mehreren Sprachen oder umfangreichen Formularen kann das auf 1-2 Wochen anwachsen. Die Remediation selbst läuft danach in einem oder mehreren Sprints, je nach Tiefe des Refactorings.
- Macht ihr auch reine Compliance-Beratung?
- Ja, aber mit einer klaren Grenze. Wir sind keine Anwaltskanzlei und ersetzen keine juristische Beratung. Was wir machen: technische Konformitätsprüfung, Risikobewertung, priorisierte Roadmap, Vorlage für die Erklärung zur Barrierefreiheit. Was wir nicht machen: rechtsverbindliche Beurteilung von Ausnahmetatbeständen oder Verteidigung in Bußgeldverfahren. Für die juristische Seite arbeiten wir bei Bedarf mit Kanzleien zusammen, die auf Digital-Compliance spezialisiert sind — insbesondere im Schnittfeld BFSG, BGG und EAA.
- Ist mein WordPress-Theme automatisch barrierefrei?
- Nein, in den allermeisten Fällen nicht — selbst wenn das Theme mit „accessibility-ready“ beworben wird. Das offizielle WordPress-Tag bedeutet nur, dass das Theme bestimmte Mindeststandards erfüllt — nicht, dass die fertige Site WCAG 2.2 AA entspricht. Sobald du einen Page-Builder wie Elementor, Divi oder WPBakery hinzufügst, fallen die meisten Themes auf ein deutlich niedrigeres Niveau. Inhalte, Plugins und Custom-Anpassungen sind ohnehin außerhalb dessen, was das Theme garantieren kann. Realistisch: ein gutes Theme ist ein guter Startpunkt, aber kein Endpunkt. Die Konformität entscheidet die fertige Site, nicht das Template.
- Was ist mit AI-generierten Bildbeschreibungen?
- Tools wie GPT-4 Vision oder Claude können Bilder beschreiben, und das wird in den nächsten Jahren zunehmend in Workflows integriert. Trotzdem: AI-Beschreibungen sind aktuell ein guter Erstwurf, kein Ersatz für menschliche Redaktion. Sie kennen den Kontext nicht — ein Foto vom Kundenmeeting wird beschrieben als „mehrere Personen in einem Raum“, was technisch korrekt, aber als Alt-Text wertlos ist. Für die Skalierung von Bildbeschreibungen in Shops mit tausenden Produkten kann AI ein sinnvoller Helfer sein, aber das Endergebnis muss redaktionell überprüft werden — und das gilt nach BFSG auch rechtlich, denn die Verantwortung bleibt beim Betreiber, nicht beim Tool.
- Können wir das schrittweise einführen?
- Ja, das ist sogar der Regelfall. Eine Voll-Konformität an Tag eins ist bei Bestandssites unrealistisch und auch nicht zwingend gefordert — das BFSG erlaubt eine dokumentierte Roadmap, sofern sie ernsthaft umgesetzt wird. Wir empfehlen: erst die kritischen Befunde (Tastatur-Fallen, fehlende Form-Labels, Kontrast-Probleme im Hauptcontent) innerhalb von vier bis sechs Wochen, dann die mittleren Befunde (Skip-Links, Heading-Hierarchie, Alt-Texte) im nächsten Quartal, danach laufende Pflege. Wichtig ist, dass die Erklärung zur Barrierefreiheit den aktuellen Stand transparent dokumentiert — eine Site, die offen mit ihren Lücken umgeht, ist rechtlich besser positioniert als eine, die Konformität behauptet, ohne sie zu liefern.
Weiterlesen
Verwandte Themen
Webdesign Fahrschule
Webdesign für Fahrschulen — moderne Online-Präsenz für mehr Anmeldungen
Webdesign für Fahrschulen: Anmeldeformulare, Kursplan, Theorie-Online-Module, mobile Buchung. Was Fahrschüler heute online erwarten.
Mehr erfahrenWebentwicklung
Webentwicklung Agentur — von der Idee bis zum produktiven Code
Webentwicklung umfasst mehr als Design: Backend, APIs, Performance, Sicherheit. Was eine Webentwicklungsagentur konkret leistet und wann sie nötig ist.
Mehr erfahrenWebdesign Arzt
Webdesign für Arztpraxen — Patienten gewinnen, Vertrauen aufbauen
Webdesign für Ärzte, Zahnärzte und Praxen: Online-Termine, HWG-konform, Barrierefreiheit, Vertrauen durch Transparenz.
Mehr erfahrenWebagentur
Webagentur — Leistungen, Auswahlkriterien & Zusammenarbeit
Was eine Webagentur leistet, wie du die richtige findest und worauf du im Erstgespräch achten solltest. Bundesweit aus dem Rhein-Neckar-Raum.
Mehr erfahrenKostenloses Erstgespräch
Bereit loszulegen?
Wir melden uns innerhalb von 24 Stunden (Mo–Fr) mit einem unverbindlichen Angebot.