bestgirlfriend.ai
KI-Freundin finden
Redaktion

Barrierefreiheit 2026: WCAG 2.1 AA, Ziele + Ausnahmen

Barrierefreiheits-Erklärung in Klartext: Ziel WCAG 2.1 AA, axe-core + Lighthouse Pipeline, eine dokumentierte Markenfarben-Ausnahme. Melde uns eine Hürde.

Von Zuletzt überarbeitet Juni 2026

Die meisten Barrierefreiheits-Erklärungen in dem Bereich lügen entweder offen („100 % WCAG-AA-konform!") oder klatschen einen generischen Textbaustein hin, der jede bekannte Ausnahme hinter einer Nebelwand aus Konformitäts-Jargon vergräbt. Diese hier ist kürzer, sortiert nach dem, was du wirklich wissen musst, und ehrlich bei der einen Ausnahme, die wir akzeptieren. Ich hab sie so geschrieben, wie ich sie selbst lesen wollen würde.

bestgirlfriend.ai ist ein redaktioneller Vergleich rund um KI-Freundin-Apps, KI-Freund-Apps, Sexcam-Seiten, Real-Model-Creator und Porno-Spiele. Barrierefreiheit gehört zur redaktionellen Grundlinie, ist kein Feature, das man zum Launch nachrüstet. Diese Seite dokumentiert die Standards, auf die wir bauen, die Techniken, die wir nutzen, die eine Ausnahme, die wir akzeptieren, und warum, die Lücken, die wir noch offen haben, und den Kanal, um eine Hürde zu melden.

Diese Erklärung richtet sich nach dem US Section 508 Refresh (29 U.S.C. §794d, harmonisiert mit WCAG 2.0 AA über den ICT Refresh 2018), dem harmonisierten EU-Standard EN 301 549 v3.2.1 (auf den die Web Accessibility Directive 2016/2102 und der European Accessibility Act 2019/882 verweisen, durchsetzbar ab 28. Juni 2025), den UK Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 und dem Accessibility for Ontarians with Disabilities Act, 2005 samt seiner Integrated Accessibility Standards Regulation. Wir sind ein privater Verlag, keine öffentliche Stelle, halten uns aber an dasselbe Konformitäts-Level, weil die gesetzliche Untergrenze die richtige Startlinie ist.

Ist bestgirlfriend.ai WCAG-konform?

Wir zielen auf WCAG 2.1 Level AA auf jeder öffentlichen Seite und erreichen das Ziel bei jedem Erfolgskriterium bis auf eine dokumentierte Ausnahme: Markenfarbe #E94B6A auf Creme #FAF7F2 ergibt 3,46:1 Kontrast, unter dem AA-Schwellenwert von 4,5:1 für Fließtext. Die Koralle ist auf Buttons, Badges, Links und dekorative Akzente beschränkt (die 3:1-Oberfläche gemäß WCAG 1.4.11), nie für Fließtext genutzt. Jedes andere Erfolgskriterium ist erfüllt, und die Ausnahme ist mit ihren Messwerten in unserem Design-System protokolliert.

Zuletzt geprüft: 2026

Konformität ist etwas, das man laufend tut, kein Häkchen, das man einmal setzt. Die Seite ist auf WCAG 2.1 AA gebaut, die vier Prinzipien (wahrnehmbar, bedienbar, verständlich, robust) stecken darin, wie die Seiten gestaltet sind, und jeder Commit besteht automatisierte Checks, bevor er gemergt wird. Der eine Kompromiss, den wir akzeptieren, ist der Markenfarben-Kontrast beim korallenen Akzent, und das sagen wir gleich vorne, statt es in einer Teil-Konformitäts-Fußnote ganz unten auf der Seite zu verstecken. Der Rest dieser Seite dokumentiert, was das konkret heißt.

Welchen Standards folgen wir?

WCAG 2.1 Level AA ist unser technisches Ziel. Darauf verweisen US Section 508 (ICT Refresh 2018), der harmonisierte EU-Standard EN 301 549 v3.2.1, die EU Web Accessibility Directive 2016/2102, der European Accessibility Act 2019/882 (durchsetzbar ab 28. Juni 2025), die UK Public Sector Bodies Accessibility Regulations 2018 und Ontario AODA Integrated Accessibility Standards Regulation.

WCAG 2.1 AA ist die globale Verkehrssprache der digitalen Barrierefreiheit [Source: W3C, Web Content Accessibility Guidelines 2.1, W3C Recommendation 05. Juni 2018 · verified 2026-05-26]. Section 508 verweist über den US ICT Refresh darauf [Source: US Section 508, ICT Refresh Standards · verified 2026-05-26]. EN 301 549 verweist als harmonisierter europäischer Standard darauf [Source: ETSI EN 301 549, Barrierefreiheits-Anforderungen für IKT-Produkte und -Dienste · verified 2026-05-26]. Die UK-Regulierung von 2018 nennt es ausdrücklich. AODA verweist über die Integrated Accessibility Standards Regulation darauf.

AA zu wählen heißt, dass wir alle fünf Regime aus einem technischen Ziel erfüllen. Wir beobachten WCAG 2.2 (veröffentlicht im Oktober 2023) und nehmen seine Erfolgskriterien auf, wo sie nicht mit 2.1 kollidieren. Unsere öffentliche Konformitäts-Aussage rücken wir auf 2.2 AA, sobald die Beschaffungs-Standards in unseren Kernmärkten darauf verweisen.

Die Standard-Landschaft läuft auf WCAG 2.1 AA als testbares technisches Ziel zu. Die fünf Regime, die unsere Märkte regeln, jedes mit der maßgeblichen Referenz verlinkt:

StandardRegionKonformitäts-LevelUnser StatusReferenz
WCAG 2.1 AAGlobal (W3C)Level AAAngepeilt (1 dokumentierte Ausnahme)W3C Recommendation, 5. Juni 2018
EN 301 549 v3.2.1Europäische UnionHarmonisierter Standard, AAAngepeilt (1 dokumentierte Ausnahme)ETSI, März 2021; referenziert von WAD 2016/2102 und EAA 2019/882
Section 508 (ICT Refresh)Vereinigte StaatenWCAG 2.0 AA harmonisiert; AAAngepeilt (mit WCAG 2.1 AA Delta, 1 dokumentierte Ausnahme)36 CFR Part 1194, U.S. Access Board 2018
UK Public Sector Bodies Accessibility Regulations 2018Vereinigtes KönigreichWCAG 2.1 AAAngepeilt (privater Verlag; freiwillig)SI 2018/952
AODA / IASROntario, KanadaWCAG 2.0 AA (IASR §14)Angepeilt (mit WCAG 2.1 AA Delta, 1 dokumentierte Ausnahme)O. Reg. 191/11, Integrated Accessibility Standards
Zuletzt geprüft: 2026.

Welche bekannten Barrierefreiheits-Ausnahmen gibt es?

Zwei. (1) Markenfarben-Kontrast-Ausnahme: #E94B6A Koralle auf Creme #FAF7F2 ergibt 3,46:1, unter dem WCAG-AA-Schwellenwert von 4,5:1 für Fließtext. Die Koralle ist auf Buttons, Badges, Links und dekorative Akzente beschränkt (die 3:1-Oberfläche gemäß WCAG 1.4.11), nie für Fließtext genutzt. (2) Open-Graph-Teilbilder auf einigen Listicle-Seiten haben keinen beschreibenden Alt-Text für Screenreader, wenn sie in Vorschauen von Drittanbieter-Plattformen auftauchen (kosmetisch; in Behebung). Der AI-Concierge-Chatbot hat sein volles Audit noch nicht abgeschlossen und geht erst live, wenn er es tut.

Bekannte Ausnahmen öffentlich aufzulisten ist das ehrliche Gegenstück zu einer Konformitäts-Aussage. WCAG-Konformität ist auf Ebene des Erfolgskriteriums binär: Eine Seite erfüllt das Kriterium oder eben nicht. Wir mischen keinen Teil-Konformitäts-Hinweis in den Seitentext; die Ausnahmen leben hier, in Klartext, mit Begründung und Behebungs-Status.

Die Markenfarben-Ausnahme im Detail. Unsere Hauptakzent-Farbe (#E94B6A, die Koralle auf Buttons und Badges) auf unserem redaktionellen Hintergrund (#FAF7F2, das warme Creme) ergibt einen Kontrast von 3,46:1. WCAG 2.1 AA verlangt 4,5:1 für normalen Fließtext (SC 1.4.3) und 3:1 für großen Text sowie für UI-Komponenten und grafische Objekte (SC 1.4.11). Der Wert von 3,46:1 erfüllt die 3:1-Untergrenze für die UI- / Großtext-Oberfläche und fällt unter die 4,5:1-Untergrenze für Fließtext.

Wir haben die Entscheidung getroffen, den Kompromiss nur für die Marken-Akzent-Oberfläche zu akzeptieren. Die Koralle taucht auf Call-to-Action-Buttons, Link-Unterstreichungen, Badges, der Sticky-Promo-Bar und dekorativen Akzenten auf, alles Oberflächen, wo die 3:1-Untergrenze gilt. Fließtext, Überschriften und aller andere Text nutzen #1A1A1A Beinahe-Schwarz auf dem Creme, das die 4,5:1 locker schafft. Die Entscheidung ist in unserem Design-System samt der Kontrast-Messwerte dokumentiert, sodass der Kompromiss prüfbar ist statt unsichtbar.

Die meisten Bewertungsseiten in dem Bereich legen so einen Marken-Kompromiss überhaupt nicht offen. Sie behaupten volle AA-Konformität, und das Audit erwischt den Akzentfarben-Mangel nie, weil das Audit nie gelaufen ist. Wir lassen das Audit laufen, protokollieren das Ergebnis und sagen dir Bescheid. Das ist halt der Unterschied zwischen einer echten Barrierefreiheits-Erklärung und einem kopierten Textbaustein.

Offene Punkte:

IDProblemSchweregradStatusZiel-Behebung
A11Y-001Markenfarbe (#E94B6A) auf Creme (#FAF7F2) = 3,46:1, unter der AA-Fließtext-Untergrenze von 4,5:1Akzeptierte Ausnahme (nur UI/Akzent; Fließtext nicht betroffen)In Design-Tokens dokumentiertKeine Behebung ohne Markenfarben-Wechsel geplant
A11Y-002Open-Graph-Alt-Text bei Listicle-Social-VorschauenKosmetisch (betrifft das Lesen auf der Seite nicht)In BehebungQ3 2026
A11Y-003AI-Concierge-Chatbot volles WCAG 2.1 AA AuditBlockierend (Chatbot geht erst live, wenn geklärt)Audit ausstehend vor LaunchVor Launch

Stößt du auf ein Problem, das nicht auf dieser Liste steht, melde es bitte. Die Liste wird aktualisiert, sobald ein neues Problem entdeckt oder ein bestehendes geschlossen wird.

Wie melde ich ein Barrierefreiheits-Problem?

Schreib eine Mail an [email protected] mit der Seiten-URL, deinem Browser und deiner assistiven Technik sowie einer kurzen Beschreibung der Hürde. Wir bestätigen jede Meldung innerhalb von 2 Werktagen und zielen bei blockierenden Problemen auf Behebung oder einen Workaround innerhalb von 7 Werktagen. Probleme, die das 7-Tage-Ziel nicht halten können, bekommen eine öffentliche Zwischenlösung plus ein Ziel-Behebungsdatum im Log der bekannten Probleme auf dieser Seite.

Das eigene Postfach ist [email protected]. Damit wir schneller reproduzieren und beheben können, gib bitte nach Möglichkeit an:

  • Die Seiten-URL, wo du auf die Hürde gestoßen bist.
  • Dein Betriebssystem und deinen Browser (samt Version).
  • Die assistive Technik, die du genutzt hast (Screenreader, Switch, Lupe, Sprachsteuerung etc.) und ihre Version.
  • Eine kurze Beschreibung dessen, was du erwartet hast und was stattdessen passiert ist.
  • Einen Screenshot oder eine Bildschirmaufnahme, falls vorhanden und du bereit bist, sie zu teilen.

Du kannst diese Erklärung, eine Audit-Zusammenfassung oder eine bestimmte Behebung auch in einem alternativen Format anfragen (Großdruck, Klartext-Mail, Rückruf), indem du an dieselbe Adresse schreibst. Wir brauchen keine dieser Angaben, um die Sache zu untersuchen; sie helfen nur, das Problem zu reproduzieren.

Die Frist ist freiwillig und wird hier veröffentlicht, damit sie prüfbar ist. Verpassen wir die 2-Tage-Bestätigung oder das 7-Tage-Ziel bei einem blockierenden Problem, ist das selbst ein dokumentiertes Versäumnis, und wir halten es auf dieser Seite fest. Gesetzliche Eskalations-Wege, zum Beispiel Beschwerden bei der UK Equality and Human Rights Commission, der US Department of Justice ADA Stelle oder deinem nationalen Äquivalent, bleiben verfügbar, egal wie wir die Meldung intern handhaben.

Wie sieht es mit der Screenreader-Unterstützung aus?

Wir testen mit NVDA und JAWS unter Windows, VoiceOver unter macOS und iOS sowie TalkBack unter Android. Überschriften, Landmarks und Listen werden korrekt vorgelesen. Formularfelder tragen sichtbare und programmatische Labels. Dekorative Icons nutzen leeres alt oder aria-hidden. Redaktionelle Bilder tragen Alt-Text, geschrieben von Redakteuren, nicht von Entwicklern, damit das alt die Absicht widerspiegelt.

Screenreader sehen nicht, was sehende Nutzer sehen; sie parsen den Dokumentbaum. Genau deshalb trägt semantisches HTML, nicht ARIA, das erste Gewicht der Barrierefreiheit hier. ARIA legen wir nur dort drauf, wo die native HTML-Semantik nicht reicht (Live-Regionen bei dynamischen Inhalten, Dialog-Rollen bei Modals, Expanded-States bei aufklappbaren Widgets), gemäß der ersten Regel von ARIA: Liefert ein natives Element die Semantik, nimm es. Die Screenreader-Abdeckung wird bei jedem größeren Release neu getestet, und wir behalten die Test-Mitschriften in der Akte.

Wie wird die Tastatur-Navigation unterstützt?

Jedes interaktive Element ist per Tastatur bedienbar. Ein Skip-to-Main-Content-Link ist das erste fokussierbare Element auf jeder Seite. Die Tab-Reihenfolge folgt der visuellen Leserichtung. Fokus-Anzeiger erreichen 3:1 Kontrast in hellem und dunklem Modus. Die mobile Schublade und das Sprach-Modal fangen den Fokus ein, wenn sie offen sind, und geben ihn beim Schließen zurück, sodass reine Tastatur-Nutzer nie stranden.

Der Tastatur-Vertrag ist die Oberfläche, die wir am härtesten testen, weil er stellvertretend für jede assistive Technik steht, die eine Tastatur emuliert, inklusive Switch-Geräte und Bildschirm-Tastaturen. Skip-Links erfüllen WCAG 2.4.1 Bypass Blocks, sichtbare Fokus-Anzeiger erfüllen WCAG 2.4.7 Focus Visible, und die Kein-Tastatur-Falle-Regel erfüllt WCAG 2.1.2. Das Fokus-Trap-Verhalten bei Modals folgt dem Dialog-Pattern des W3C ARIA Authoring Practices Guide, wobei der Fokus beim Schließen zum auslösenden Element zurückkehrt.

Welche Barrierefreiheits-Funktionen sind eingebaut?

Eingebaute Funktionen umfassen semantisches HTML (header, nav, main, footer, article, aside), strenge Überschriften-Hierarchie mit einer H1 pro Seite, beschreibenden Alt-Text bei redaktionellen Illustrationen, dekorative Bilder mit alt="", Tabellen-Beschriftungen mit zugeordneten Headern, Transkripte bei jedem eingebetteten Video, prefers-reduced-motion-Unterstützung und sichtbare Fokus-Anzeiger mit 3:1 Kontrast in hellem und dunklem Theme.

Das volle Funktions-Inventar, zugeordnet zu seinem zugrunde liegenden WCAG-Erfolgskriterium:

Wie wird Rechts-nach-links-Text behandelt?

Arabische (ar) und hebräische (he-IL) Seiten rendern in Rechts-nach-links-Layout über CSS Logical Properties (margin-inline-start, padding-inline-end) statt fester Links/Rechts-Werte. Jede Komponente, inklusive Header, Navigation, Call-to-Actions, Footer, mobiler Sticky-Bar und Modals, spiegelt korrekt. Wir haben das volle Chrome vor dem Launch an einer eigenen AR-Vorlage stresstestet und das Ergebnis in unserem Design-System dokumentiert.

Rechts-nach-links-Unterstützung ist keine Übersetzungs-Frage; sie ist eine Layout-Frage. Das dir-Attribut des Dokuments auf "rtl" zu schalten kippt Inline-Start und Inline-End über das ganze Layout, weil jeder Abstand, jede Ausrichtung und jeder Float in Logical Properties ausgedrückt ist. Bidirektionaler Inhalt (lateinische URLs in arabischer Prosa zum Beispiel) wird in HTML <bdi>-Elemente gewickelt, damit der Bidi-Algorithmus vorhersehbar rendert. Wir halten ein volles Rechts-nach-links-Audit auf einer eigenen arabischen Testseite und lassen es vor jedem Release neu laufen.

Wie hängt der Dunkelmodus mit Barrierefreiheit zusammen?

Der Dunkelmodus ist ein manueller Header-Schalter und respektiert beim ersten Besuch prefers-color-scheme. Der Fließtext bleibt in beiden Modi bei 4,5:1 oder höher; großer Text und UI-Komponenten bleiben über 3:1 (mit der dokumentierten Marken-Akzent-Ausnahme). Farbe ist nie der einzige Bedeutungsträger, sodass Nutzer mit Farbsehschwäche oder in monochromen Umgebungen beim Wechsel keine Information verlieren.

Zuletzt geprüft: 2026

Der Dunkelmodus läuft über ein data-theme="dark"-Attribut auf dem Wurzelelement des Dokuments und schaltet CSS Custom Properties an der Wurzel um. Der Schalter merkt sich die Nutzer-Wahl im localStorage, und hat der Nutzer nicht gewählt, folgen wir prefers-color-scheme. Beide Paletten werden unabhängig gegen die Kontrast-Mindestwerte von WCAG 1.4.3 und 1.4.11 geprüft. Der Dunkelmodus geht über Stil-Geschmack hinaus. Die Apple Human Interface Guidelines und die GOV.UK Barrierefreiheit erkennen ihn als Hilfe bei Photophobie, Migräne und Sehschwäche-Bedingungen an, sodass die Kontrast-Garantie in beide Richtungen gilt.

Werden Videos transkribiert?

Ja. Jedes eingebettete Video nutzt die youtube-nocookie.com-Domain und kommt mit einem schriftlichen Transkript auf der Seite unter dem Embed. Untertitel sind an der YouTube-Quelle aktiviert. Videos starten nicht automatisch, laufen nicht in Endlosschleife und bieten Pause- und Stopp-Steuerung. Wo Untertitel der Quelle fehlen, ergänzen wir vor der Veröffentlichung ein manuelles Transkript.

Transkripte sind hier nicht optional. Sie dienen gehörlosen und schwerhörigen Lesern (dem Publikum, für das sie geschrieben sind), Lesern in Umgebungen ohne Ton wie Arbeitsplatz und Bahn, Sprachlernern, die sich auf Text als Verstärkung des Audios stützen, und den Suchmaschinen und KI-Crawlern, die maschinenlesbaren Inhalt lesen können, den die Video-Pixel nicht offenlegen. Ein Artefakt, vier Erträge.

Wie geht ihr mit reduzierter Bewegung um?

Die Seite ehrt die CSS-Media-Query prefers-reduced-motion. Wenn ein Nutzer auf Betriebssystem-Ebene reduzierte Bewegung aktiviert hat, deaktivieren wir Parallax, automatisch scrollende Karussells, automatisch laufende Animationen und dekorative Übergänge. Wesentliche Interface-Bewegung (Fokus-Anzeiger, Dropdown-Einblendungen) bleibt erhalten, weil sie einen Zustand vermittelt. Nichts auf der Seite blinkt mehr als drei Mal pro Sekunde.

Die Drei-Blink-Schwelle erfüllt WCAG 2.3.1 Three Flashes or Below, das Kriterium zur Anfall-Vermeidung. Die Konformität mit reduzierter Bewegung adressiert vestibuläre Störungen, bewegungsbedingte Übelkeit und aufmerksamkeitsbezogene Bedürfnisse, dokumentiert in der Literatur der W3C Cognitive Accessibility Task Force. Die Umsetzung ist eine Media-Query, angewandt auf der Design-Token-Ebene; es braucht kein JavaScript, damit die Nutzer-Präferenz greift.

Wie oft testen wir?

Build-Zeit: axe-core läuft in der CI gegen jede Komponenten-Story und jeden Seiten-Snapshot. Builds scheitern bei schweren oder kritischen Verstößen. Vor dem Merge: Pull Requests tragen einen Lighthouse-Accessibility-Mindestwert von 95, und die GitHub Action blockiert Merges darunter. Manuelle Screenreader-Durchläufe (NVDA, JAWS, VoiceOver, TalkBack) laufen vierteljährlich auf einem repräsentativen Seitensatz und ad hoc bei jeder neuen Vorlage.

Das Testen ist geschichtet: automatisiert, wo das Werkzeug zuverlässig ist, manuell, wo Menschen noch das einzige Signal sind, das zählt.

  • Build-Zeit: axe-core läuft in der CI gegen jede Komponenten-Story und jeden Seiten-Snapshot. Builds scheitern bei schweren oder kritischen Verstößen.
  • Vor dem Merge: Pull Requests tragen einen Lighthouse-Accessibility-Mindestwert von 95, und die GitHub Action blockiert Merges darunter.
  • Manuelle Screenreader-Durchläufe: NVDA, JAWS, VoiceOver (macOS + iOS), TalkBack, vierteljährlich auf einem repräsentativen Seitensatz, ad hoc bei jeder neuen Vorlage.
  • Reiner Tastatur-Durchlauf: Jeder neue Seitentyp wird vor dem Merge von vorne bis hinten mit der Tastatur durchnavigiert, und das Test-Protokoll wird zur Änderung abgelegt.
  • Lese-Reihenfolge-Audit: Die Tab-Reihenfolge wird bei jeder Vorlage mit der visuellen Leserichtung verglichen.
  • Farbenblindheits-Simulation: Sim Daltonism und das Chrome-DevTools-Rendering-Panel simulieren Protanopie, Deuteranopie und Tritanopie auf jeder veröffentlichten Palette. Die Markenfarben-Kontrast-Ausnahme wird hier protokolliert.
  • Echtes Nutzer-Feedback: Jede an [email protected] gemeldete Hürde wird als Ticket abgelegt und öffentlich in der Tabelle der bekannten Probleme auf dieser Seite verfolgt.

Die Kombination folgt der GOV.UK Leitlinie zum Barrierefreiheits-Test: Automatisiertes Werkzeug fängt grob 30 bis 40 % der Probleme, und der Rest taucht erst auf, wenn Menschen assistive Technik unter realistischen Bedingungen nutzen.

Wie ist die Frist bei Barrierefreiheits-Beschwerden?

Wir bestätigen Barrierefreiheits-Beschwerden innerhalb von 2 Werktagen unter [email protected]. Bei blockierenden Hürden (eine Funktion ist mit assistiver Technik unbenutzbar) zielen wir auf Behebung innerhalb von 7 Werktagen. Nicht-blockierende Probleme bekommen ein dokumentiertes Ziel-Behebungsdatum und erscheinen im Log der bekannten Probleme, bis sie geschlossen sind. Gesetzliche Eskalationsrechte bleiben unter dieser freiwilligen Frist bestehen.

Die Frist ist freiwillig und wird hier veröffentlicht, damit sie prüfbar ist. Verpassen wir die 2-Tage-Bestätigung oder das 7-Tage-Ziel bei einem blockierenden Problem, ist das selbst ein dokumentiertes Versäumnis, und wir halten es auf dieser Seite fest. Gesetzliche Eskalations-Wege, zum Beispiel Beschwerden bei der UK Equality and Human Rights Commission, der US Department of Justice ADA Stelle oder deinem nationalen Äquivalent, bleiben verfügbar, egal wie wir die Meldung intern handhaben.

Wie geht der AI-Concierge-Chatbot mit Barrierefreiheit um?

Der AI-Concierge-Chatbot (vor Launch) geht erst live, wenn er ein volles WCAG 2.1 AA Audit besteht, das Tastatur-Bedienbarkeit, Screenreader-Ansagen (Live-Region für streamende Antworten), Fokus-Management beim Öffnen und Schließen des Panels und Konformität mit reduzierter Bewegung abdeckt. Bis dahin sind alle redaktionellen Inhalte ohne den Chatbot über die FAQ-Akkordeons auf der Seite erreichbar.

Konversationelle Interfaces fordern die Barrierefreiheit auf eine Weise heraus, wie statische Seiten es nicht tun. Streamender Text braucht höfliche ARIA-Live-Regionen, der Fokus muss vorhersehbar zwischen Auslöser, Panel und Schließen wandern, Tastatur-Nutzer brauchen einen dokumentierten Ausstieg, und Nutzer mit reduzierter Bewegung brauchen ihre Präferenz beim Panel-Übergang geehrt. Das Concierge-Audit folgt dem W3C ARIA APG Dialog-Pattern für das Panel-Verhalten und der WAI-ARIA Live-Region-Leitlinie für streamende Antworten. Die volle Audit-Mitschrift hängen wir an diese Seite an, wenn der Chatbot live geht.

Was sind Section 508 und der European Accessibility Act 2025?

Section 508 des US Rehabilitation Act (29 U.S.C. §794d, ICT Refresh 2018) verpflichtet Bundesbehörden und Bundesauftragnehmer, barrierefreie Informationstechnik zu beschaffen und zu pflegen, harmonisiert mit WCAG 2.0 AA über 36 CFR Part 1194. Der European Accessibility Act (Directive 2019/882, durchsetzbar ab 28. Juni 2025) weitet Barrierefreiheits-Pflichten auf eine breite Palette privatwirtschaftlicher Produkte und Dienste aus, ebenfalls harmonisiert auf WCAG 2.1 AA über EN 301 549.

Beide Regime laufen auf dasselbe technische Ziel zu. Deshalb erfüllt eine Konformitäts-Haltung beide, und deshalb wählen wir die höchste anwendbare Latte (WCAG 2.1 AA über EN 301 549 v3.2.1) und behandeln sie als Untergrenze auf jeder öffentlichen Seite, nicht nur auf den Oberflächen, die US-Bundesaufträge oder EU-Dienstpflichten berühren.

Das Durchsetzungs-Datum des EAA am 28. Juni 2025 zählt für private Verlage wie uns. Es ist der Moment, in dem die „Barrierefreiheits-Erklärung auf der Website" aufhört, eine Höflichkeit zu sein, und ein vom Regulierer prüfbares Artefakt wird, in den Mitgliedsstaaten, die die Richtlinie umgesetzt haben. Wir haben diese Erklärung gut vor dem Datum veröffentlicht, mit der einen dokumentierten Ausnahme von oben, weil wir das Gespräch über unseren Markenfarben-Kompromiss lieber jetzt führen, als später danach gefragt zu werden.

Diese Seite zitieren

Wenn du diese Erklärung in akademischer, regulatorischer oder journalistischer Arbeit referenzierst, zitiere bitte als:

Joly, A. (2026). Barrierefreiheits-Erklärung: WCAG 2.1 AA Ziele, Ausnahmen und Meldung für bestgirlfriend.ai. bestgirlfriend.ai. https://bestgirlfriend.ai/de/accessibility

Eine maschinenlesbare Zusammenfassung ist unter /llms.txt für die Aufnahme durch KI-Such-Crawler veröffentlicht.

Häufige Fragen

Zuletzt geprüft: 2026.

Ist bestgirlfriend.ai WCAG-konform?

Wir zielen auf die Web Content Accessibility Guidelines (WCAG) 2.1 Level AA auf jeder öffentlichen Seite. Wir erreichen das Ziel bei jedem Erfolgskriterium bis auf eine dokumentierte Ausnahme: Unsere Markenfarbe #E94B6A auf Creme #FAF7F2 ergibt einen Kontrast von 3,46:1, unter dem AA-Schwellenwert von 4,5:1 für Fließtext. Die Markenfarbe nutzen wir nur für Buttons, Badges und dekorative Akzente (behandelt als großer Text + UI gemäß WCAG 1.4.11), nie für Fließtext. Unsere Standard-Ausrichtung deckt US Section 508, EU EN 301 549, die UK Public Sector Bodies Accessibility Regulations 2018 und Ontario AODA ab.

Welchen Standards folgen wir?

WCAG 2.1 Level AA ist unser technisches Ziel. Darauf verweisen US Section 508 (ICT Refresh 2018), der harmonisierte EU-Standard EN 301 549 v3.2.1, die EU Web Accessibility Directive 2016/2102, der European Accessibility Act 2019/882 (durchsetzbar ab 28. Juni 2025), die UK Public Sector Bodies Accessibility Regulations 2018 und Ontario AODA mit seiner Integrated Accessibility Standards Regulation. Wir verfolgen die Erfolgskriterien von WCAG 2.2 als Vorwärtskompatibilität, unsere öffentliche Konformitäts-Aussage bleibt aber bei 2.1 AA, bis 2.2 in die regionalen Beschaffungsgesetze einzieht.

Welche bekannten Barrierefreiheits-Ausnahmen gibt es?

Zwei. (1) Markenfarben-Ausnahme: #E94B6A Koralle auf Creme #FAF7F2 ergibt 3,46:1, unter dem AA-Schwellenwert von 4,5:1 für Fließtext. Wir beschränken die Koralle auf Buttons, Badges, Links und dekorative Akzente (wo der 3:1-Schwellenwert für UI / großen Text gemäß WCAG 1.4.11 gilt), nie für Fließtext; der Kompromiss ist in unserem Design-System dokumentiert. (2) Einige Open-Graph-Teilbilder auf Listicle-Seiten haben keinen beschreibenden Alt-Text für Screenreader, wenn sie in Vorschauen von Drittanbieter-Plattformen auftauchen (kosmetisch; in Behebung). Der Chatbot geht erst live, wenn er ein volles Tastatur- und Screenreader-Audit besteht.

Wie melde ich ein Barrierefreiheits-Problem?

Schreib eine Mail an [email protected] mit der Seiten-URL, deinem Browser, deiner Version der assistiven Technik und einer kurzen Beschreibung der Hürde. Wir bestätigen jede Meldung innerhalb von 2 Werktagen. Bei blockierenden Hürden (eine Funktion ist mit assistiver Technik unbenutzbar) zielen wir auf Behebung innerhalb von 7 Werktagen. Nicht-blockierende Probleme bekommen ein dokumentiertes Ziel-Behebungsdatum und erscheinen in der Tabelle der bekannten Probleme auf dieser Seite, bis sie geschlossen sind. Gesetzliche Eskalationsrechte bleiben unabhängig von unserer internen Frist bestehen.

Wie sieht es mit der Screenreader-Unterstützung aus?

Wir testen mit NVDA unter Windows, JAWS unter Windows, VoiceOver unter macOS und iOS sowie TalkBack unter Android. Überschriften, Landmarks und Listen werden korrekt vorgelesen. Formularfelder tragen sichtbare und programmatische Labels. Dekorative Icons nutzen leeres alt oder aria-hidden. Redaktionelle Bilder tragen beschreibenden Alt-Text, geschrieben von Redakteuren, nicht von Entwicklern, damit das alt die Absicht widerspiegelt. Semantisches HTML ist unsere erste Verteidigungslinie; ARIA legen wir nur dort drauf, wo die native HTML-Semantik nicht reicht, gemäß der ersten Regel von ARIA.

Wie wird die Tastatur-Navigation unterstützt?

Jedes interaktive Element auf bestgirlfriend.ai ist per Tastatur bedienbar. Ein Skip-to-Main-Content-Link ist das erste fokussierbare Element auf jeder Seite. Die Tab-Reihenfolge folgt der visuellen Leserichtung. Fokus-Anzeiger haben mindestens 3:1 Kontrast in hellem und dunklem Modus. Die mobile Schublade und das Sprach-Modal fangen den Fokus ein, wenn sie offen sind, und geben ihn beim Schließen zurück, sodass reine Tastatur-Nutzer nie stranden. Das Fokus-Trap-Verhalten folgt dem Dialog-Pattern des W3C ARIA Authoring Practices Guide.

Wie wird Rechts-nach-links-Text behandelt?

Arabische (ar) und hebräische (he-IL) Seiten rendern in Rechts-nach-links-Layout über CSS Logical Properties (margin-inline-start, padding-inline-end) statt fester Links/Rechts-Werte. Jede Komponente, inklusive Header, Navigation, Call-to-Actions, Footer, mobiler Sticky-Bar und Modals, spiegelt korrekt. Wir haben das volle Chrome vor dem Launch an einer eigenen AR-Vorlage stresstestet und das Ergebnis in unserem Design-System dokumentiert.

Wie hängt der Dunkelmodus mit Barrierefreiheit zusammen?

Der Dunkelmodus ist ein manueller Schalter im Header und respektiert beim ersten Besuch die System-Einstellung prefers-color-scheme. Der Kontrast des Fließtexts bleibt in beiden Modi bei 4,5:1 oder höher für die Prosa-Oberfläche. Farbe ist nie der einzige Bedeutungsträger, sodass Nutzer mit Farbsehschwäche oder in monochromen Umgebungen beim Wechsel keine Information verlieren. Die Kontrast-Ausnahme für den korallenen Markenakzent gilt in beiden Modi.

Werden Videos transkribiert?

Ja. Jedes auf bestgirlfriend.ai eingebettete Video nutzt die youtube-nocookie-Domain und kommt mit einem schriftlichen Transkript, direkt auf der Seite unter dem Embed veröffentlicht. Untertitel sind an der YouTube-Quelle aktiviert. Videos starten nicht automatisch, laufen nicht in Endlosschleife und bieten Pause- und Stopp-Steuerung. Wo Untertitel aus der Originalquelle fehlen, ergänzen wir vor der Veröffentlichung ein manuelles Transkript.

Wie geht ihr mit reduzierter Bewegung um?

Die Seite ehrt die CSS-Media-Query prefers-reduced-motion. Wenn ein Nutzer auf Betriebssystem-Ebene reduzierte Bewegung aktiviert hat, deaktivieren wir Parallax, automatisch scrollende Karussells, automatisch laufende Animationen und dekorative Übergänge. Wesentliche Interface-Bewegung (Fokus-Anzeiger, Dropdown-Einblendungen) bleibt erhalten, weil sie einen Zustand vermittelt. Nichts auf der Seite blinkt mehr als drei Mal pro Sekunde, was das Kriterium zur Anfall-Vermeidung erfüllt.

Wie oft testen wir?

axe-core läuft in der CI gegen jede Komponenten-Story und jeden Seiten-Snapshot; Builds scheitern bei schweren oder kritischen Verstößen. Pull Requests tragen einen Lighthouse-Accessibility-Mindestwert von 95, und die GitHub Action blockiert Merges darunter. Manuelle Screenreader-Durchläufe mit NVDA, JAWS, VoiceOver und TalkBack laufen vierteljährlich auf einem repräsentativen Seitensatz und ad hoc bei jeder neuen Vorlage. Jede neue Vorlage wird vor dem Merge von vorne bis hinten per Tastatur durchnavigiert.

Wie ist die Frist bei Barrierefreiheits-Beschwerden?

Wir bestätigen Barrierefreiheits-Beschwerden innerhalb von 2 Werktagen unter [email protected]. Bei blockierenden Hürden (eine Funktion ist mit assistiver Technik unbenutzbar) zielen wir auf Behebung innerhalb von 7 Werktagen. Nicht-blockierende Probleme bekommen ein dokumentiertes Ziel-Behebungsdatum und erscheinen im Log der bekannten Probleme, bis sie geschlossen sind. EU- und UK-Leser behalten ihre gesetzlichen Eskalationsrechte, egal wie wir die Meldung intern handhaben.

Wie geht der AI-Concierge-Chatbot mit Barrierefreiheit um?

Der AI-Concierge-Chatbot (vor Launch) geht erst live, wenn er ein volles WCAG 2.1 AA Audit besteht, das Tastatur-Bedienbarkeit, Screenreader-Ansagen (Live-Region für streamende Antworten), Fokus-Management beim Öffnen und Schließen des Panels und Konformität mit reduzierter Bewegung abdeckt. Bis dahin sind alle redaktionellen Inhalte ohne den Chatbot erreichbar, und gleichwertige Antworten gibt es über die FAQ-Akkordeons auf der Seite. Das Audit folgt dem W3C ARIA APG Dialog-Pattern für das Panel-Verhalten und der WAI-ARIA-Live-Region-Leitlinie für streamende Antworten.

Was sind Section 508 und der European Accessibility Act 2025?

Section 508 des US Rehabilitation Act (29 U.S.C. §794d, ICT Refresh 2018) verpflichtet Bundesbehörden und Bundesauftragnehmer, barrierefreie Informationstechnik zu beschaffen und zu pflegen, harmonisiert mit WCAG 2.0 AA über 36 CFR Part 1194. Der European Accessibility Act (Directive 2019/882, durchsetzbar ab 28. Juni 2025) weitet Barrierefreiheits-Pflichten auf eine breite Palette privatwirtschaftlicher Produkte und Dienste aus, ebenfalls harmonisiert auf WCAG 2.1 AA über EN 301 549. Beide Regime laufen auf dasselbe technische Ziel zu, weshalb eine Konformitäts-Haltung beide erfüllt.

Quellen

Die auf dieser Seite zitierten Standards, Gesetze und Leitlinien sind unten in der Reihenfolge ihres Auftretens aufgeführt, mit stabilen URLs. Neu geprüft 2026.

Verwandte redaktionelle Vertrauensseiten

Hinweis je nach Jurisdiktion

Zuletzt geprüft 2026 · Siehe Korrektur-Log für nachträgliche Korrekturen · Redakteurin: Alexandra Joly · Methodik · Redaktioneller Prozess · Affiliate-Hinweis

Barrierefreiheit 2026: WCAG 2.1 AA, Ziele + Ausnahmen