bestgirlfriend.ai
Best Match Quiz
Editorial

Accessibility Statement: WCAG 2.1 AA Targets + Exceptions

Plain-English accessibility statement: WCAG 2.1 AA target, axe-core + Lighthouse pipeline, one brand-color exception documented. Report a barrier.

By Last revised May 2026

Most accessibility statements in this space either lie outright ("100% WCAG AA compliant!") or paste a generic boilerplate that buries every known exception behind a smokescreen of conformance jargon. This one is shorter, organized around what you actually need to know, and frank about the one documented exception we accept. I wrote it the way I'd want it written if I were the reader.

bestgirlfriend.ai is an editorial comparator covering AI girlfriend apps, AI boyfriend apps, cam sites, real-model creators, and adult games. Accessibility is part of the editorial baseline, not a feature retrofitted at launch. This page documents the standards we build to, the techniques we use, the one exception we accept and why, the gaps we still owe, and the channel for reporting a barrier.

This statement aligns with the U.S. Section 508 refresh (29 U.S.C. §794d, harmonized with WCAG 2.0 AA via the 2018 ICT Refresh), the EU harmonized standard EN 301 549 v3.2.1 (referenced by the Web Accessibility Directive 2016/2102 and the European Accessibility Act 2019/882, enforceable from 28 June 2025), the UK Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, and the Accessibility for Ontarians with Disabilities Act, 2005 and its Integrated Accessibility Standards Regulation. We are a private publisher, not a public-sector body, but we hold ourselves to the same conformance level because the legal floor is the right starting line.

Is bestgirlfriend.ai WCAG-compliant?

We target WCAG 2.1 Level AA across every public page and meet the target on every success criterion except one documented exception: brand color #E94B6A on cream #FAF7F2 produces 3.46:1 contrast, below the 4.5:1 AA body-text floor. The coral is restricted to buttons, badges, links, and decorative accents (the 3:1 surface under WCAG 1.4.11), never used for body prose. Every other success criterion is met, and the exception is logged with its measurements in our design system.

Last reviewed: 2026

Conformance is something you keep doing, not a box you tick once. The site is engineered to WCAG 2.1 AA, the four principles (perceivable, operable, understandable, robust) are built into how the pages are designed, and every commit passes automated checks before it merges. The one trade-off we accept is the brand-color contrast on the coral accent, and we say so up front instead of hiding it in a partial-conformance footnote at the bottom of the page. The rest of this page documents what that means concretely.

What standards do we follow?

WCAG 2.1 Level AA is our engineering target. It is referenced by U.S. Section 508 (ICT Refresh 2018), the EU harmonized standard EN 301 549 v3.2.1, the EU Web Accessibility Directive 2016/2102, the European Accessibility Act 2019/882 (enforceable from 28 June 2025), the UK Public Sector Bodies Accessibility Regulations 2018, and Ontario AODA Integrated Accessibility Standards Regulation.

WCAG 2.1 AA is the global lingua franca of digital accessibility [Source: W3C, Web Content Accessibility Guidelines 2.1, W3C Recommendation 05 June 2018 · verified 2026-05-26]. Section 508 references it via the U.S. ICT Refresh [Source: U.S. Section 508, ICT Refresh standards · verified 2026-05-26]. EN 301 549 references it as the harmonized European standard [Source: ETSI EN 301 549, accessibility requirements for ICT products and services · verified 2026-05-26]. The UK 2018 regulations name it explicitly. AODA references it through the Integrated Accessibility Standards Regulation.

Picking AA means we satisfy all five regimes from one engineering target. We watch WCAG 2.2 (published October 2023) and fold in its success criteria where they don't conflict with 2.1. We'll move our public conformance claim to 2.2 AA once the procurement standards in our key markets cite it.

The standards landscape converges on WCAG 2.1 AA as the testable engineering target. The five regimes that govern our markets, each linked to the canonical reference:

StandardRegionCompliance levelOur statusReference
WCAG 2.1 AAGlobal (W3C)Level AATargeted (1 documented exception)W3C Recommendation, 5 June 2018
EN 301 549 v3.2.1European UnionHarmonized standard, AATargeted (1 documented exception)ETSI, March 2021; referenced by WAD 2016/2102 and EAA 2019/882
Section 508 (ICT Refresh)United StatesWCAG 2.0 AA harmonized; AATargeted (with WCAG 2.1 AA delta, 1 documented exception)36 CFR Part 1194, U.S. Access Board 2018
UK Public Sector Bodies Accessibility Regulations 2018United KingdomWCAG 2.1 AATargeted (private publisher; voluntary)SI 2018/952
AODA / IASROntario, CanadaWCAG 2.0 AA (IASR §14)Targeted (with WCAG 2.1 AA delta, 1 documented exception)O. Reg. 191/11, Integrated Accessibility Standards
Last reviewed: 2026.

What are the known accessibility exceptions?

Two. (1) Brand-color contrast exception: #E94B6A coral on cream #FAF7F2 produces 3.46:1, below the WCAG AA 4.5:1 floor for body text. The coral is restricted to buttons, badges, links, and decorative accents (the 3:1 surface under WCAG 1.4.11), never used for body prose. (2) Open Graph share images on some listicle pages lack descriptive alt for screen readers when surfaced inside third-party social previews (cosmetic; in remediation). The AI Concierge chatbot has not yet completed its full audit and will not ship until it does.

Listing known exceptions in public is the honest counterpart to a conformance claim. WCAG conformance is binary at the success-criterion level: a page either meets the criterion or it does not. We do not blend a partial-conformance disclaimer into the body of the page; the exceptions live here, in plain language, with their rationale and remediation status.

The brand-color exception, in detail. Our primary accent color (#E94B6A, the coral on buttons and badges) on our editorial background (#FAF7F2, the warm cream) produces a contrast ratio of 3.46:1. WCAG 2.1 AA requires 4.5:1 for normal body text (SC 1.4.3) and 3:1 for large text and for UI components and graphical objects (SC 1.4.11). The 3.46:1 ratio satisfies the 3:1 floor for the UI / large-text surface and falls short of the 4.5:1 floor for body prose.

We made the call to accept the trade-off for the brand-accent surface only. The coral appears on call-to-action buttons, link underlines, badges, the sticky promo bar, and decorative accents, all surfaces where the 3:1 floor applies. Body prose, headings, and all other text use #1A1A1A near-black on the cream, which clears 4.5:1 comfortably. The decision is documented in our design system alongside the contrast measurements, so the trade-off is reviewable rather than invisible.

Most review sites in this space don't surface this kind of brand trade-off at all. They claim full AA compliance, and the audit never catches the accent-color shortfall because the audit was never run. We run the audit, log the result, and tell you about it. That's the difference between a real accessibility statement and a copy-pasted boilerplate.

Open issues:

IDIssueSeverityStatusTarget fix
A11Y-001Brand color (#E94B6A) on cream (#FAF7F2) = 3.46:1, below AA body-text 4.5:1 floorAccepted exception (UI/accent only; body prose unaffected)Documented in design tokensNo fix planned without brand-color change
A11Y-002Open Graph image alt text on listicle social previewsCosmetic (does not affect on-site reading)In remediationQ3 2026
A11Y-003AI Concierge chatbot full WCAG 2.1 AA auditBlocking (chatbot will not ship until cleared)Audit pending pre-shipPre-ship

If you encounter an issue not on this list, please report it. The list is updated whenever a new issue is discovered or an existing one is closed.

How do I report an accessibility issue?

Email [email protected] with the page URL, your browser and assistive technology, and a short description of the barrier. We acknowledge every report within 2 business days and target resolution or a workaround within 7 business days for blocking issues. Issues that cannot meet the 7-day target receive a public interim mitigation plus a target fix date in the Known Issues log on this page.

The dedicated mailbox is [email protected]. To help us reproduce and fix faster, please include where possible:

  • The page URL where you encountered the barrier.
  • Your operating system and browser (and version).
  • The assistive technology you used (screen reader, switch, magnifier, voice control, etc.) and its version.
  • A short description of what you expected and what happened instead.
  • A screenshot or screen recording, if available and you are comfortable sharing one.

You can also request this statement, an audit summary, or a specific fix in an alternative format (large print, plain-text email, a phone callback) by writing to the same address. We do not require any of this metadata to investigate; it just helps us reproduce the issue.

The SLA is voluntary and is published here so that it is checkable. If we miss the 2-day acknowledgment or the 7-day target on a blocking issue, that is itself a documented failure and we will document it on this page. Statutory escalation routes, for example, complaints to the UK Equality and Human Rights Commission, the U.S. Department of Justice ADA line, or your national equivalent, are available regardless of how we handle the report internally.

What about screen reader support?

We test with NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. Headings, landmarks, and lists are announced correctly. Form fields carry both visible and programmatic labels. Decorative icons use empty alt or aria-hidden. Editorial images carry alt text written by editors, not developers, so the alt reflects intent.

Screen readers don't see what sighted users see; they parse the document tree. That's why semantic HTML, rather than ARIA, carries the first weight of accessibility here. We layer ARIA on only where native HTML semantics fall short (live regions on dynamic content, dialog roles on modals, expanded states on disclosure widgets), per the first rule of ARIA: if a native element provides the semantic, use it. Screen-reader coverage is re-tested at each major release, and we keep the test transcripts on file.

How is keyboard navigation supported?

Every interactive element is keyboard-operable. A skip-to-main-content link is the first focusable item on every page. Tab order follows visual reading order. Focus indicators meet 3:1 contrast in light and dark modes. The mobile drawer and language modal trap focus when open and restore it on close, so keyboard-only users are never stranded.

The keyboard contract is the surface we test hardest, because it stands in for every assistive technology that emulates a keyboard, including switch devices and on-screen keyboards. Skip links satisfy WCAG 2.4.1 Bypass Blocks, visible focus indicators satisfy WCAG 2.4.7 Focus Visible, and the no-keyboard-trap rule satisfies WCAG 2.1.2. Focus-trap behavior on modals follows the W3C ARIA Authoring Practices Guide dialog pattern, with focus restored to the triggering element on close.

What accessibility features are built in?

Built-in features include semantic HTML (header, nav, main, footer, article, aside), strict heading hierarchy with one H1 per page, descriptive alt text on editorial illustrations, decorative images marked with alt="", table captions with scoped headers, transcripts on every embedded video, prefers-reduced-motion support, and visible focus indicators meeting 3:1 contrast across light and dark themes.

The full feature inventory, mapped to its underlying WCAG success criterion:

How is right-to-left text handled?

Arabic (ar) and Hebrew (he-IL) pages render in right-to-left layout via CSS logical properties (margin-inline-start, padding-inline-end) rather than fixed left/right values. Every component, including the header, navigation, calls-to-action, footer, sticky mobile bar, and modals, mirrors correctly. We stress-tested the full chrome on a dedicated AR template before launch and documented the result in our design system.

Right-to-left support isn't a translation concern; it's a layout concern. Switching the document's dir attribute to "rtl" flips inline-start and inline-end across the entire layout because every spacing, alignment, and float is expressed in logical properties. Bidirectional content (Latin URLs inside Arabic prose, for instance) is wrapped in HTML <bdi> elements so the bidirectional algorithm renders predictably. We keep a full right-to-left audit on a dedicated Arabic test page and re-run it before each release.

How does dark mode interact with accessibility?

Dark mode is a manual header toggle and respects prefers-color-scheme on first visit. Body text remains 4.5:1 or higher in both modes; large text and UI components stay above 3:1 (with the documented brand-accent exception). Color is never the sole carrier of meaning, so users with color-vision deficiency or in monochrome environments lose no information when switching modes.

Last reviewed: 2026

Dark mode is implemented via a data-theme="dark" attribute on the document root element, switching CSS custom properties at the root. The toggle persists user choice in localStorage, and if the user hasn't chosen, we follow prefers-color-scheme. Both palettes are independently audited against WCAG 1.4.3 and 1.4.11 contrast minima. Dark mode goes beyond styling taste. The Apple Human Interface Guidelines and GOV.UK accessibility recognize it as an accommodation for photophobia, migraine, and low-vision conditions, so the contrast guarantee applies in both directions.

Are videos transcribed?

Yes. Every embedded video uses the youtube-nocookie.com domain and ships with a written transcript on the page below the embed. Captions are enabled on the YouTube source. Videos do not auto-play, do not auto-loop, and offer pause and stop controls. Where source captions are missing, we add a manual transcript pre-publication.

Transcripts aren't optional here. They serve deaf and hard-of-hearing readers (the audience they're written for), readers in sound-off environments like workplaces and transit, language learners who lean on text reinforcing audio, and the search engines and AI crawlers that can read machine-readable content the video pixels can't expose. One artifact, four returns.

How do you handle reduced motion?

The site honors the prefers-reduced-motion CSS media query. When a user has reduced motion enabled at the operating-system level, we disable parallax, auto-scrolling carousels, auto-playing animations, and decorative transitions. Essential interface motion (focus indicators, dropdown reveals) is preserved because it conveys state. Nothing on the site flashes more than three times per second.

The three-flash threshold satisfies WCAG 2.3.1 Three Flashes or Below, the seizure-prevention criterion. Reduced-motion compliance addresses vestibular disorders, motion-induced nausea, and attention-related accessibility needs documented in the W3C Cognitive Accessibility task force literature. The implementation is one media query, applied at the design-token layer; no JavaScript is required for the user preference to take effect.

How often do we test?

Build-time: axe-core runs against every component story and every page snapshot in CI. Builds fail on serious or critical violations. Pre-merge: pull requests carry a Lighthouse Accessibility score floor of 95 and the GitHub Action blocks merges below that. Manual screen-reader passes (NVDA, JAWS, VoiceOver, TalkBack) run quarterly on a representative page set and ad-hoc on any new template.

Testing is layered: automated where the tooling is reliable, manual where humans are still the only signal that matters.

  • Build-time: axe-core runs against every component story and every page snapshot in CI. Builds fail on serious or critical violations.
  • Pre-merge: pull requests carry a Lighthouse Accessibility score floor of 95 and the GitHub Action blocks merges below that.
  • Manual screen-reader passes: NVDA, JAWS, VoiceOver (macOS + iOS), TalkBack, quarterly on a representative page set, ad-hoc on any new template.
  • Keyboard-only pass: every new page type is navigated end-to-end with a keyboard before merge, and the test record is filed alongside the change.
  • Reading-order audit: tab order is compared to visual reading order on every template.
  • Color-blindness simulation: Sim Daltonism and the Chrome DevTools rendering pane simulate protanopia, deuteranopia, and tritanopia on every published palette. The brand-color contrast exception is logged here.
  • Real-user feedback: every barrier reported to [email protected] is filed as a ticket and tracked publicly in the Known Issues table on this page.

The combination follows the GOV.UK accessibility testing guidance: automated tooling catches roughly 30 to 40% of issues, and the rest only turns up when humans use assistive technology under realistic conditions.

What is the SLA on accessibility complaints?

We acknowledge accessibility complaints within 2 business days at [email protected]. Blocking barriers (a feature unusable with assistive technology) target resolution within 7 business days. Non-blocking issues receive a documented target fix date and appear in the Known Issues log until closed. Statutory escalation rights remain available below this voluntary SLA.

The SLA is voluntary and is published here so that it is checkable. If we miss the 2-day acknowledgment or the 7-day target on a blocking issue, that is itself a documented failure and we will document it on this page. Statutory escalation routes, for example, complaints to the UK Equality and Human Rights Commission, the U.S. Department of Justice ADA line, or your national equivalent, are available regardless of how we handle the report internally.

How does the AI Concierge chatbot handle accessibility?

The AI Concierge chatbot (pre-ship) will not ship until it passes a full WCAG 2.1 AA audit covering keyboard operability, screen-reader announcements (live region for streaming responses), focus management on panel open and close, and reduced-motion compliance. Until then, all editorial content is reachable without the chatbot via on-page FAQ accordions.

Conversational interfaces stress-test accessibility in ways static pages don't. Streaming text needs polite ARIA live regions, focus has to move predictably between the trigger, the panel, and the dismissal, keyboard users need a documented escape, and reduced-motion users need their preferences honored on the panel transition. The Concierge audit will follow the W3C ARIA APG dialog pattern for panel behavior and the WAI-ARIA live-region guidance for streaming responses. We'll append the full audit transcript to this page when the chatbot ships.

What is Section 508 and the European Accessibility Act 2025?

Section 508 of the U.S. Rehabilitation Act (29 U.S.C. §794d, ICT Refresh 2018) requires federal agencies and federal contractors to procure and maintain accessible information technology, harmonized with WCAG 2.0 AA via 36 CFR Part 1194. The European Accessibility Act (Directive 2019/882, enforceable from 28 June 2025) extends accessibility duties to a wide range of private-sector products and services, also harmonized to WCAG 2.1 AA via EN 301 549.

Both regimes converge on the same engineering target. That's why one conformance posture satisfies both, and why we pick the highest applicable bar (WCAG 2.1 AA via EN 301 549 v3.2.1) and treat it as the floor across every public page on the site, not just the surfaces touched by U.S. federal contracts or EU service obligations.

The EAA's 28 June 2025 enforcement date matters for private publishers like us. It's the moment when "accessibility statement on the website" stops being a courtesy and becomes a regulator-checkable artifact in member states that have transposed the directive. We published this statement well ahead of that date, with the one documented exception above, because we'd rather have the conversation about our brand-color trade-off now than be asked about it later.

Cite this page

If you reference this statement in academic, regulatory, or journalistic work, please cite as:

Joly, A. (2026). Accessibility Statement: WCAG 2.1 AA Targets, Exceptions, and Reporting for bestgirlfriend.ai. bestgirlfriend.ai. https://bestgirlfriend.ai/accessibility

A machine-readable summary is published at /llms.txt for AI search crawler ingestion.

Frequently asked questions

Last reviewed: 2026.

Is bestgirlfriend.ai WCAG-compliant?

We target Web Content Accessibility Guidelines (WCAG) 2.1 Level AA on every public page. We meet the target on every success criterion except one documented exception: our brand color #E94B6A on cream #FAF7F2 yields a 3.46:1 contrast ratio, below the AA 4.5:1 floor for body text. We use the brand color only for buttons, badges, and decorative accents (treated as large text + UI under WCAG 1.4.11), never for body prose. Our standards alignment maps to U.S. Section 508, EU EN 301 549, the UK Public Sector Bodies Accessibility Regulations 2018, and Ontario AODA.

What standards do we follow?

WCAG 2.1 Level AA is our engineering target. It is referenced by U.S. Section 508 (ICT Refresh 2018), the EU harmonized standard EN 301 549 v3.2.1, the EU Web Accessibility Directive 2016/2102, the European Accessibility Act 2019/882 (enforceable from 28 June 2025), the UK Public Sector Bodies Accessibility Regulations 2018, and Ontario AODA's Integrated Accessibility Standards Regulation. We track WCAG 2.2 success criteria as a forward-compatibility goal but our public conformance claim stays at 2.1 AA until 2.2 enters regional procurement laws.

What are the known accessibility exceptions?

Two. (1) Brand color exception: #E94B6A coral on cream #FAF7F2 yields 3.46:1, below the 4.5:1 AA body-text floor. We restrict the coral to buttons, badges, links, and decorative accents (where the 3:1 UI / large-text floor applies per WCAG 1.4.11), never for body prose; the trade-off is documented in our design system. (2) Some Open Graph share images on listicle pages lack descriptive alt for screen readers when surfaced inside third-party social previews (cosmetic; in remediation). The chatbot will not ship until it passes a full keyboard-and-screen-reader audit.

How do I report an accessibility issue?

Email [email protected] with the page URL, your browser and assistive technology version, and a short description of the barrier. We acknowledge every report within 2 business days. Blocking barriers (a feature is unusable with assistive technology) target resolution within 7 business days. Non-blocking issues receive a documented target fix date and appear in the Known Issues table on this page until closed. Statutory escalation rights remain available regardless of our internal SLA.

What about screen reader support?

We test with NVDA on Windows, JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. Headings, landmarks, and lists are announced correctly. Form fields carry both visible and programmatic labels. Decorative icons use empty alt or aria-hidden. Editorial images carry descriptive alt text written by editors, not developers, so the alt reflects intent. Semantic HTML is our first line of defense; ARIA is layered only where native HTML semantics are insufficient, per the first rule of ARIA.

How is keyboard navigation supported?

Every interactive element on bestgirlfriend.ai is keyboard-operable. A skip-to-main-content link is the first focusable item on every page. Tab order follows the visual reading order. Focus indicators have at least 3:1 contrast in both light and dark modes. The mobile drawer and language modal trap focus when open and restore it on close, so keyboard-only users are never stranded. Focus-trap behavior follows the W3C ARIA Authoring Practices Guide dialog pattern.

How is right-to-left text handled?

Arabic (ar) and Hebrew (he-IL) pages render in right-to-left layout via CSS logical properties (margin-inline-start, padding-inline-end) rather than fixed left/right values. Every component, including the header, navigation, calls-to-action, footer, sticky mobile bar, and modals, mirrors correctly. We stress-tested the full chrome on a dedicated AR template before launch and documented the result in our design system.

How does dark mode interact with accessibility?

Dark mode is offered as a manual toggle in the header and respects the user's prefers-color-scheme system preference on first visit. Body text contrast remains 4.5:1 or higher in both modes for the prose surface. Color is never the sole carrier of meaning, so users with color-vision deficiency or in monochrome environments lose no information when switching modes. The contrast exception for the coral brand accent applies in both modes.

Are videos transcribed?

Yes. Every video embedded on bestgirlfriend.ai uses the youtube-nocookie domain and ships with a written transcript published directly on the page below the embed. Captions are enabled on the YouTube source. Videos do not auto-play, do not auto-loop, and offer pause and stop controls. Where captions are not available from the original source, we add a manual transcript before publication.

How do you handle reduced motion?

The site honors the prefers-reduced-motion CSS media query. When a user has reduced motion enabled at the operating-system level, we disable parallax, auto-scrolling carousels, auto-playing animations, and decorative transitions. Essential interface motion (focus indicators, dropdown reveals) is preserved because it conveys state. Nothing on the site flashes more than three times per second, satisfying the seizure-prevention criterion.

How often do we test?

axe-core runs against every component story and every page snapshot in CI; builds fail on serious or critical violations. Pull requests carry a Lighthouse Accessibility score floor of 95 and the GitHub Action blocks merges below that. Manual screen-reader passes on NVDA, JAWS, VoiceOver, and TalkBack run quarterly on a representative page set and ad-hoc on any new template. Every new template is keyboard-navigated end-to-end before merge.

What is the SLA on accessibility complaints?

We acknowledge accessibility complaints within 2 business days at [email protected]. Blocking barriers (a feature unusable with assistive technology) target resolution within 7 business days. Non-blocking issues receive a documented target fix date and appear in the Known Issues log until closed. EU and UK readers retain their statutory escalation rights regardless of how we handle the report internally.

How does the AI Concierge chatbot handle accessibility?

The AI Concierge chatbot (pre-ship) will not ship until it passes a full WCAG 2.1 AA audit covering keyboard operability, screen-reader announcements (live region for streaming responses), focus management when the panel opens and closes, and reduced-motion compliance. Until then, all editorial content is accessible without the chatbot, and equivalent answers are reachable via the on-page FAQ accordions. The audit will follow the W3C ARIA APG dialog pattern for panel behavior and the WAI-ARIA live-region guidance for streaming responses.

What is Section 508 and the European Accessibility Act 2025?

Section 508 of the U.S. Rehabilitation Act (29 U.S.C. §794d, ICT Refresh 2018) requires federal agencies and federal contractors to procure and maintain accessible information technology, harmonized with WCAG 2.0 AA via 36 CFR Part 1194. The European Accessibility Act (Directive 2019/882, enforceable from 28 June 2025) extends accessibility duties to a wide range of private-sector products and services, also harmonized to WCAG 2.1 AA via EN 301 549. Both regimes converge on the same engineering target, which is why one conformance posture satisfies both.

Sources

The standards, statutes, and guidelines cited on this page are listed below in the order they appear, with stable URLs. Re-verified 2026.

Per-jurisdiction notice

Last verified 2026 · See errata log for any post-publish corrections · Editor: Alexandra Joly · Methodology · Editorial process · Affiliate disclosure

Accessibility Statement: WCAG 2.1 AA Targets + Exceptions