Accessibilité

Cette version fait foi. Une traduction anglaise est disponible : Accessibility EN. Elle est fournie pour la compréhension des lecteurs non francophones ; en cas de divergence, le texte français prévaut (arbitrage de l'éditeur du 22 août 2026).

Cette page dit comment l'accessibilité d'OrgGuardian est mesurée, ce que la mesure donne, et ce qu'elle ne couvre pas. Ce n'est pas une déclaration de conformité. Les réserves sont nommées plus bas, et nous les considérons comme bloquantes pour une déclaration — c'est la conclusion de notre propre audit, pas une précaution ajoutée après coup.

Cette page a été corrigée le 22 août 2026, et dans les deux sens. La mesure rejouée sur la version installée a trouvé 37 échecs de contraste là où nous annoncions zéro depuis le 13 août — et elle a montré, dans le même relevé, que notre propre sonde criait au loup sur une réserve que nous publiions. Les deux corrections sont détaillées ci-dessous. Nous préférons publier une mesure qui nous contredit qu'un chiffre confortable que nous savons faux.

Que mesure-t-on, et comment ?

Le référentiel appliqué est WCAG 2.1, niveaux A et AA. La mesure est instrumentée et rejouable : elle parcourt l'application déployée dans une org réelle, écran par écran, et calcule chaque ratio de contraste sur la couleur composée jusqu'au premier fond opaque trouvé en remontant les ancêtres — pas sur la valeur déclarée dans la feuille de style.

Relevé du 22 août 2026, sur la version 0.1.0.16 installée dans une org réelle. Une mesure appartient au jour et à la version où elle a été prise ; celle-ci remplace le relevé du 13 août plutôt que de le corriger, et sera remplacée à son tour.

• 39 écrans mesurés sur 39. Les écrans sont énumérés depuis les onglets que le paquet installe, et non depuis la navigation affichée : un audit qui ne visite que les écrans faciles d'accès surestime la conformité.
• 55 551 éléments parcourus.

Que donne la mesure ?

1.4.3 — contraste du texte

37 échecs, qui se ramènent à six paires couleur/fond — pas à trente-sept endroits distincts. La plus fréquente, vingt-sept fois, est le rouge « Critique » : #dc2626 sur #f4f7fc, ratio 4,497 pour un seuil de 4,5. Il échoue de trois millièmes. Aucun œil ne l'aurait vu, aucune relecture ne l'aurait attrapé ; seule une mesure de ratio le trouve. Les six paires sont corrigées dans le code — la plus petite retouche qui passe le seuil, pour ne pas déplacer la charte — mais le correctif n'est pas encore dans le paquet installé : il sera vérifié sur org réelle à la version suivante, pas par le calcul seul.

1.1.1 — images sans alternative textuelle

0.

1.3.1 — sauts de niveau de titre

0.

2.4.3 — tabindex positif

0. L'ordre de tabulation suit l'ordre du document.

1.4.10 — redistribution à 345 px

Conforme : le document ne déborde pas horizontalement.

4.1.2 — éléments focusables sans nom accessible

0. Ce chiffre a d'abord été annoncé à 3, puis mesuré à 15 — et les quinze étaient des faux positifs de notre propre sonde. Elle lisait le nom accessible via textContent, qui ne traverse pas un shadow root ; les cellules d'un lightning-datatable rendent leur contenu dans des shadow roots imbriqués. La sonde lisait une chaîne vide et concluait « sans nom », alors que la cellule affichait bien son texte. Sonde corrigée, extraction bornée en profondeur et en nœuds : 15 avant, 0 après, sur l'org inchangée.

Pourquoi ne déclarons-nous pas la conformité ?

Un audit qui ne déclare pas ses angles morts n'est pas opposable. Voici les nôtres.

1. 942 nœuds de texte reposent sur un fond non mesurable (relevé du 13 août) — des dégradés du système de design Salesforce, que l'instrument ne sait pas réduire à une couleur unique. Ils sont déclarés non mesurés, jamais supposés conformes. C'est la réserve la plus lourde : une part non négligeable du texte n'a pas été vérifiée, et une vérification à l'œil ou à l'outil pixel reste due.
2. Les 37 échecs de contraste sont corrigés dans le code, pas encore dans le paquet installé. Tant que la version suivante n'est pas mesurée sur une org réelle, cette réserve tient : un correctif calculé n'est pas un correctif vérifié.
3. 409 cibles tactiles sous 24 px (relevé du 13 août). Ce critère relève de WCAG 2.2 et n'est pas requis en 2.1. Nous le signalons parce qu'il le sera.

Et ce site lui-même ?

La page que vous lisez et les autres pages de ce site sont mesurées séparément du produit, sur le site publié et non sur les fichiers locaux. Relevé du 22 août 2026 : 20 des 28 pages publiées, × 4 largeurs (320, 390, 768 et 1 440 px, soit 80 rendus), 14 300 nœuds de texte, 0 échec de contraste AA, 0 débordement horizontal. Également : 0 rupture de niveau de titre, navigation au clavier complète, et respect de prefers-reduced-motion. Le carrousel de captures reste lisible sans JavaScript.

Ce que ce relevé ne couvre pas, et pourquoi nous le disons. Huit des vingt-huit pages publiées sont restées hors du balayage — 29 % du périmètre. Un audit qui ne déclare pas ses angles morts n'est pas opposable ; celui-ci en avait un, il est nommé. Par ailleurs les quinze pages anglaises ont été entièrement régénérées depuis : elles servaient jusque-là un en-tête et un pied de page français, ce qui plaçait 105 intitulés d'aide français sous un document déclaré lang="en" — un manquement à WCAG 3.1.2 que ce relevé n'a pas vu, faute de les avoir mesurées. Le relevé complet des 28 pages est donc à refaire après la prochaine mise en ligne, et cette page portera sa date.

Ce relevé-ci a coûté un correctif à l'instrument, et c'est la partie qui mérite d'être dite. Le balayage ne lisait que la propriété color : il ne composait pas opacity. Une pastille de langue posée à opacity: .7 rendait 3,61:1 sur blanc — un échec AA qu'il ne pouvait pas voir. Troisième fois que le même angle mort se paie sur cet outil, après les dégradés de fond et les états d'apparition : une couleur rendue n'est pas une couleur déclarée. La pastille est corrigée, l'instrument aussi, et les 80 rendus ci-dessus ont été repris après.

Relevé du 26 août 2026 : ce que le relevé du 22 août ne dit plus. Le site comptait 28 pages ce jour-là ; il en compte 44 aujourd'hui. Les chiffres ci-dessus appartiennent donc au site du 22 août et à lui seul — ils ne couvrent pas les seize pages parues depuis, et « navigation au clavier complète » n'a pas été remesuré sur elles. Ce qui suit est ce qui a été mesuré le 26 août, et rien de plus.

Un défaut WCAG trouvé et corrigé le 26 août, sur 14 des 44 pages. Le formulaire de demande d'essai porte un piège à robots : un champ que personne ne voit et que seul un automate remplit. Il était masqué hors de l'écran et retiré du parcours de tabulation, mais il restait focalisable par programme — un contenu focalisable placé sous aria-hidden="true", ce qu'un contrôle WCAG compte comme un défaut. L'attribut inert a été posé sur les quatorze copies du formulaire. Vérification : 42 URL publiées × 4 largeurs, soit 168 rendus, et 0 élément focalisable non inerte sous aria-hidden sur l'ensemble ; un cycle complet de tabulation sur l'accueil rend 63 arrêts et le champ n'apparaît dans aucun. Le piège, lui, pige toujours : le champ reste affiché au sens de CSS et reste posté avec le formulaire, ce que le serveur continue d'exiger. Un cliquet dans la suite de tests refuse désormais la perte de l'attribut sur une seule des quatorze pages — un attribut recopié quatorze fois à la main se perd à la quinzième édition.

Un second défaut WCAG trouvé et corrigé le 26 août, sur les 11 pages anglaises. Le bandeau de titre des pages intérieures est une dalle sombre : le lien de la mention « The French text governs », qui renvoie chaque page anglaise vers sa version française, y restait peint au bleu de lien du papier — #2563EB sur #0B1220, soit 3,62:1 pour un seuil de 4,5 (WCAG 1.4.3). La cause est une égalité de spécificité CSS : la règle du bandeau et la règle du papier pesaient exactement le même poids, et la plus basse du fichier l'emportait. Le lien passe au cyan de l'appareil, 10,36:1. Relevé de vérification : 44 pages, 371 nœuds de texte dans le bandeau sombre, 0 échec après correction contre 11 avant, la plus basse paire restante étant à 7,19:1. Ce relevé ne couvre que le bandeau sombre : le reste des pages n'est pas remesuré ici, pour la raison dite juste en dessous.

Un quatrième angle mort de l'instrument, nommé le 26 août et pas encore corrigé. La sonde cherche le premier fond opaque en remontant les ancêtres. Quand un élément porte à la fois une couleur de fond opaque et un motif décoratif en dégradé translucide, elle résout le dégradé contre le fond du parent et saute la couleur de l'élément lui-même, celle qui est pourtant peinte dessous. Sur les bandeaux sombres de ce site, elle compose donc du texte blanc sur le papier clair du <body> et annonce 1,13:1 là où l'œil lit du blanc sur #0B1220. Le mécanisme est démontré, la conséquence est massive : 3 508 prétendus échecs sur les 42 URL, et l'instrument ne permet pas de distinguer lesquels seraient réels. Aucun relevé de contraste du site n'est donc publié pour le 26 août : il faut d'abord réparer la sonde, puis remesurer. C'est la quatrième fois que le même genre d'angle mort se paie sur cet outil, après les dégradés de fond, les états d'apparition et opacity — et c'est la raison pour laquelle il est écrit ici plutôt que passé sous silence.

Relevé du 27 août 2026 : la sonde est réparée, le contraste est remesuré. Le paragraphe précédent annonçait qu’aucun relevé de contraste ne serait publié tant que l’instrument composerait les fonds à l’envers. Il compose désormais l’opacité et remonte les fonds d’ancêtre, et refuse de noter ce qu’il ne sait pas calculer plutôt que de le compter juste. Sur 44 pages × 7 largeurs (320, 390, 620, 900, 960, 1 024 et 1 440 px, soit 308 rendus) : 58 884 relevés de contraste considérés et 0 échec AA parmi ceux qui ont pu être jugés.

L’angle mort de ce relevé, et il est large : 13 461 relevés — 23 % — n’ont pas été jugés. Ce sont ceux dont un ancêtre porte une image de fond : le fond effectif d’un texte posé dessus ne se déduit d’aucune valeur déclarée, et un instrument qui inventerait une couleur là rendrait un chiffre au lieu d’une mesure. 2 828 autres (5 %) ont été jugés sur un fond approché et sont signalés comme tels par l’outil. Nous préférons publier ce 23 % que de l’absorber dans un « 0 échec » qui paraîtrait plus net qu’il ne l’est.

Débordement horizontal : 0, vérifié séparément du harnais, sur 12 largeurs de 320 à 1 920 px (320, 328, 360, 390, 620, 768, 900, 960, 976, 1 024, 1 440, 1 920) et les 44 pages. Le pas fin n’est pas décoratif : deux bandes étroites — [320 ; 331] et [951 ; 990] — débordaient sans qu’aucune des largeurs alors mesurées n’y tombe. Elles sont corrigées, et les deux largeurs témoins sont entrées dans l’outil pour qu’une récidive se voie.

Ce relevé porte sur une mise en page refondue le jour même. Le corps des pages d’article était aligné sur un bord gauche commun : la prose y occupait 632 px d’une piste de 1 136, laissant 504 px de vide à sa droite sur chaque paragraphe. Elle partage désormais un axe et non un bord (252 px de chaque côté à 1 440 px). Le défaut avait été signalé quatre fois à l’œil pendant que cinq mesures successives le déclaraient vert ; l’outil a gagné pour cela une sixième mesure, qui refuse un bloc décentré dans sa piste.

Un défaut à signaler

Si vous rencontrez un obstacle d'accessibilité, dans le produit ou sur ce site, écrivez à contact@orgguardian.com. Décrivez l'écran, la technologie d'assistance utilisée et ce qui s'est passé : c'est ce qui rend un signalement reproductible, donc corrigeable.

Retour à l'accueil