Déclaration d'accessibilité : objectifs WCAG 2.1 AA + exceptions (2026)

La plupart des déclarations d'accessibilité dans ce secteur, soit elles mentent franchement (« 100 % conforme WCAG AA ! »), soit elles collent un texte passe-partout qui noie chaque exception connue derrière un écran de fumée de jargon de conformité. Celle-ci est plus courte, organisée autour de ce qu'il te faut vraiment savoir, et franche sur la seule exception documentée qu'on accepte. Je l'ai écrite comme j'aimerais qu'on me l'écrive si j'étais à ta place.

bestgirlfriend.ai est un comparateur éditorial qui couvre les applications de petite amie IA, de petit ami IA, les sites de cam, les créateurs et créatrices en vrai, et les jeux pour adultes. L'accessibilité fait partie du socle éditorial, c'est pas une fonctionnalité rajoutée au lancement. Cette page documente les standards qu'on respecte, les techniques qu'on utilise, la seule exception qu'on accepte et pourquoi, les écarts qu'on doit encore combler, et le canal pour signaler un obstacle.

Cette déclaration s'aligne sur le Section 508 américain (29 U.S.C. §794d, harmonisé avec WCAG 2.0 AA via l'ICT Refresh 2018), le standard harmonisé européen EN 301 549 v3.2.1 (référencé par la directive sur l'accessibilité du web 2016/2102 et le European Accessibility Act 2019/882, applicable depuis le 28 juin 2025), les Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 britanniques, et l'Accessibility for Ontarians with Disabilities Act, 2005 et son Integrated Accessibility Standards Regulation. On est un éditeur privé, pas un organisme public, mais on se tient au même niveau de conformité parce que le plancher légal est la bonne ligne de départ.

bestgirlfriend.ai est-il conforme WCAG ?

Dernière revue : 2026

La conformité, c'est un truc qu'on continue de faire, pas une case qu'on coche une fois. Le site est conçu pour le WCAG 2.1 AA, les quatre principes (perceptible, utilisable, compréhensible, robuste) sont intégrés à la façon dont les pages sont pensées, et chaque commit passe les vérifications automatiques avant de fusionner. Le seul compromis qu'on accepte, c'est le contraste de la couleur de marque sur l'accent corail, et on le dit d'entrée au lieu de le planquer dans une note de conformité partielle en bas de page. Le reste de cette page documente ce que ça veut dire concrètement.

Quels standards on suit ?

Le WCAG 2.1 AA, c'est la langue commune mondiale de l'accessibilité numérique [Source: W3C, Web Content Accessibility Guidelines 2.1, Recommandation W3C du 5 juin 2018 · verified 2026-06-04]. Le Section 508 y renvoie via l'ICT Refresh américain [Source: Section 508 américain, standards ICT Refresh · verified 2026-06-04]. L'EN 301 549 y renvoie comme standard harmonisé européen [Source: ETSI EN 301 549, exigences d'accessibilité pour les produits et services TIC · verified 2026-06-04]. Les textes britanniques de 2018 le nomment explicitement. L'AODA y renvoie via l'Integrated Accessibility Standards Regulation.

Choisir le AA, ça veut dire qu'on satisfait les cinq régimes à partir d'une seule cible technique. On surveille le WCAG 2.2 (publié en octobre 2023) et on en intègre les critères de succès là où ils n'entrent pas en conflit avec la 2.1. On passera notre déclaration de conformité publique en 2.2 AA dès que les standards de marchés publics de nos marchés clés le citeront.

Le paysage des standards converge sur le WCAG 2.1 AA comme cible technique vérifiable. Les cinq régimes qui régissent nos marchés, chacun relié à sa référence officielle :

Dernière revue : 2026.

Quelles sont les exceptions d'accessibilité connues ?

Lister les exceptions connues en public, c'est le pendant honnête d'une déclaration de conformité. La conformité WCAG est binaire au niveau du critère de succès : une page tient le critère, ou pas. On ne fond pas une note de conformité partielle dans le corps de la page ; les exceptions vivent ici, en clair, avec leur justification et leur statut de correction.

L'exception de couleur de marque, en détail. Notre couleur d'accent principale (#E94B6A, le corail des boutons et badges) sur notre fond éditorial (#FAF7F2, le crème chaud) donne un rapport de contraste de 3,46:1. Le WCAG 2.1 AA exige 4,5:1 pour le texte courant normal (CS 1.4.3) et 3:1 pour le texte large et pour les composants d'interface et objets graphiques (CS 1.4.11). Le rapport de 3,46:1 satisfait le plancher 3:1 pour la surface UI / texte large et reste sous le plancher 4,5:1 pour la prose.

On a fait le choix d'accepter le compromis pour la surface d'accent de marque uniquement. Le corail apparaît sur les boutons d'appel à l'action, les soulignements de liens, les badges, la barre promo collante et les accents décoratifs, toutes des surfaces où s'applique le plancher 3:1. La prose, les titres et tout le reste du texte utilisent un #1A1A1A presque noir sur le crème, qui dépasse 4,5:1 sans souci. La décision est documentée dans notre système de design à côté des mesures de contraste, donc le compromis est vérifiable plutôt qu'invisible.

La plupart des sites d'avis de ce secteur ne montrent pas du tout ce genre de compromis de marque. Ils annoncent une conformité AA complète, et l'audit ne repère jamais l'écart de couleur d'accent parce que l'audit n'a jamais tourné. Nous, on fait tourner l'audit, on consigne le résultat, et on te le dit. C'est ça, la différence entre une vraie déclaration d'accessibilité et un texte passe-partout copié-collé.

Problèmes ouverts :

ID	Problème	Gravité	Statut	Correction cible
A11Y-001	Couleur de marque (#E94B6A) sur crème (#FAF7F2) = 3,46:1, sous le plancher AA texte courant 4,5:1	Exception acceptée (UI/accent seulement ; prose non concernée)	Documentée dans les tokens de design	Aucune correction prévue sans changement de couleur de marque
A11Y-002	Texte alternatif des images Open Graph sur les aperçus sociaux de listes	Cosmétique (n'affecte pas la lecture sur le site)	En correction	T3 2026
A11Y-003	Audit complet WCAG 2.1 AA du chatbot Concierge IA	Bloquant (le chatbot ne sortira pas tant que ce n'est pas levé)	Audit en attente avant sortie	Avant sortie

Si tu tombes sur un problème absent de cette liste, signale-le. La liste est mise à jour dès qu'un nouveau problème est découvert ou qu'un existant est clos.

Comment je signale un problème d'accessibilité ?

La boîte dédiée, c'est [email protected]. Pour nous aider à reproduire et corriger plus vite, indique si possible :

• L'URL de la page où tu as rencontré l'obstacle.
• Ton système d'exploitation et ton navigateur (et leur version).
• La technologie d'assistance utilisée (lecteur d'écran, contacteur, loupe, commande vocale, etc.) et sa version.
• Une courte description de ce que tu attendais et de ce qui s'est passé à la place.
• Une capture d'écran ou un enregistrement, si tu en as un et que tu es à l'aise pour le partager.

Tu peux aussi demander cette déclaration, un résumé d'audit, ou une correction précise dans un format alternatif (gros caractères, e-mail en texte brut, un rappel téléphonique) en écrivant à la même adresse. On n'exige aucune de ces infos pour enquêter ; ça nous aide juste à reproduire le problème.

L'engagement est volontaire et publié ici pour qu'il soit vérifiable. Si on rate l'accusé de réception sous 2 jours ou la cible de 7 jours sur un problème bloquant, c'est en soi un manquement documenté et on le documentera sur cette page. Les voies de recours légales, par exemple les plaintes auprès de l'UK Equality and Human Rights Commission, de la ligne Department of Justice ADA américaine, ou de ton équivalent national, restent ouvertes quelle que soit la façon dont on traite le signalement en interne.

Et le support des lecteurs d'écran ?

Les lecteurs d'écran ne voient pas ce que voient les personnes voyantes ; ils analysent l'arbre du document. C'est pour ça que c'est le HTML sémantique, pas ARIA, qui porte le premier poids de l'accessibilité ici. On ajoute ARIA uniquement là où la sémantique HTML native ne suffit pas (régions live sur le contenu dynamique, rôles de dialogue sur les fenêtres, états déployés sur les widgets d'affichage), selon la première règle d'ARIA : si un élément natif fournit la sémantique, on l'utilise. La couverture lecteur d'écran est re-testée à chaque sortie majeure, et on garde les transcriptions de test en archive.

Comment la navigation au clavier est-elle gérée ?

Le contrat clavier, c'est la surface qu'on teste le plus dur, parce qu'elle tient lieu de toutes les technologies d'assistance qui émulent un clavier, contacteurs et claviers à l'écran compris. Les liens d'évitement satisfont le WCAG 2.4.1 Contournement de blocs, les indicateurs de focus visibles satisfont le WCAG 2.4.7 Visibilité du focus, et la règle d'absence de piège clavier satisfait le WCAG 2.1.2. Le piégeage du focus sur les fenêtres suit le motif de boîte de dialogue du W3C ARIA Authoring Practices Guide, avec le focus restauré sur l'élément déclencheur à la fermeture.

Quelles fonctionnalités d'accessibilité sont intégrées ?

L'inventaire complet des fonctionnalités, relié à son critère de succès WCAG sous-jacent :

• Repères sémantiques (<header>, <nav>, <main>, <footer>, <article>, <aside>), WCAG 1.3.1 Information et relations.
• Un seul H1 par page, hiérarchie H2/H3 stricte, aucun niveau sauté, WCAG 2.4.6 En-têtes et étiquettes.
• Le lien d'évitement vers le contenu principal en premier élément focusable, WCAG 2.4.1.
• Texte alternatif descriptif rédigé par l'équipe éditoriale, pas auto-généré ; l'imagerie décorative utilise alt="", WCAG 1.1.1 Contenu non textuel.
• Les tableaux portent <caption> et <th scope="col" | "row">, WCAG 1.3.1.
• La vidéo intégrée utilise youtube-nocookie.com, est livrée avec des transcriptions sur la page, ne se lance jamais seule, WCAG 1.2.1, 1.2.2, 1.2.3.
• Mouvement réduit : @media (prefers-reduced-motion: reduce) désactive le parallaxe, les carrousels à défilement automatique et les transitions décoratives, WCAG 2.3.3 Animation à partir d'interactions.
• Contraste des couleurs : 4,5:1 pour la prose, 3:1 pour le texte large et l'UI dans les deux modes (WCAG 1.4.3 Contraste minimum, 1.4.11 Contraste du non-textuel), avec la seule exception d'accent de marque documentée ci-dessus.
• Aucun sens porté par la couleur seule, WCAG 1.4.1 Utilisation de la couleur.
• Redimensionnement du texte jusqu'à 200 % sans perte de contenu, WCAG 1.4.4.
• Reflux à 320 pixels CSS sans défilement horizontal, WCAG 1.4.10.
• Libellés de formulaire, identification des erreurs, suggestion de correction, WCAG 1.3.1, 3.3.1, 3.3.3.
• Les titres de page décrivent le sujet ou le but, WCAG 2.4.2.
• La langue de la page est déclarée via l'attribut lang de l'élément HTML racine ; les surcharges par section via des attributs lang en ligne, WCAG 3.1.1, 3.1.2.

Comment le texte de droite à gauche est-il géré ?

Le support du droite-à-gauche, c'est pas un sujet de traduction ; c'est un sujet de mise en page. Basculer l'attribut dir du document sur "rtl" retourne l'inline-start et l'inline-end sur toute la mise en page, parce que chaque espacement, alignement et flottant est exprimé en propriétés logiques. Le contenu bidirectionnel (des URL latines dans de la prose arabe, par exemple) est enveloppé dans des éléments HTML <bdi> pour que l'algorithme bidirectionnel rende les choses de façon prévisible. On garde un audit droite-à-gauche complet sur une page de test arabe dédiée et on le refait avant chaque sortie.

Comment le mode sombre interagit-il avec l'accessibilité ?

Dernière revue : 2026

Le mode sombre est implémenté via un attribut data-theme="dark" sur l'élément racine du document, qui bascule les propriétés CSS personnalisées à la racine. Le bouton garde le choix de l'utilisateur dans localStorage, et si la personne n'a pas choisi, on suit prefers-color-scheme. Les deux palettes sont auditées indépendamment contre les minima de contraste WCAG 1.4.3 et 1.4.11. Le mode sombre va au-delà du goût esthétique. Les Apple Human Interface Guidelines et l'accessibilité GOV.UK le reconnaissent comme un aménagement pour la photophobie, la migraine et les conditions de basse vision, donc la garantie de contraste s'applique dans les deux sens.

Les vidéos sont-elles transcrites ?

Les transcriptions ne sont pas optionnelles ici. Elles servent les lecteurs sourds et malentendants (le public pour qui elles sont écrites), les lecteurs en environnement sans son comme le travail et les transports, les personnes qui apprennent une langue et s'appuient sur le texte pour renforcer l'audio, et les moteurs de recherche et robots IA qui peuvent lire du contenu lisible par machine que les pixels de la vidéo ne peuvent pas exposer. Un seul artefact, quatre retours.

Comment gérez-vous le mouvement réduit ?

Le seuil des trois clignotements satisfait le WCAG 2.3.1 Pas plus de trois flashs, le critère de prévention des crises d'épilepsie. Le respect du mouvement réduit répond aux troubles vestibulaires, aux nausées induites par le mouvement et aux besoins liés à l'attention documentés dans la littérature du groupe de travail W3C sur l'accessibilité cognitive. L'implémentation, c'est une seule media query, appliquée à la couche des tokens de design ; aucun JavaScript n'est requis pour que la préférence de l'utilisateur prenne effet.

À quelle fréquence testez-vous ?

Le test est en couches : automatique là où l'outillage est fiable, manuel là où l'humain reste le seul signal qui compte.

• Au build : axe-core tourne contre chaque story de composant et chaque capture de page en CI. Les builds échouent sur les violations graves ou critiques.
• Avant fusion : les pull requests portent un plancher de score Lighthouse Accessibilité de 95 et l'action GitHub bloque les fusions en dessous.
• Passes manuelles au lecteur d'écran : NVDA, JAWS, VoiceOver (macOS + iOS), TalkBack, chaque trimestre sur un échantillon de pages représentatif, au cas par cas sur tout nouveau gabarit.
• Passe au clavier seul : chaque nouveau type de page est parcouru de bout en bout au clavier avant fusion, et le compte-rendu de test est archivé avec la modification.
• Audit d'ordre de lecture : l'ordre de tabulation est comparé à l'ordre de lecture visuel sur chaque gabarit.
• Simulation de daltonisme : Sim Daltonism et le panneau de rendu des Chrome DevTools simulent la protanopie, la deutéranopie et la tritanopie sur chaque palette publiée. L'exception de contraste de couleur de marque est consignée ici.
• Retours d'utilisateurs réels : chaque obstacle signalé à [email protected] est ouvert comme un ticket et suivi publiquement dans le tableau des Problèmes connus sur cette page.

Cette combinaison suit les recommandations de test d'accessibilité de GOV.UK: l'outillage automatique attrape grosso modo 30 à 40 % des problèmes, et le reste ne ressort que quand des humains utilisent une technologie d'assistance dans des conditions réelles.

Quel est l'engagement sur les plaintes d'accessibilité ?

L'engagement est volontaire et publié ici pour qu'il soit vérifiable. Si on rate l'accusé de réception sous 2 jours ou la cible de 7 jours sur un problème bloquant, c'est en soi un manquement documenté et on le documentera sur cette page. Les voies de recours légales, par exemple les plaintes auprès de l'UK Equality and Human Rights Commission, de la ligne Department of Justice ADA américaine, ou de ton équivalent national, restent ouvertes quelle que soit la façon dont on traite le signalement en interne.

Comment le chatbot Concierge IA gère-t-il l'accessibilité ?

Les interfaces conversationnelles mettent l'accessibilité à l'épreuve d'une façon que les pages statiques ne font pas. Le texte en flux a besoin de régions live ARIA polies, le focus doit se déplacer de façon prévisible entre le déclencheur, le panneau et la fermeture, les utilisateurs clavier ont besoin d'une sortie documentée, et les utilisateurs en mouvement réduit ont besoin que leurs préférences soient respectées sur la transition du panneau. L'audit du Concierge suivra le motif de boîte de dialogue du W3C ARIA APG pour le comportement du panneau et les recommandations WAI-ARIA sur les régions live pour les réponses en flux. On ajoutera la transcription complète de l'audit à cette page quand le chatbot sortira.

C'est quoi le Section 508 et le European Accessibility Act 2025 ?

Les deux régimes convergent sur la même cible technique. C'est pour ça qu'une seule posture de conformité satisfait les deux, et pourquoi on prend la barre applicable la plus haute (WCAG 2.1 AA via l'EN 301 549 v3.2.1) et qu'on la traite comme le plancher sur chaque page publique du site, pas seulement sur les surfaces touchées par des contrats fédéraux US ou des obligations de service UE.

La date d'entrée en vigueur du 28 juin 2025 de l'EAA compte pour les éditeurs privés comme nous. C'est le moment où « une déclaration d'accessibilité sur le site » cesse d'être une politesse et devient un artefact vérifiable par le régulateur dans les États membres qui ont transposé la directive. On a publié cette déclaration bien avant cette date, avec la seule exception documentée ci-dessus, parce qu'on préfère avoir la conversation sur notre compromis de couleur de marque maintenant que se la faire poser plus tard.

Citer cette page

Si tu fais référence à cette déclaration dans un travail universitaire, réglementaire ou journalistique, cite-la ainsi :

Joly, A. (2026). Déclaration d'accessibilité : objectifs WCAG 2.1 AA, exceptions et signalement pour bestgirlfriend.ai. bestgirlfriend.ai. https://bestgirlfriend.ai/fr/accessibility

Un résumé lisible par machine est publié sur /llms.txt pour l'ingestion par les robots de recherche IA.

Questions fréquentes

Dernière revue : 2026.

Sources

Les standards, textes de loi et recommandations cités sur cette page sont listés ci-dessous dans l'ordre où ils apparaissent, avec des URL stables. Revérifiés en 2026.

• [Source: W3C, Web Content Accessibility Guidelines (WCAG) 2.1, Recommandation W3C du 5 juin 2018 · verified 2026-06-04]
• [Source: W3C, Web Content Accessibility Guidelines (WCAG) 2.2, Recommandation W3C du 5 octobre 2023 · verified 2026-06-04]
• [Source: ETSI, EN 301 549 v3.2.1, Exigences d'accessibilité pour les produits et services TIC (mars 2021) · verified 2026-06-04]
• [Source: Directive européenne sur l'accessibilité du web 2016/2102 · verified 2026-06-04]
• [Source: European Accessibility Act de l'UE, directive 2019/882 (applicable le 28 juin 2025) · verified 2026-06-04]
• [Source: Section 508 du Rehabilitation Act américain, ICT Refresh (2018) · verified 2026-06-04]
• [Source: UK Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (SI 2018/952) · verified 2026-06-04]
• [Source: Accessibility for Ontarians with Disabilities Act, 2005 (AODA) et Integrated Accessibility Standards Regulation O. Reg. 191/11 · verified 2026-06-04]
• [Source: GOV.UK Service Manual, Tester l'accessibilité · verified 2026-06-04]
• [Source: Apple Developer, Human Interface Guidelines, Accessibilité · verified 2026-06-04]
• [Source: W3C ARIA Authoring Practices Guide, motif Boîte de dialogue (modale) · verified 2026-06-04]
• [Source: Deque Systems, axe-core, moteur de test d'accessibilité open source · verified 2026-06-04]
• [Source: Google Chrome Developers, scoring Lighthouse Accessibilité · verified 2026-06-04]
• [Source: WebAIM, recherche en accessibilité et test des lecteurs d'écran · verified 2026-06-04]

Pages de confiance éditoriale à lire aussi

• Page méthode, les standards éditoriaux derrière chaque note sur bestgirlfriend.ai.
• Processus éditorial, comment les avis sont écrits, vérifiés et mis à jour.
• Politique de confidentialité, quelles données on collecte et tes droits sous le RGPD, le CCPA et leurs équivalents.
• Conditions d'utilisation, le contrat qui régit ton usage du site.
• Divulgation d'affiliation, comment on gagne de l'argent et pourquoi ça n'influence pas les classements.
• À propos d'Alexandra Joly, profil de la rédactrice en chef, parcours et contact direct.
• Contact, canal de contact général pour les demandes hors accessibilité.

Avis par juridiction

---

Vérifié le 4 juin 2026 · Voir le journal d'errata pour toute correction post-publication · Rédactrice : Alexandra Joly · Méthode · Processus éditorial · Divulgation d'affiliation