Barrierefreiheit per KI: Der Vibe-Coding Skill

Ich sage es ganz offen: Die deutsche Bürokratie und die EU-Regulierung können sich manchmal anfühlen wie ein Labyrinth aus Paragrafen, Abkürzungen und Fristen. Aber genau dort entsteht gerade eine spannende Chance.

Denn mit KI-gestütztem Vibe-Coding kannst Du heute Dinge von Anfang an mitdenken, die früher oft erst kurz vor dem Go-live schmerzhaft aufflogen – vor allem digitale Barrierefreiheit.

Und ganz ehrlich: Wenn wir mit moderner Entwicklung dafür sorgen können, dass mehr Menschen Webseiten, Shops und Apps ohne Hürden nutzen können, dann ist das nicht nur klug, sondern auch einfach richtig.

Ich gebe Dir hier die Quintessenz zur direkten Umsetzung als Skill, für Antigravity oder Claude.

Das ganze basiert auf einem Deep Research mit Gemini.

Hier ist der Skill zum Kopieren:

<core_identity>
You are an Elite Frontend Systems Architect and an uncompromising Expert in Digital Accessibility (A11y). Your absolute, non-negotiable mandate is to ensure that all code, architecture plans, and UI components generated strictly comply with the German Barrierefreiheitsstärkungsgesetz (BFSG) and the Barrierefreie-Informationstechnik-Verordnung (BITV 2.0).
These laws mandate strict technical compliance with the European norm EN 301 549, which technically maps directly to the W3C Web Content Accessibility Guidelines (WCAG) version 2.2 at Level AA.
Never compromise on accessibility for aesthetic reasons, speed, or code brevity. Treat every violation of WCAG 2.2 AA as a critical, blocking compilation error. Assume this codebase belongs to an e-commerce or fundamental B2C service falling under mandatory, sanction-enforced BFSG guidelines effective June 28, 2025.
</core_identity>

<technical_stack_constraints>

CSS Utility Frameworks: When utilizing CSS frameworks like Tailwind, you must explicitly code highly visible, contrast-compliant focus states (e.g., focus-visible:ring-2 focus-visible:ring-offset-2 focus-visible:ring-blue-600) to strictly comply with WCAG 2.4.7 and 2.4.11.
Forbidden CSS: NEVER generate outline: none; or outline: 0; unless it is immediately accompanied by a robust, high-contrast custom focus indicator that meets a minimum 3:1 contrast ratio against the adjacent background.
</technical_stack_constraints>

<wcag_2_2_mandatory_rules>
Every time you plan or generate UI components, you must internally verify your output against these critical WCAG 2.2 AA criteria:

Target Size (Minimum) (2.5.8): All interactive elements (buttons, links, form controls, hamburger menus) MUST have a minimum bounding box of 24x24 CSS pixels, inclusive of padding.
Focus Not Obscured (2.4.11): Ensure floating or fixed elements (sticky headers, cookie consent banners, persistent footers) do not completely hide an element when it receives keyboard focus. Implement scroll-padding-top or scroll-margin in global layouts.
Color Contrast (1.4.3): Maintain at least a 4.5:1 contrast ratio for normal text and 3:1 for large text (18pt or 14pt bold) and essential UI components. Color must never be the ONLY visual means of conveying information (1.4.1 Use of Color).
Redundant Entry (3.3.7): Never generate multi-step forms (like checkout flows) that ask for the previously entered information twice without providing an auto-fill mechanism, a dropdown selection, or a copy checkbox.
Accessible Authentication (3.3.8): Never block the system clipboard (copy-pasting) in password fields. Never rely solely on cognitive tests (CAPTCHAs, math puzzles) for login. You must provide autocomplete support (e.g., <input type="password" autocomplete="current-password" />) to ensure password managers function correctly.
Dragging Movements (2.5.7): Any functionality requiring a dragging motion (sliders, drag-and-drop lists) must also be operable via simple, single-pointer clicks/taps.
</wcag_2_2_mandatory_rules>

<semantic_html_and_aria>
"No ARIA is better than bad ARIA." Always prefer native HTML5 elements (<button>, <nav>, <dialog>, <form>). When native elements are insufficient and you must build custom widgets, you are strictly bound to the implementations defined in the W3C ARIA Authoring Practices Guide (APG).

Forbidden Anti-Patterns:

❌ <div onClick={...}> or <span onClick={...}> - NEVER DO THIS. Always use <button type="button"> for actions.
❌ Using role="button" without implementing onKeyDown handlers for BOTH the Enter and Space keys to trigger the action.
❌ Creating modal dialogs that do not trap keyboard focus within the modal while it is open.

Required Architectural Patterns:

Tabs Interface: Must consist of a container with role="tablist", interactive elements with role="tab", and content containers with role="tabpanel". Tabs MUST be linked via aria-controls and aria-labelledby. Crucially, implement a roving tabindex: the active tab has tabindex="0", all inactive tabs must have tabindex="-1". Keyboard routing between tabs must occur via Left/Right Arrow keys, NOT the Tab key.
Accordion: The clickable header must be a <button> semantically wrapped inside a heading tag (e.g., <h3>). The button requires aria-expanded={isOpen} and aria-controls="panel-id". Navigation occurs via the Tab key, activation via Enter/Space.
Forms: Every <input>, <select>, or <textarea> must have a programmatically associated <label> (using the for or htmlFor attribute linking to the input's id). Placeholder attributes are NEVER an acceptable substitute for a label.
</semantic_html_and_aria>

<german_law_specifics>

Document Language: Always ensure the document structure has the correct primary language attribute declared: <html lang="de">.
Language Shifts: If embedding English terms, quotes, or segments written in "Leichte Sprache" (Easy Language, highly relevant for BITV 2.0) within a German page, you must wrap that specific content in a container with a distinct language tag (e.g., <span lang="en"> or <div lang="de-x-simple">) to instruct screen reader synthesizers to switch their phonetic engine.
Documentation Architecture: BFSG mandates the existence of a "Barrierefreiheitserklärung" (Accessibility Statement) and a distinct "Feedback-Mechanismus" (Feedback Form). When scaffolding projects, remind the developer to include routes and compliant semantic structures for these legally required pages.
</german_law_specifics>

<workflow_execution>
When I instruct you to build, refactor, or analyze a feature, follow this loop:

Analyze: Briefly assess how the request intersects with WCAG 2.2 and BFSG requirements.
Plan (Shift+Tab): Output a concise architectural plan outlining the semantic HTML structure, the ARIA attributes, and the keyboard focus management logic you intend to use. Wait for my confirmation.
Execute: Write clean, modular, accessible code strictly adhering to the plan.
Self-Audit: Add a brief comment block at the end of your response stating: "A11y Audit: Verified Keyboard Operability (Enter/Space), Screen Reader Semantics (Labels/Roles), and Target Size compliance."
</workflow_execution>

Der komplette Deep Research aus Gemini

Deep Research Report: Digitale Barrierefreiheit nach deutscher Gesetzgebung und Implementierung als Claude-Skill für Vibecoding

1. Einleitung und Management Summary

Die digitale Landschaft in Deutschland sowie innerhalb der gesamten Europäischen Union durchläuft gegenwärtig eine fundamentale rechtliche und technologische Transformation hin zu einer inklusiveren Informationsgesellschaft. Mit dem nahenden Stichtag des 28. Juni 2025, an dem das Barrierefreiheitsstärkungsgesetz (BFSG) vollumfänglich in Kraft tritt, wird die digitale Barrierefreiheit aus ihrer bisherigen Nischenrolle im rein öffentlichen Sektor herausgehoben und zu einer zwingenden, sanktionsbewehrten rechtlichen Anforderung für weite Teile der Privatwirtschaft. Diese legislative Zäsur zwingt Unternehmen, Softwareentwickler, UI/UX-Designer und Systemarchitekten dazu, Webtechnologien von Grund auf neu zu evaluieren und barrierefreie Prinzipien nahtlos in den gesamten Software Development Life Cycle (SDLC) zu integrieren. Die Missachtung dieser Vorgaben birgt nicht nur das Risiko des Ausschlusses vulnerabler Nutzergruppen, sondern zieht erhebliche juristische und ökonomische Konsequenzen nach sich, die bis zur behördlich angeordneten Abschaltung digitaler Vertriebskanäle reichen können.

Parallel zu dieser regulatorischen Verdichtung revolutioniert die rasante Entwicklung der Künstlichen Intelligenz die Art und Weise, wie Software konzipiert und geschrieben wird. Das Paradigma des sogenannten "Vibecodings" – die stark KI-gestützte, interaktive und oft natürlichsprachlich gesteuerte Entwicklung von Code mithilfe autonomer oder semi-autonomer Agenten wie Claude Code von Anthropic – beschleunigt Entwicklungsprozesse exponentiell und verändert die Rolle des Entwicklers vom Syntax-Schreiber zum Architektur-Direktor. Die Schnittmenge dieser beiden tektonischen Verschiebungen – strenge gesetzliche Regulierung einerseits und KI-generierter Code andererseits – birgt jedoch ein signifikantes systemisches Risiko: Wenn KI-Codegeneratoren nicht mit dem hochspezifischen rechtlichen und technischen Kontext der deutschen Barrierefreiheitsgesetzgebung (insbesondere BFSG, BITV 2.0 und BGG) sowie den allerneuesten internationalen Richtlinien (WCAG 2.2) instruiert werden, skalieren sie technische Schulden und rechtliche Risiken in nie dagewesener Geschwindigkeit. KI-Modelle tendieren nativ dazu, syntaktisch korrekten, visuell ansprechenden, aber semantisch katastrophalen Code zu generieren, der für assistive Technologien wie Screenreader vollkommen unzugänglich ist.

Dieser Forschungsbericht analysiert die komplexe Rechtslage in Deutschland in extremer Detailtiefe, dekonstruiert die technischen Anforderungen auf Basis der Web Content Accessibility Guidelines (WCAG) in ihrer neuesten Iteration 2.2 sowie der WAI-ARIA-Pattern des W3C und überführt diese holistischen Erkenntnisse in einen systematischen, hochspezialisierten "Skill" (System Prompt / Context Framework) für den KI-Agenten Claude. Das ultimative Ziel dieser Ausarbeitung ist die Schaffung eines resilienten Entwicklungs-Setups, in dem Claude beim Vibecoding proaktiv, kontextbewusst und rechtlich unangreifbar barrierefreien Code generiert, der den Anforderungen der deutschen Marktüberwachungsbehörden standhält.

2. Die gesetzliche Architektur der digitalen Barrierefreiheit in Deutschland

Die juristische Grundlage für digitale Barrierefreiheit in der Bundesrepublik Deutschland ist in ein duales System gegliedert, das historisch gewachsen ist und strikt zwischen öffentlichen Stellen und privatwirtschaftlichen Akteuren unterscheidet. Diese Trennung ist für die Softwareentwicklung von höchster Relevanz, da die jeweiligen Gesetze unterschiedliche technische Tiefen und formelle Pflichten verlangen.

2.1 Das Barrierefreiheitsstärkungsgesetz (BFSG) für die Privatwirtschaft

Das am 16. Juni 2021 vom Deutschen Bundestag verabschiedete Barrierefreiheitsstärkungsgesetz (BFSG) stellt den bisher weitreichendsten Eingriff in die digitale Gestaltungsfreiheit der Privatwirtschaft dar. Es dient der nationalen Umsetzung der Richtlinie (EU) 2019/882, international bekannt als der "European Accessibility Act" (EAA). Das Gesetz entfaltet seine volle rechtliche Bindungswirkung nach dem Ablauf der Übergangsfristen am 28. Juni 2025. Ab diesem Stichtag müssen Wirtschaftsakteure – definiert als Hersteller, Bevollmächtigte, Einführer, Händler oder Dienstleistungserbringer – garantieren, dass ihre betroffenen Produkte und Dienstleistungen für Endverbraucher barrierefrei gestaltet sind.

Der Anwendungsbereich des BFSG fokussiert sich präzise auf den elektronischen Geschäftsverkehr sowie auf grundlegende digitale Dienstleistungen, die für die Teilhabe am modernen gesellschaftlichen und wirtschaftlichen Leben unabdingbar sind. Eine detaillierte Analyse der betroffenen Sektoren zeigt die weitreichenden Implikationen für die Softwareindustrie :
Die Verpflichtung erstreckt sich primär auf Online-Shops und B2C-Verkaufsplattformen, was den gesamten Sektor des E-Commerce in die Pflicht nimmt. Darüber hinaus fallen Dienstleistungen im überregionalen Personenverkehr, inklusive der dazugehörigen Buchungs-Apps, Websites und interaktiven Selbstbedienungsterminals (wie Ticket- oder Check-in-Automaten), unter das Gesetz. Auch Telekommunikationsdienste und Internetanbieter müssen ihre Portale, insbesondere für die Vertragsverwaltung von Endverbrauchern, anpassen. Bankdienstleistungen, im Speziellen das gesamte Spektrum des Online-Bankings, unterliegen ebenfalls den strengen Vorgaben. Im Bereich der digitalen Medien sind E-Books sowie die für den Zugriff benötigte Hard- und Software (E-Book-Reader, entsprechende Applikationen) explizit genannt. Ferner betrifft das Gesetz Terminbuchungsmasken, digitale Vertragsabschlüsse und Kundenportale für jedwede Dienstleistungen. Auf der Hardware-Ebene werden Smartphones, Tablets, Notebooks für die private Nutzung und Fernsehgeräte mit Internetzugang (Smart-TVs) sowie deren Betriebssysteme reguliert.

Die zentrale rechtliche Definition von Barrierefreiheit im Rahmen des BFSG lehnt sich stark an die Formulierungen des Behindertengleichstellungsgesetzes an. Gemäß § 3 Absatz 1 BFSG gelten Produkte und Dienstleistungen nur dann als barrierefrei, wenn sie für Menschen mit Behinderungen "in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar sind". Diese Definition verbietet de facto die Auslagerung von Funktionalitäten auf separate, stigmatisierende Sonderlösungen und fordert ein inklusives Universal Design.

Eine kritische und oft missverstandene Nuance des Gesetzes ist die Ausnahme für sogenannte Kleinstunternehmen. Ein Unternehmen ist von den Vorgaben für erbrachte Dienstleistungen ausgenommen, wenn es exakt zwei kumulative Kriterien erfüllt: Es muss weniger als 10 Personen beschäftigen und darf höchstens einen Jahresumsatz oder eine Jahresbilanzsumme von zwei Millionen Euro aufweisen. Es ist für die rechtliche Bewertung jedoch von absolut fundamentaler Bedeutung zu beachten, dass sich diese Ausnahme ausschließlich auf Dienstleistungen (wie den reinen Betrieb eines kleinen Online-Shops für physische Güter) bezieht, nicht jedoch auf Produkte. Vertreibt ein Kleinstunternehmen beispielsweise E-Books (welche juristisch als Produkt im Sinne des Gesetzes klassifiziert werden), müssen diese E-Books zwingend barrierefrei sein, unabhängig von der Größe des vertreibenden Unternehmens. Diese Differenzierung führt dazu, dass Software-Agenten bei der Code-Generierung für E-Commerce-Plattformen stets den höchsten Standard anlegen müssen, da die Produkthaftung nicht durch die Unternehmensgröße des Händlers negiert wird.

Darüber hinaus existieren weitere spezifische Befreiungen. Rein geschäftliche (B2B) Angebote sowie ausschließlich private Websites unterliegen nicht dem Gesetz. Eine weitere, jedoch in der Praxis schwer rechtssicher anwendbare Ausnahme greift, wenn die Anpassung eine "unzumutbare wirtschaftliche Belastung" für das Unternehmen darstellen würde oder eine "grundlegende Veränderung der Wesensmerkmale" der Dienstleistung erfordern würde. Die Inanspruchnahme dieser Ausnahmeregelung unterliegt jedoch strengsten Nachweispflichten gegenüber den Behörden.

2.2 Behindertengleichstellungsgesetz (BGG) und die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0)

Während sich die Privatwirtschaft auf die Frist im Juni 2025 vorbereitet, gelten für öffentliche Stellen des Bundes und der Länder bereits seit geraumer Zeit wesentlich weitreichendere und formalistischere Vorgaben. Diese werden durch das Behindertengleichstellungsgesetz (BGG) und die darauf basierende Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) diktiert.

Die BITV 2.0 dient der nationalen Umsetzung der Richtlinie (EU) 2016/2102 (EU-Webseitenrichtlinie) und definiert den Anwendungsbereich extrem breit. Sie gilt ausnahmslos für alle Webinhalte (Websites, Webanwendungen), mobile Anwendungen, elektronisch unterstützte Verwaltungsabläufe (einschließlich der Verfahren zur elektronischen Vorgangsbearbeitung und elektronischen Aktenführung) sowie grafische Programmoberflächen, die von Behörden der Bundesverwaltung betrieben werden. Bemerkenswert ist, dass auch Stellen, die nicht originär zur Bundesverwaltung gehören, aber das Vergaberecht anzuwenden haben und dem Bund zuzurechnen sind, vollständig unter die BITV 2.0 fallen.

Ein signifikanter und für die Softwareentwicklung relevanter Unterschied der BITV 2.0 im Vergleich zum BFSG liegt in den Verpflichtungen, die weit über die rein technischen WCAG-Anforderungen hinausgehen. Die Verordnung fordert zwingend die Bereitstellung von Informationen in spezifischen, nicht-technischen Formaten, was direkte Auswirkungen auf die Informationsarchitektur und das Routing einer Webanwendung hat. So muss die Startseite eines Webauftritts zwingend Informationen zu den wesentlichen Inhalten der Seite, Hinweise zur Navigation und eine detaillierte Erklärung zur Barrierefreiheit in sogenannter "Leichter Sprache" vorhalten. Diese Inhalte müssen von der Startseite aus prominent verlinkt sein, wobei oft das etablierte europäische Logo von "Inclusion Europe" zur schnellen visuellen Erkennbarkeit genutzt wird. Äquivalent dazu fordert die BITV 2.0 die Bereitstellung von adäquaten Informationen in Form von Videos in Deutscher Gebärdensprache (DGS), die ebenfalls von der Startseite aus direkt zugänglich sein müssen.

Ausnahmen unter der BITV 2.0 sind extrem eng gefasst und betreffen primär historische oder hochspezifische Inhalte. Ausgenommen sind beispielsweise digitale Archive, die nach dem 23. September 2019 weder aktualisiert noch überarbeitet wurden und deren Inhalte für aktive Verwaltungsverfahren nicht mehr benötigt werden. Ebenso ausgenommen sind bestimmte Reproduktionen von Stücken aus Kulturerbesammlungen sowie Websites und mobile Anwendungen von Rundfunkanstalten des Bundesrechts, wie etwa der Deutschen Welle.

2.3 Sanktionsmechanismen und Rechtsdurchsetzung

Die Relevanz der präzisen Instruktion von KI-Agenten beim Vibecoding wird durch die drakonischen Sanktionsmechanismen unterstrichen, die bei Non-Konformität drohen. Das BFSG etabliert ein striktes, proaktives Melde- und Monitoring-System, das von den Marktüberwachungsbehörden der einzelnen Bundesländer gesteuert und exekutiert wird. Die Rechtsdurchsetzung erfolgt in Deutschland auf mehreren, voneinander unabhängigen Gleisen, was das kumulierte Risiko für nicht konforme Wirtschaftsakteure potenziert.

Das erste Gleis ist das direkte behördliche Einschreiten. Marktüberwachungsbehörden können Mängelbeseitigungen fordern, Fristen setzen und empfindliche Bußgelder verhängen, die schnell in die Tausende Euro gehen können. Als Ultima Ratio, sollte sich ein Betreiber weigern oder unfähig sein, die Konformität herzustellen, sind die Behörden gesetzlich legitimiert, die vollständige Abschaltung einer Website oder eines Online-Shops anzuordnen (formell als "Einstellung des elektronischen Geschäftsverkehrs" bezeichnet). Diese Maßnahme stellt einen massiven Eingriff in den eingerichteten und ausgeübten Gewerbebetrieb dar.

Das zweite Gleis ist das zivilrechtliche Verbandsklagerecht. Verbraucher, die auf digitale Barrieren stoßen, können sich durch nach dem Behindertengleichstellungsgesetz anerkannte Verbände vertreten lassen. Dies kann entweder direkt durch eine Prozessvertretung geschehen oder über eine sogenannte gewillkürte Prozessstandschaft, bei der der Verband nicht nur im Namen, sondern an Stelle des Verbrauchers vor Gericht handelt. Das Gesetz sieht zudem ein eigenes, starkes Verbandsklagerecht für Verbände und qualifizierte Einrichtungen vor, wodurch die Schwelle für juristische Auseinandersetzungen erheblich gesenkt wird.

Das dritte und ökonomisch weitaus gefährlichste Gleis resultiert aus dem Wettbewerbsrecht. Da die Vorgaben des BFSG explizit darauf abzielen, den Wettbewerb im Binnenmarkt durch klare und einheitliche Standards zu stärken, können zahlreiche Regeln des BFSG als Marktverhaltensregeln nach § 3a des Gesetzes gegen den unlauteren Wettbewerb (UWG) klassifiziert werden. Ein Verstoß gegen die Barrierefreiheitsanforderungen ist in diesem Kontext nicht nur ein administratives Versäumnis, sondern ein wettbewerbswidriges Verhalten. Dies öffnet Tür und Tor für kostenpflichtige Abmahnungen durch direkte Mitbewerber. In der hochkompetitiven Landschaft des E-Commerce stellt diese permanente Bedrohung durch wettbewerbsrechtliche Abmahnungen den stärksten Anreiz dar, Barrierefreiheit nicht als nachgelagertes Testing-Problem zu betrachten, sondern als fundamentalen, unverhandelbaren Bestandteil der initialen Software-Architektur.

3. Ökonomische Dimensionen und methodische Prüfverfahren

Die Implementierung digitaler Barrierefreiheit ist untrennbar mit ökonomischen Kalkulationen verbunden. Die Kosten für die Erstellung oder den Umbau (Redesign) einer Website zur Erfüllung der BFSG- oder BITV-Vorgaben hängen stark von der Komplexität, dem Umfang und dem gewählten technologischen Ansatz ab.

3.1 Kostenstrukturen der digitalen Barrierefreiheit

Empirische Daten und Analysen, unter anderem bereitgestellt durch die Aktion Mensch, verdeutlichen die finanzielle Bandbreite solcher Projekte. Eine initial durchgeführte, grobe Analyse einer bestehenden Website nimmt in der Regel etwa einen Personentag in Anspruch. Die Kosten für diesen ersten Schritt, der lediglich einen Überblick über den Status Quo liefert und noch keine spezifischen Lösungsansätze beinhaltet, bewegen sich schätzungsweise zwischen 600 Euro und 1.200 Euro. Für einen vollständigen, systematischen Test, bei dem zertifizierte Spezialisten jeden einzelnen Seitentyp einer Webpräsenz evaluieren und einen detaillierten Maßnahmenbericht erstellen, steigen die Budgetanforderungen signifikant. Bei einer verhältnismäßig einfachen Website belaufen sich die Kosten für diese tiefe Analyse auf etwa 2.500 Euro bis 5.000 Euro. Handelt es sich jedoch um komplexe Projekte mit hochgradig dynamischen Inhalten, verschachtelten Formularen oder umfangreichen Checkout-Prozessen – wie es bei großen Online-Shops die Regel ist – muss ein Analysebudget von 5.000 Euro bis 10.000 Euro veranschlagt werden.

Diese Kostendaten untermauern eine zentrale ökonomische These der Softwareentwicklung: Die nachträgliche Reparatur von nicht barrierefreiem Code (Retrofitting) ist um ein Vielfaches teurer und fehleranfälliger, als die Barrierefreiheit von Beginn an in den Design- und Entwicklungsprozess (Shift-Left-Ansatz) zu integrieren. Die Konzeption und Implementierung von Funktionen wie Kontaktformularen oder Warenkörben in einer barrierefreien Weise ist fundamental nicht komplexer oder zeitaufwendiger, als sie mit Barrieren zu entwickeln, sofern das notwendige Wissen – beziehungsweise der korrekt konfigurierte KI-Agent – von der ersten Zeile Code an vorhanden ist. Bei mangelnder interner Expertise sollten Unternehmen auf Dienstleister zurückgreifen, die Zertifizierungen der International Association of Accessibility Professionals (IAAP) aufweisen, wie den CPACC (Certified Professional in Accessibility Core Competencies) oder den WAS (Web Accessibility Specialist).

3.2 Systematische Prüfverfahren und Tooling

Die Verifikation der Barrierefreiheit ist ein kontinuierlicher Prozess, der automatisierte Werkzeuge mit zwingend erforderlichen manuellen Tests kombiniert. Eine einfache Checkliste kann niemals eine vollständige Qualitätskontrolle ersetzen und ist nicht gleichwertig mit einem systematischen Test nach dem Standard des W3C.

Für die technische Evaluierung während des Entwicklungsprozesses haben sich verschiedene Tools etabliert. WAVE (Web Accessibility Evaluation Tools) bietet Browsererweiterungen, die visuell Fehler in der Überschriftenstruktur, fehlende Alternativtexte oder ARIA-Fehlkonfigurationen direkt im Document Object Model (DOM) anzeigen. Google Lighthouse ermöglicht automatisierte Tests der "Accessibility Essentials" und lässt sich hervorragend in Continuous Integration / Continuous Deployment (CI/CD) Pipelines integrieren. Spezifische Browsererweiterungen wie HeadingsMap erlauben die schnelle Validierung der Dokumenten-Outline, während dedizierte Contrast-Checker sicherstellen, dass die strengen Farbvorgaben eingehalten werden.

Automatisierte Tests können jedoch systembedingt nur einen Bruchteil (etwa 25 bis 30 Prozent) der tatsächlichen WCAG-Kriterien zuverlässig verifizieren. Eine maschinelle Prüfung kann feststellen, ob ein Bild ein alt-Attribut besitzt, sie kann jedoch nicht beurteilen, ob der darin enthaltene Text den visuellen Inhalt für einen blinden Nutzer sinnvoll und kontextgerecht beschreibt. Daher ist der manuelle Screenreader-Check unerlässlich. Websites müssen auf ihre Kompatibilität mit Vorleseanwendungen geprüft werden, wobei die Standardsysteme Google TalkBack (für Android), Apple VoiceOver (für iOS und macOS) sowie NVDA und JAWS (für Windows) das Test-Ökosystem dominieren.

Für das Vibecoding bedeutet dies, dass der Entwickler den KI-Agenten nicht nur Code generieren lassen darf, sondern ihn auch explizit anweisen muss, automatisierte Prüfskripte (wie axe-core) zu schreiben und in die Test-Suite zu integrieren, um eine kontinuierliche Überwachung der Code-Qualität sicherzustellen.

4. Technische Spezifikationen und die Evolution zu WCAG 2.2

Die gesetzlichen Vorgaben in Deutschland verweisen technisch nicht direkt auf die Richtlinien des W3C, sondern referenzieren als normatives Bindeglied die europäische Norm EN 301 549. Diese Norm beschreibt die funktionalen Anforderungen an die Barrierefreiheit von IKT-Produkten und -Dienstleistungen und referenziert für Web-Inhalte direkt die Web Content Accessibility Guidelines (WCAG).

4.1 Die Hierarchie der Konformitätsstufen

Die WCAG gliedern sich in Prinzipien (Wahrnehmbar, Bedienbar, Verständlich, Robust), Richtlinien und testbare Erfolgskriterien, welche wiederum drei Konformitätsstufen zugeordnet sind:
Die Stufe A definiert die absoluten Mindestanforderungen. Ohne die Erfüllung dieser Kriterien (beispielsweise die grundsätzliche Bedienbarkeit aller interaktiven Elemente mittels Tastatur) ist eine Website für Menschen mit bestimmten Behinderungen physisch unnutzbar. Die Stufe AA stellt den Kompromiss zwischen weitreichender Inklusion und technischer Machbarkeit dar und ist in fast allen globalen und europäischen Gesetzgebungen – inklusive BFSG und BITV 2.0 – der gesetzlich geforderte Standard. Die Stufe AAA umfasst die höchsten Anforderungen, die oftmals in tiefgreifende Designentscheidungen eingreifen und gesetzlich flächendeckend nicht gefordert werden, jedoch für spezifische, spezialisierte Informationsangebote essenziell sind.

4.2 Der Paradigmenwechsel von WCAG 2.1 zu WCAG 2.2

Aktuell fordert die rechtliche Basis in der Europäischen Union mindestens die Konformität mit der WCAG Version 2.1 auf dem Level AA. Im Oktober 2023 veröffentlichte das W3C nach jahrelanger Entwicklung die WCAG 2.2. Obwohl die europäische Norm EN 301 549 derzeit in einem Überarbeitungsprozess steckt, um formell auf die Version 2.2 zu referenzieren, ist der Konsens unter Experten, Prüfstellen und Institutionen wie der Überwachungsstelle des Bundes (BFIT-Bund) eindeutig: Neue Entwicklungszyklen und Relaunches müssen zwingend direkt auf Basis der WCAG 2.2 durchgeführt werden. Eine Website, die heute die WCAG 2.2 umsetzt, gilt als technisch zukunftssicher und übererfüllt die derzeitigen rechtlichen Minimalanforderungen auf eine Weise, die zukünftige Retrofitting-Kosten eliminiert.

Die Evolution zur Version 2.2 bringt hochrelevante Anpassungen für Entwickler mit sich. Ein historisch bedeutsames Erfolgskriterium, 4.1.1 Parsing, wurde in der WCAG 2.2 als obsolet markiert und vollständig entfernt. Dieses Kriterium forderte ursprünglich absolut fehlerfreies HTML, da frühe Screenreader bei nicht geschlossenen Tags abstürzten. Da moderne Browser fehlerhaftes Markup heutzutage intern durch den DOM-Parser äußerst zuverlässig kompensieren und korrigieren, stellte dieses Kriterium in der Praxis oft eine formale Hürde ohne realen Gewinn für die Nutzer dar. Gleichzeitig wurde das essenzielle Kriterium 2.4.7 Focus Visible, welches vorschreibt, dass der aktuelle Tastaturfokus visuell deutlich erkennbar sein muss, von der Konformitätsstufe AA auf die Stufe A hochgestuft, was seine fundamentale Bedeutung als absolute Mindestanforderung für die Bedienbarkeit untermauert.

4.3 Analyse der neuen WCAG 2.2 Erfolgskriterien (Level A und AA)

Für die Instruktion autonomer Programmieragenten beim Vibecoding müssen die neuen Kriterien der WCAG 2.2 zwingend und präzise in das Kontext-Wissen des Modells überführt werden. Große Sprachmodelle (LLMs) wurden oft auf Datenbeständen trainiert, in denen die Version 2.1 den State of the Art repräsentierte, weshalb sie ohne explizites Prompting dazu tendieren, die neuen 2.2-Metriken zu ignorieren. Die WCAG 2.2 legt einen starken Fokus auf Nutzer mit kognitiven Einschränkungen, Lernbehinderungen sowie auf die mobile Bedienbarkeit via Touchscreen.

Die folgende detaillierte Spezifikation der relevantesten neuen Kriterien bildet das Rückgrat für die spätere Prompt-Generierung:

KriteriumStufeKernanforderung für die Architektur und UI-Entwicklung2.4.11 Focus Not Obscured (Minimum)AA

Wenn ein interaktives UI-Element durch Tastaturnavigation den Fokus erhält, muss zwingend mindestens ein Teil dieses Elements im Viewport sichtbar bleiben. Es darf nicht vollständig durch andere überlagernde Inhalte (wie "Sticky"-Header, feststehende Footer, Cookie-Consent-Banner oder persistente Chat-Widgets) verdeckt werden. Technisch erfordert dies ein vorausschauendes Layouting und häufig den Einsatz der CSS-Eigenschaft scroll-padding-top oder scroll-margin, um den Browser anzuweisen, beim Scrollen zu fokussierten Elementen einen definierten Abstand zum oberen Bildschirmrand einzuhalten.

2.5.7 Dragging MovementsAA

Jegliche Funktionalität, die eine kontinuierliche, pfadbasierte Ziehbewegung des Zeigegeräts erfordert (wie Drag-and-Drop-Listen, verschiebbare Slider-Griffe, interaktive Karten), muss zwingend auch durch eine einfache, punktuelle Zeiger-Aktion (einen einfachen Klick oder Tap) ausführbar sein. Ein Nutzer mit motorischen Einschränkungen (z.B. Tremor), der keine Maus-Taste gedrückt halten und gleichzeitig präzise ziehen kann, muss das Element beispielsweise durch einen Klick anwählen und durch einen weiteren Klick am Zielort ablegen können.

2.5.8 Target Size (Minimum)AA

Die Ausdehnung interaktiver Klickflächen (Pointer Inputs wie Buttons, Textlinks, Checkboxen) muss in der Regel mindestens 24x24 CSS-Pixel betragen. Diese Ausdehnung schließt das innere Padding der Box ein. Von dieser Regel darf nur abgewichen werden, wenn eine Ausnahmesituation vorliegt, beispielsweise wenn um ein kleineres Element herum ausreichend nicht-interaktiver Leerraum (Spacing) existiert, sodass der Abstand zum Mittelpunkt des nächsten interaktiven Elements wiederum mindestens 24 Pixel beträgt. Dieses Kriterium ist massiv relevant für die mobile Nutzbarkeit (Touch-Targets).

3.2.6 Consistent HelpA

Wenn eine Website oder Webapplikation Hilfsmechanismen anbietet – seien es Kontaktformulare, menschliche Kontaktinformationen (Telefonnummern, E-Mail-Adressen), vollständig automatisierte Chat-Bots oder Verlinkungen zu FAQ-Seiten – und diese Hilfen auf mehreren Seiten zur Verfügung stehen, so müssen sie sich konsistent an der gleichen relativen Position im Layout befinden. Dies reduziert die kognitive Last für Nutzer, die sich nicht auf jeder Unterseite neu orientieren müssen, um Hilfe zu finden.

3.3.7 Redundant EntryA

Nutzer dürfen niemals gezwungen werden, Dateninformationen, die sie in einem zusammenhängenden Prozess bereits eingegeben haben, erneut einzutippen. Ein klassisches Beispiel ist der E-Commerce-Checkout: Wenn Rechnungs- und Lieferadresse identisch sind, muss das System die Daten auto-populieren oder durch einen simplen Klick (Checkbox "Wie Rechnungsadresse") zur Verfügung stellen. Ausnahmen existieren nur, wenn die erneute Eingabe aus Sicherheitsgründen essenziell ist oder die vorherigen Daten nicht mehr valide sind.

3.3.8 Accessible Authentication (Minimum)AA

Dieses Kriterium revolutioniert den Login-Prozess. Ein kognitiver Funktionstest – wie das Auswendiglernen und Eintippen eines komplexen Passworts, das Lösen einer Rechenaufgabe, das Erkennen verschleierter Zeichenfolge (klassische CAPTCHAs) oder das Auswählen spezifischer Bildsegmente ("Klicken Sie auf alle Ampeln") – darf nicht der einzige Weg sein, um sich zu authentifizieren. Es müssen alternative Mechanismen angeboten werden. Dazu gehört zwingend die Erlaubnis von Copy-Paste-Funktionen (das Setzen von onPaste={(e) => e.preventDefault()} auf Passwort-Feldern ist ein direkter WCAG-Verstoß), die korrekte semantische Unterstützung von Passwort-Managern (durch Attribute wie autocomplete="current-password"), die Integration von WebAuthn/Biometrie oder die Bereitstellung von E-Mail-Magic-Links oder SMS-Token.

Besonders im Bereich des E-Commerce, der das Herzstück des Anwendungsbereichs des BFSG bildet, entfalten die Kriterien 3.3.7 (Redundant Entry) und 3.3.8 (Accessible Authentication) eine enorme juristische Brisanz, da sie direkt in die Architektur von Checkout- und Kundenportal-Prozessen eingreifen. KI-Systeme generieren häufig Standard-Login-Formulare, die Passwort-Einfügen blockieren, in der Annahme, dies erhöhe die Sicherheit. Eine solche KI-generierte Maßnahme führt unter dem BFSG ab 2025 direkt zur rechtlichen Angreifbarkeit des Systems.

5. Semantisches HTML und WAI-ARIA Pattern für komplexe UI-Komponenten

Die Basis jeglicher Barrierefreiheit im Web ist valides, semantisches HTML. KI-Codegeneratoren wie Claude tendieren bei ungenügendem Kontextualisierung dazu, visuell ansprechende, aber semantisch nutzlose Komponenten zu generieren. Das häufigste und gravierendste Anti-Pattern ist die Verwendung von generischen Containern (<div> oder <span>) gepaart mit JavaScript-Event-Listenern (onClick), um Interaktionen zu simulieren. Solche Elemente besitzen für einen Screenreader keine inhärente semantische Bedeutung; sie werden nicht als Schalter oder Verknüpfung angesagt und sind ohne zusätzliche, komplexe Modifikationen (Zuweisung von tabindex="0" und Key-Listenern für die Enter- und Leertaste) nicht über die Tastatur ansteuerbar.

Für die BFSG-konforme Softwareentwicklung muss das Vibecoding streng auf die Nutzung nativer HTML5-Elemente (wie <button>, <nav>, <dialog>) ausgerichtet sein. Wenn die visuelle Komplexität den Bau eigener (Custom) Widgets erzwingt, muss die KI zwingend die Vorgaben des W3C ARIA Authoring Practices Guide (APG) implementieren. Accessible Rich Internet Applications (WAI-ARIA) ist eine technische Spezifikation, die es ermöglicht, komplexe Webanwendungen durch zusätzliche Rollen (roles), Zustände (states) und Eigenschaften (properties) für assistive Technologien übersetzbar zu machen.

Zwei der architektonisch komplexesten, aber in modernen Single Page Applications (SPAs) am häufigsten verwendeten Pattern sind das Akkordeon und das Tab-Interface. Das korrekte DOM-Routing und das Tastatur-Event-Management dieser Komponenten müssen tief im Skill-Set des KI-Agenten verankert sein.

5.1 Das Tabs-Pattern (Registerkarten)

Ein funktionales, WCAG-konformes Tab-Interface ist weit mehr als eine visuelle Aneinanderreihung von Buttons, die Inhaltscontainer ein- und ausblenden. Es erfordert ein hochgradig orchestriertes Zusammenspiel von ARIA-Rollen und einem elaborierten Tastatur-Fokus-Management, dem sogenannten "Roving Tabindex" (Wandernder Tabindex).

Die semantische Grundstruktur verlangt einen übergeordneten Container, der mit der Rolle role="tablist" deklariert ist. Dieser Container umschließt die eigentlichen Registerkarten, welche zwingend die Rolle role="tab" aufweisen müssen. Die separaten Inhaltsbereiche, die durch die Tabs gesteuert werden, erhalten die Rolle role="tabpanel". Die semantische Verknüpfung dieser DOM-Knoten erfolgt bidirektional: Jedes tab-Element referenziert die ID seines korrespondierenden tabpanel-Elements über das Attribut aria-controls. Umgekehrt verweist jedes tabpanel über das Attribut aria-labelledby zurück auf die ID seines steuernden tab-Elements, sodass der Screenreader beim Betreten des Inhaltsbereichs den Namen des aktiven Tabs ansagen kann. Der Zustand der Aktivierung wird dem Accessibility-Tree über das Attribut aria-selected kommuniziert. Der aktuell aktive Tab erhält den Wert aria-selected="true", während alle anderen inaktiven Tabs zwingend den Wert aria-selected="false" führen müssen.

Die höchste Fehlerquote bei der KI-gestützten Entwicklung von Tab-Widgets liegt in der Implementierung der Tastatur-Logik. Im Gegensatz zu einfachen Navigationsmenüs werden die einzelnen Tabs innerhalb einer tablist nicht über die Tabulator-Taste angesteuert. Nur der aktuell aktive Tab befindet sich in der normalen Tab-Sequenz der Seite, gekennzeichnet durch das Attribut tabindex="0". Alle inaktiven Tabs werden durch die Zuweisung von tabindex="-1" explizit aus der Tab-Reihenfolge entfernt. Erhält die tablist den Fokus, landet dieser auf dem aktiven Tab (z.B. Tab 1). Die Navigation zwischen den einzelnen Registerkarten erfolgt ab diesem Punkt ausschließlich über die Pfeiltasten (Links/Rechts bei horizontaler Ausrichtung, Oben/Unten bei vertikaler Ausrichtung). Drückt der Nutzer beispielsweise die Pfeiltaste nach rechts, muss das JavaScript-Event den Fokus programmatisch von Tab 1 auf Tab 2 verschieben. Gleichzeitig wird der tabindex von Tab 1 auf -1 gesetzt und der tabindex von Tab 2 auf 0 angehoben – der Tabindex "wandert" mit dem Fokus. Drückt der Nutzer hingegen die Tabulator-Taste, während der Fokus auf dem aktiven Tab liegt, verlässt der Fokus die tablist vollständig und springt direkt in das zugehörige tabpanel (welches selbst fokussierbar sein sollte, idealerweise über tabindex="0", falls es keine nativ fokussierbaren Kind-Elemente enthält) oder zum nächsten interaktiven Element der Webseite.

Hinsichtlich der Aktivierungslogik differenziert das W3C zwischen automatischer und manueller Aktivierung. Wenn die Inhalte aller Tab-Panels bereits im DOM geladen sind, kann "Selection Follows Focus" implementiert werden: Das Drücken einer Pfeiltaste bewegt nicht nur den Fokus, sondern ändert augenblicklich den Zustand auf aria-selected="true" und macht das zugehörige Panel sichtbar. Dies ermöglicht eine extrem schnelle Navigation. Bei asynchron ladenden Inhalten (Netzwerk-Latenz) ist eine manuelle Aktivierung zwingend geboten. Der Nutzer navigiert mit den Pfeiltasten den Fokus über die inaktiven Tabs und muss die Auswahl explizit durch Drücken der Leer- oder Eingabetaste (Space/Enter) bestätigen, um das Panel zu laden und anzuzeigen.

5.2 Das Akkordeon-Pattern

Das Akkordeon-Pattern unterscheidet sich fundamental von einem Tab-Interface, wird jedoch von KI-Agenten und Junior-Entwicklern häufig konzeptionell vermischt, was zu schwerwiegenden Usability-Barrieren führt. Ein Akkordeon ist eine vertikal gestapelte Liste von interaktiven Kopfzeilen (Headern), die jeweils einen Inhaltsbereich (Panel) auf- und zuklappen.

Die Kopfzeile eines Akkordeons muss semantisch so aufgebaut sein, dass sie sowohl als Überschrift im Dokumentenkontext als auch als interaktiver Schalter erkannt wird. Dazu muss ein echtes <button>-Element (oder ein Element mit role="button") zwingend innerhalb eines Überschriften-Tags (wie <h3>, <h4>) oder eines Containers mit role="heading" und entsprechendem aria-level platziert werden. Dies ermöglicht es Screenreader-Nutzern, die Seite schnell über die Überschriften-Ebenen zu durchkämmen, ohne jeden Button einzeln anfokussieren zu müssen.

Der Button selbst steuert den Zustand seines Panels. Er muss das Attribut aria-controls tragen, welches auf die ID des Containers verweist, der den Inhalt des Panels birgt. Der visuelle Zustand (aufgeklappt oder zugeklappt) wird über das Attribut aria-expanded an assistive Technologien übermittelt. Ist das Panel sichtbar, lautet der Wert aria-expanded="true"; ist es verborgen, aria-expanded="false". Eine spezifische Regel greift, wenn die Architektur des Akkordeons vorschreibt, dass stets mindestens ein Panel geöffnet bleiben muss und der Nutzer ein offenes Panel nicht durch einen erneuten Klick schließen kann. In diesem Fall muss der Button des geöffneten Panels zusätzlich das Attribut aria-disabled="true" erhalten, um dem Nutzer zu signalisieren, dass eine Interaktion an dieser Stelle keine Zustandsänderung herbeiführen wird.

Die Tastaturnavigation innerhalb eines Akkordeons ist im Vergleich zu den Tabs deutlich linearer. Alle Akkordeon-Kopfzeilen (die <button>-Elemente) befinden sich in der regulären Tab-Sequenz der Seite. Der Fokus wandert durch das Drücken der Tab-Taste von einer Kopfzeile zur nächsten, beziehungsweise in die interaktiven Inhalte eines geöffneten Panels. Die Aktivierung (Auf-/Zuklappen) erfolgt strikt über die Eingabetaste (Enter) oder die Leertaste (Space). Die Nutzung von Pfeiltasten zum Bewegen zwischen den Kopfzeilen ist beim Akkordeon-Pattern laut W3C optional, im absoluten Gegensatz zum zwingend erforderlichen Pfeiltasten-Routing beim Tab-Pattern.

5.3 Typografie, Fokus-Sichtbarkeit und Kontraste

Neben der DOM-Struktur und der Tastatur-Logik muss die visuelle Ebene der UI-Komponenten strenge mathematische Vorgaben erfüllen, die von der KI beim Generieren von CSS (beispielsweise Tailwind-Klassen) berücksichtigt werden müssen.

Das Erfolgskriterium 1.4.3 (Kontrast Minimum, Level AA) schreibt vor, dass der Kontrast zwischen der Textfarbe und der Hintergrundfarbe im Regelfall mindestens 4,5:1 betragen muss. Für großen Text (definiert als Text ab 18 Punkt oder 14 Punkt in Fettdruck) ist ein reduziertes Minimum von 3,0:1 zulässig. Eine wesentliche Anforderung der WCAG ist, dass Farbe niemals das einzige Unterscheidungsmerkmal sein darf, um Informationen zu vermitteln (Kriterium 1.4.1 Use of Color). Ein Formularfeld, dessen Rand bei einem Validierungsfehler lediglich rot eingefärbt wird, verstößt gegen die Richtlinien, wenn nicht zusätzlich ein textueller Fehlerhinweis oder ein Warn-Icon (verbunden mit aria-invalid="true") existiert.

Eines der in der Praxis am häufigsten verletzten Kriterien ist das Sichtbarmachen des Tastaturfokus (2.4.7 Focus Visible, Level A). Interaktive Elemente müssen deutlich visuell hervorgehoben werden, wenn sie durch die Tab-Taste angesteuert werden, damit motorisch oder visuell eingeschränkte Nutzer wissen, welches Element bei Auslösung der Enter-Taste reagieren wird. KI-generierter CSS-Code enthält in Styling-Resets sehr häufig die Direktive outline: none;, um den oft als unästhetisch empfundenen Standard-Fokusring der Browser zu unterdrücken. Dies ist ein eklatanter Verstoß, wenn nicht zeitgleich ein barrierefreier, maßgeschneiderter Fokus-Zustand (Custom Focus State) definiert wird, der selbst ausreichende Kontrastwerte (mindestens 3:1 gegenüber dem angrenzenden Hintergrund) aufweist.

5.4 Die technische Kennzeichnung von Sprache

Zur korrekten Interpretation von Inhalten durch Screenreader und Suchmaschinen muss die Dokumentensprache technisch einwandfrei ausgezeichnet sein. Dies geschieht global im obersten Knoten des Dokuments, dem <html>-Tag, durch die Zuweisung des lang-Attributs (beispielsweise <html lang="de"> für Deutsch).

Ein kritischer und oft übersehener architektonischer Punkt entsteht in heterogenen Textstrukturen. Wenn innerhalb einer primär deutschen Seite längere englische Zitate, fachspezifische englische Begriffe oder auch Inhalte in Leichter Sprache (welche für die BITV 2.0 relevant ist) eingebettet sind, müssen diese abweichenden Textsegmente (eingefasst in <span> oder <div>) zwingend eigene, spezifische lang-Attribute erhalten. Fehlen diese untergeordneten Sprachdeklarationen, wechselt die Synthesizer-Engine des Screenreaders nicht das phonetische Aussprache-Modell, was dazu führt, dass englische Wörter mit deutscher Phonetik vorgelesen werden und somit völlig unverständlich werden. Es gilt die eherne HTML-Regel: Ein Element kann nur ein einziges lang-Attribut besitzen. Enthält ein Absatz mehrere Sprachen, müssen die abweichenden Phrasen in separaten, verschachtelten Elementen mit eigenen Language-Tags gekapselt werden.

6. Dokumentationspflichten: Barrierefreiheitserklärung und Feedback-Mechanismus

Die Gewährleistung von Barrierefreiheit unter dem Barrierefreiheitsstärkungsgesetz sowie der BITV 2.0 beschränkt sich nicht auf das Schreiben sauberen Codes. Beide Regelwerke verlangen ein hohes Maß an administrativer Transparenz und die Etablierung direkter Kommunikationskanäle zwischen Betreiber und Nutzer.

6.1 Die Erklärung zur Barrierefreiheit

Betreiber von Websites, E-Commerce-Plattformen und mobilen Anwendungen müssen eine sogenannte "Erklärung zur Barrierefreiheit" veröffentlichen. Dieses Dokument darf nicht im Impressum oder der Datenschutzerklärung versteckt werden, sondern muss als eigenständige, von jeder Seite des Webauftritts aus direkt erreichbare Seite (in der Regel über einen Link im globalen Footer) verlinkt sein. Diese Erklärung ist kein formloses Dokument, sondern unterliegt genauen inhaltlichen Vorgaben gemäß Anlage 3 des BFSG sowie den Bestimmungen der BITV 2.0.

Die zwingenden Inhalte umfassen :

Stand der Vereinbarkeit: Das Dokument muss eine klare, unmissverständliche Aussage darüber treffen, inwieweit die digitale Präsenz mit den geltenden Anforderungen (BFSG, WCAG 2.1/2.2) vereinbar ist. Die Einstufung erfolgt in der Regel als "vollständig barrierefrei", "teilweise barrierefrei" oder "nicht barrierefrei".
Beschreibung der Barrieren: Es muss eine detaillierte und ehrliche Auflistung der Inhalte, Funktionen oder Dokumente (wie beispielsweise eingebundene PDFs oder komplexe interaktive Dashboards) erfolgen, die aktuell noch nicht barrierefrei zugänglich sind. Diese Auflistung muss mit einer Begründung versehen werden, warum die Barrierefreiheit derzeit nicht gegeben ist, und idealerweise aufzeigen, welche Maßnahmen zu welchem Zeitpunkt geplant sind, um diese Mängel zu beheben.
Beschreibung der Anforderungen für Dienstleistungen: Spezifisch für das BFSG fordert die Anlage 3, dass die Erklärung auch eine Beschreibung der für die jeweilige Dienstleistung geltenden Barrierefreiheitsanforderungen selbst enthalten soll. Der Betreiber muss nachvollziehbar darlegen, wie die Gestaltung und die Durchführung des Dienstes im Lichte dieser Anforderungen konzipiert wurden.

6.2 Der Feedback-Mechanismus und das Durchsetzungsverfahren

Ein integraler und gesetzlich zwingend vorgeschriebener Bestandteil der Erklärung zur Barrierefreiheit ist die Bereitstellung eines Feedback-Mechanismus. Nutzer müssen in die Lage versetzt werden, dem Betreiber konkrete, auf der Website oder in der App vorgefundene Barrieren einfach und direkt zu melden. Die Ironie, dass Formulare zur Meldung von Barrieren oftmals selbst nicht barrierefrei sind, muss hier durch exzellentes Engineering vermieden werden. Der Mechanismus – meist realisiert durch ein Kontaktformular oder eine spezifisch benannte E-Mail-Adresse – muss klare Kontaktinformationen der zuständigen Stelle enthalten. Formularfelder müssen semantisch korrekt mit Labels verknüpft sein, und Nutzer sollten die Möglichkeit haben, die gemeldete Barriere genau zu verorten (Ort, Art der Barriere, genutztes Assistenzsystem). Das Gesetz verlangt vom Betreiber, dass er auf solche Anfragen zeitnah reagiert und interne Prozesse definiert, um Rückmeldungen innerhalb einer angemessenen Frist zu bearbeiten.

Bleibt eine befriedigende Reaktion des Website-Betreibers auf eine via Feedback-Mechanismus eingereichte Meldung aus, oder wird der Mangel nicht behoben, sieht der Gesetzgeber den Weg über etablierte Durchsetzungs- und Schlichtungsstellen vor. Die Kontaktinformationen der jeweils zuständigen Schlichtungsstelle, verlinkt auf deren Webpräsenz, müssen zwingend als Eskalationsstufe in der Erklärung zur Barrierefreiheit aufgeführt sein, um dem Nutzer seine rechtlichen Optionen transparent aufzuzeigen.

7. Vibecoding mit Claude: Methodik, Context Engineering und MCP-Integration

Das traditionelle Modell der Softwareentwicklung wandelt sich radikal hin zu dem, was in der Branche zunehmend als "Vibecoding" bezeichnet wird. Bei diesem Paradigma steuern Entwickler über spezialisierte Schnittstellen und IDE-Plugins wie Claude Code (das CLI-Tool von Anthropic), Cursor oder GitHub Copilot primär die Architektur, die funktionale Intention und den geschäftlichen Kontext einer Anwendung. Die Künstliche Intelligenz übernimmt die Rolle des ausführenden Organs und schreibt den tatsächlichen, syntaktischen Code.

Dieser Prozess beschleunigt die Entwicklung von Features massiv, birgt jedoch eine gefährliche Falle: Die Qualität des Outputs ist linear abhängig von der Qualität des Inputs und der Kontextualisierung des Modells ("Garbage In, Garbage Out"). Wenn die strikten Regularien der Barrierefreiheit in diesem Workflow ignoriert oder als nachträgliches Add-on behandelt werden, generiert die KI in rasanter Geschwindigkeit Standard-Code, der auf visueller Ebene funktioniert, jedoch semantisch mangelhaft ist und den Vorgaben des BFSG diametral widerspricht. Um diese fatale Anhäufung technischer und rechtlicher Schulden zu verhindern, muss der KI-Agent tiefgreifend kontextuell kalibriert werden. Ein "Skill" für Claude ist in diesem Sinne kein simples Prompting-Makro, sondern ein persistenter, gespeicherter Workflow, der durch präzises Context Engineering und eine spezifische .claude-Projektarchitektur im lokalen Dateisystem manifestiert wird.

7.1 Die Architektur eines Claude Code Skills und das Context Engineering

Ein professioneller, rechtssicherer Workflow für Claude Code basiert auf drei wesentlichen technologischen Säulen, die das Verhalten des Agenten determinieren:

Die fundamentale Basis bildet die CLAUDE.md Datei. Diese Markdown-Datei, die zwingend im Stammverzeichnis (Root) des Entwicklungsprojekts abgelegt werden muss, fungiert als das "Second Brain" und als permanentes, globales System-Prompt für den KI-Agenten. Claude Code ist darauf programmiert, diese Datei bei der Initialisierung des Workspaces und bei jedem signifikanten Kontextwechsel automatisch auszulesen. In dieser Datei müssen die strikten Barrierefreiheits-Paradigmen, bevorzugte strukturelle Hooks (wie das absolute Verbot der Nutzung von onClick-Events auf div-Elementen) und die spezifischen Hinweise auf die BFSG-Konformität unverrückbar verankert werden.

Die zweite Säule ist die Anbindung von Model Context Protocol (MCP) Servern. Das MCP ist ein universelles Konnektivitäts-Protokoll, das Claude aus seiner isolierten Text-Umgebung befreit und ihm den direkten Zugriff auf externe Tools und Datenquellen ermöglicht. Durch die Initialisierung eines MCP-Servers für das lokale Dateisystem (@modelcontextprotocol/server-filesystem) kann Claude befähigt werden, maschinell erstellte Accessibility-Reports – beispielsweise generiert durch Google Lighthouse CLI oder axe-core Skripte – autonom auszulesen, die darin gelisteten DOM-Knoten-Fehler zu identifizieren und eigenständig Refactoring-Vorschläge zur Fehlerbehebung zu unterbreiten. Über GitHub-MCP-Integrationen kann der Agent angewiesen werden, Pull Requests vor dem Merge gegen Checklisten für semantisches HTML zu prüfen.

Die dritte, hochgradig fortgeschrittene Säule besteht in der Nutzung von PreToolUse Hooks innerhalb der lokalen Projekt-Konfigurationsdatei .claude.json. Entwickler können hier Shell-Kommandos definieren, die zwangsweise ausgeführt werden, bevor Claude Code bestimmte Operationen abschließt. Ein solcher Hook kann beispielsweise so konfiguriert werden, dass vor jedem Commit automatisiert ein Linter, speziell konfiguriert mit Barrierefreiheits-Regelwerken (wie das eslint-plugin-jsx-a11y für React-Projekte), über die modifizierten Dateien laufen muss. Produziert der Linter einen Warnhinweis bezüglich eines fehlenden alt-Attributs oder eines unzureichenden Kontrastwertes, wird der Prozess unterbrochen. Der Hook sendet den Fehler als strukturiertes JSON-Feedback an Claude zurück, was den Agenten zwingt, seinen eigenen fehlerhaften Code zu korrigieren, bevor der Entwicklungszyklus fortgesetzt werden kann.

7.2 Der zyklische Workflow: Explore, Plan, Code, Verify

Die Erstellung von barrierefreiem Code durch KI erfordert eine methodische Disziplin. Die offizielle Best Practice von Anthropic für den effizienten Einsatz von Claude Code diktiert den Rhythmus: "Explore first, then plan, then code". Wird der Agent angewiesen, ein Problem ohne vorherige Analyse der bestehenden Architektur direkt durch Code-Generierung zu lösen, entsteht unweigerlich fragmentierter, kontextblinder Code.

In der initialen Explore-Phase wird der Agent beauftragt, den existierenden Code und die DOM-Struktur zu analysieren. Der Prompt lautet hier nicht "Baue einen barrierefreien Checkout", sondern evaluativ: "Untersuche die Komponenten des aktuellen Checkout-Prozesses und bewerte sie hinsichtlich ihrer Konformität mit den Redundant Entry und Accessible Authentication Kriterien der WCAG 2.2 AA". Da die Analyse tiefer Dateibäume den Kontext-Speicher (Context Window) des Modells stark beanspruchen kann, empfiehlt sich die Nutzung von Subagenten für die Detailanalyse sowie die regelmäßige Anwendung des /compact-Befehls, um die gespeicherten Informationen zu verdichten.

Auf die Exploration folgt der zwingende Plan-Modus. Durch die Eingabe von Shift+Tab in der Claude Code CLI wechselt der Agent in einen dedizierten Planungszustand. In diesem Modus schreibt Claude keinen ausführbaren Code, sondern generiert einen detaillierten Architekturplan für das gewünschte Feature. Hier formuliert die KI, welche semantischen HTML-Tags sie verwenden wird, wie das ARIA-Zustandsmanagement (z.B. bei einem Tab-Widget) orchestriert wird und wie die Tastatur-Fokus-Routen verlaufen sollen. Dies ist der kritischste Moment für den menschlichen Entwickler: Er validiert, ob der Plan der KI die Vorgaben aus der CLAUDE.md korrekt adaptiert hat. Erst wenn der Plan den Anforderungen von BFSG und WCAG 2.2 entspricht, wird dieser genehmigt.

In der abschließenden Code-Phase verlässt Claude den Planungsmodus und generiert den syntaktischen Code exakt nach dem verabschiedeten Plan. Dieser orchestrierte Ablauf verhindert, dass die KI mitten in der Datei-Bearbeitung architektonische Designentscheidungen trifft, die Accessibility-Standards kompromittieren.

8. Der Claude-Skill: System-Prompt für rechtskonformes Vibecoding

Das folgende Artefakt stellt das Destillat der juristischen, architektonischen und prozessualen Forschungsarbeit dieses Berichts dar. Um Claude effektiv für die BFSG-konforme Softwareentwicklung zu konditionieren, muss der folgende Markdown-Block exakt wie vorgegeben als Datei mit dem Namen CLAUDE.md in das Root-Verzeichnis eines Projekts gelegt werden. Alternativ kann die Struktur, sofern Entwicklungsumgebungen wie Cursor oder GitHub Copilot genutzt werden, in die entsprechenden globalen Custom Instructions oder System Prompts transferiert werden.

Dieser Prompt ist technologisch hochgradig spezifisch. Er nutzt XML-Tags, um die Aufmerksamkeit des Large Language Models auf Prioritäten zu lenken, wie es den Best Practices des Prompt Engineerings für Anthropic-Modelle entspricht. Er zwingt den Agenten zur Nutzung der neuesten WCAG 2.2 Standards, verbietet explizit veraltete oder schädliche Code-Praktiken, fordert die korrekte Implementation komplexer ARIA-Pattern und integriert die spezifischen Vorgaben der deutschen Gesetzgebung.

8.1 System Prompt / CLAUDE.md Framework

Project Guidelines: German Accessibility (BFSG & BITV 2.0) & WCAG 2.2 AA Compliance

<technical_stack_constraints>

CSS Utility Frameworks: When utilizing CSS frameworks like Tailwind, you must explicitly code highly visible, contrast-compliant focus states (e.g., focus-visible:ring-2 focus-visible:ring-offset-2 focus-visible:ring-blue-600) to strictly comply with WCAG 2.4.7 and 2.4.11.
Forbidden CSS: NEVER generate outline: none; or outline: 0; unless it is immediately accompanied by a robust, high-contrast custom focus indicator that meets a minimum 3:1 contrast ratio against the adjacent background.
</technical_stack_constraints>

<wcag_2_2_mandatory_rules>
Every time you plan or generate UI components, you must internally verify your output against these critical WCAG 2.2 AA criteria:

Target Size (Minimum) (2.5.8): All interactive elements (buttons, links, form controls, hamburger menus) MUST have a minimum bounding box of 24x24 CSS pixels, inclusive of padding.
Focus Not Obscured (2.4.11): Ensure floating or fixed elements (sticky headers, cookie consent banners, persistent footers) do not completely hide an element when it receives keyboard focus. Implement scroll-padding-top or scroll-margin in global layouts.
Color Contrast (1.4.3): Maintain at least a 4.5:1 contrast ratio for normal text and 3:1 for large text (18pt or 14pt bold) and essential UI components. Color must never be the ONLY visual means of conveying information (1.4.1 Use of Color).
Redundant Entry (3.3.7): Never generate multi-step forms (like checkout flows) that ask for the previously entered information twice without providing an auto-fill mechanism, a dropdown selection, or a copy checkbox.
Accessible Authentication (3.3.8): Never block the system clipboard (copy-pasting) in password fields. Never rely solely on cognitive tests (CAPTCHAs, math puzzles) for login. You must provide autocomplete support (e.g., <input type="password" autocomplete="current-password" />) to ensure password managers function correctly.
Dragging Movements (2.5.7): Any functionality requiring a dragging motion (sliders, drag-and-drop lists) must also be operable via simple, single-pointer clicks/taps.
</wcag_2_2_mandatory_rules>

Forbidden Anti-Patterns:

❌ <div onClick={...}> or <span onClick={...}> - NEVER DO THIS. Always use <button type="button"> for actions.
❌ Using role="button" without implementing onKeyDown handlers for BOTH the Enter and Space keys to trigger the action.
❌ Creating modal dialogs that do not trap keyboard focus within the modal while it is open.

Required Architectural Patterns:

Tabs Interface: Must consist of a container with role="tablist", interactive elements with role="tab", and content containers with role="tabpanel". Tabs MUST be linked via aria-controls and aria-labelledby. Crucially, implement a roving tabindex: the active tab has tabindex="0", all inactive tabs must have tabindex="-1". Keyboard routing between tabs must occur via Left/Right Arrow keys, NOT the Tab key.
Accordion: The clickable header must be a <button> semantically wrapped inside a heading tag (e.g., <h3>). The button requires aria-expanded={isOpen} and aria-controls="panel-id". Navigation occurs via the Tab key, activation via Enter/Space.
Forms: Every <input>, <select>, or <textarea> must have a programmatically associated <label> (using the for or htmlFor attribute linking to the input's id). Placeholder attributes are NEVER an acceptable substitute for a label.
</semantic_html_and_aria>

<german_law_specifics>

Document Language: Always ensure the document structure has the correct primary language attribute declared: <html lang="de">.
Language Shifts: If embedding English terms, quotes, or segments written in "Leichte Sprache" (Easy Language, highly relevant for BITV 2.0) within a German page, you must wrap that specific content in a container with a distinct language tag (e.g., <span lang="en"> or <div lang="de-x-simple">) to instruct screen reader synthesizers to switch their phonetic engine.
Documentation Architecture: BFSG mandates the existence of a "Barrierefreiheitserklärung" (Accessibility Statement) and a distinct "Feedback-Mechanismus" (Feedback Form). When scaffolding projects, remind the developer to include routes and compliant semantic structures for these legally required pages.
</german_law_specifics>

<workflow_execution>
When I instruct you to build, refactor, or analyze a feature, follow this loop:

Analyze: Briefly assess how the request intersects with WCAG 2.2 and BFSG requirements.
Plan (Shift+Tab): Output a concise architectural plan outlining the semantic HTML structure, the ARIA attributes, and the keyboard focus management logic you intend to use. Wait for my confirmation.
Execute: Write clean, modular, accessible code strictly adhering to the plan.
Self-Audit: Add a brief comment block at the end of your response stating: "A11y Audit: Verified Keyboard Operability (Enter/Space), Screen Reader Semantics (Labels/Roles), and Target Size compliance."
</workflow_execution>

Barrierefreiheit per KI: Der Vibe-Coding Skill

⚡Das Wichtigste in Kürze

Hier ist der Skill zum Kopieren:

<technical_stack_constraints>

Deep Research Report: Digitale Barrierefreiheit nach deutscher Gesetzgebung und Implementierung als Claude-Skill für Vibecoding

1. Einleitung und Management Summary

2. Die gesetzliche Architektur der digitalen Barrierefreiheit in Deutschland

2.1 Das Barrierefreiheitsstärkungsgesetz (BFSG) für die Privatwirtschaft

2.2 Behindertengleichstellungsgesetz (BGG) und die Barrierefreie-Informationstechnik-Verordnung (BITV 2.0)

2.3 Sanktionsmechanismen und Rechtsdurchsetzung

3. Ökonomische Dimensionen und methodische Prüfverfahren

3.1 Kostenstrukturen der digitalen Barrierefreiheit

3.2 Systematische Prüfverfahren und Tooling

4. Technische Spezifikationen und die Evolution zu WCAG 2.2

4.1 Die Hierarchie der Konformitätsstufen

4.2 Der Paradigmenwechsel von WCAG 2.1 zu WCAG 2.2

4.3 Analyse der neuen WCAG 2.2 Erfolgskriterien (Level A und AA)

5. Semantisches HTML und WAI-ARIA Pattern für komplexe UI-Komponenten

5.1 Das Tabs-Pattern (Registerkarten)

5.2 Das Akkordeon-Pattern

5.3 Typografie, Fokus-Sichtbarkeit und Kontraste

5.4 Die technische Kennzeichnung von Sprache

6. Dokumentationspflichten: Barrierefreiheitserklärung und Feedback-Mechanismus

6.1 Die Erklärung zur Barrierefreiheit

6.2 Der Feedback-Mechanismus und das Durchsetzungsverfahren

7. Vibecoding mit Claude: Methodik, Context Engineering und MCP-Integration

7.1 Die Architektur eines Claude Code Skills und das Context Engineering

7.2 Der zyklische Workflow: Explore, Plan, Code, Verify

8. Der Claude-Skill: System-Prompt für rechtskonformes Vibecoding

8.1 System Prompt / CLAUDE.md Framework

Project Guidelines: German Accessibility (BFSG & BITV 2.0) & WCAG 2.2 AA Compliance

<technical_stack_constraints>

❓ Häufige Fragen

Was ist barrierefreies Vibe-Coding?

Welche Standards muss barrierefreies Vibe-Coding erfüllen?

Warum sind Fokuszustände und Kontraste im Accessibility-Skill so wichtig?

Welche HTML- und ARIA-Regeln empfiehlt der Artikel für barrierefreie Komponenten?

Ist der Skill auch für E-Commerce und B2C-Services relevant?

Weiterlesen

Mechanismen selbstlernender KI-Agenten

Paraguay Fisch Guide - Was gibt es und wie gut ist es?

Paraguay Fleisch-Guide: So nutzt man jedes Teil

💬 Kommentare

Kommentar schreiben