Le but de ce document est d’évaluer le niveau d’accessibilité du site Contre-visite Site internet.
2. Référentiel
Le référentiel utilisé pour l’audit est le R.G.A.A. version 4.1.2, publié par l’état français.
Ce référentiel s’appuie sur les préconisations internationales W.C.A.G. 2.1 (Web Content Accessibility Guidelines) niveau AA.
Il est complètement compatible avec les W.C.A.G. 2.1 niveau AA, ainsi qu’avec la norme européenne EN 301 549 V2.1.2.
(Les W.C.A.G. sont également repris dans l’A.D.A. (American with Disability Act).
Le référentiel R.G.A.A. version 4.1.2 fournit une méthode d’application et d’évaluation des préconisations internationales W.C.A.G. 2.1, plus efficace à mettre en œuvre lors des audits, et plus facile à exploiter pour les personnes qui auront ensuite à prendre en charge les correctifs.
Le R.G.A.A. se décline en treize thématiques :
Images
Cadres
Couleurs
Multimédia
Tableaux
Liens
Scripts
Éléments obligatoires
Structuration de l'information
Présentation de l'information
Formulaires
Navigation
Consultation
3. Périmètre du test
Le périmètre du test est constitué des pages suivantes :
Dans l’audit, il pourra être fait référence à la notion de masquage accessible. Cette technique consiste à enrichir la page de contenus textuels, qui seront visuellement cachés, mais qui resteront exploitables par les outils d’aide technique tels que les synthèses vocales.
Ceci a pour but, lorsque des informations additionnelles sont nécessaires aux utilisateurs de synthèse vocale pour la bonne compréhension de la page, de les leur procurer sans modifier l’aspect visuel de la page.
Un exemple éprouvé de classe CSS permettant de mettre en place cette fonctionnalité est disponible sous l’url :
Ce style redéfinit la classe « sr-only », initialement proposée par bootstrap, mais peut être adaptée à n’importe quel contexte de développement.
5. Taux de contraste
La combinaison de deux couleurs, (l’une utilisée comme couleur de texte, et l’autre utilisée comme couleur de fond, ou réciproquement) produit un taux de contraste mesurable.
Le R.G.A.A. version 4.1.2 recommande des taux de contrastes qui vont dépendre de la taille des caractères, de la graisse de la police, et du niveau d’accessibilité souhaité :
Taux de contraste minimum
Le texte et le texte en image sans effet de graisse d’une taille restituée inférieure à 24px.
4.5:1
Le texte et le texte en image en gras d’une taille restituée inférieure à 18,5px.
4.5:1
Le texte et le texte en image sans effet de graisse d’une taille restituée supérieure ou égale à 24px.
3:1
Le texte et le texte en image en gras d’une taille restituée supérieure ou égale à 18,5px.
3:1
Les composants d’interface ou les éléments graphiques porteurs d’informations
3:1
Note : Bien que cela puisse restreindre un tout petit peu la palette des nuances disponibles, on voit qu’en s’imposant un taux de contraste minimum de 4.5:1 on s’assure d’être conforme, quelle que soit la taille et la graisse de police utilisées.
6. Navigation sur mobile
Les périphériques Android et IOS intègrent nativement une synthèse vocale, qui peut être activée depuis les paramètres du périphérique.
Pour parcourir les écrans, l’utilisateur de synthèse vocale aura deux modes principaux d’interaction :
La navigation séquentielle
La navigation « au doigt » ou « sous le doigt »
Le premier mode est la navigation séquentielle, qui consiste à balayer l’écran de gauche à droite. Chaque balayage vocalise les données textuelles de l’élément suivant, dans l’ordre dans lequel les éléments ont été insérés dans la page. Le balayage de droite à gauche fait la même chose mais en sens inverse.
Ce mode de navigation, permet de lister à coup sûr, tous les éléments de la page. Ceci est très pertinent en mode « découverte », pour découvrir de façon exhaustive tous les éléments que contient la page. L’inconvénient est que sur une page volumineuse dans laquelle l’élément que recherche l’internaute est situé plutôt vers la fin de la page, cela peut être long et fastidieux.
Un deuxième mode que nous appelons « navigation au doigt » ou « sous le doigt », va vocaliser ce qui se trouve sous le doigt à mesure qu’on le déplace sur l’écran. Ce premier mode est intéressant pour une personne non voyante qui connaît l’écran dans lequel elle se trouve, et qui sait à peu près ou est positionné l’élément qu’elle cherche.
L’inconvénient de ce mode de navigation est que l’on ne vocalisera jamais un élément sur lequel on n’a pas posé le doigt (par exemple un élément ne proposant qu’une surface d’affichage minime à côté de laquelle on risque fort de passer) et qu’il est moins efficace sur une page inconnue de l’utilisateur.
Il est important de s’assurer que la construction de la page interagit correctement avec ces deux modes de navigation.
B. Synthèse
1. Résultats
Le taux de conformité par critère du site est de 85% et le taux moyen de conformité du service en ligne est de 93%.
L'audit de contrôle a proposé quelques correctifs permettant d'améliorer le taux d'accessibilité du site d'Assurance Prévention.
Dans sa globalité, les corrections effectuées sont très encourageantes et permettent d'atteindre un taux de conformité de 80%.
Parmi les correctifs appliqués, seule l'utilisation d'une description détaillée ayant pour objectif d'alléger l'alternative d'une image reste à corriger
Il reste encore un petit bout de chemin à parcourir pour que le site devienne totalement conforme.
1. Images
Critère 1.1 - Chaque image porteuse d’information a-t-elle une alternative textuelle ?
[CTRL] Images porteuses d'information sans alternative textuelle
URBILOG OK (02/06/2025): Passage en simple remarque
Chaque image porteuse d'information doit avoir une alternative textuelle transmettant une information équivalente aux aides techniques telles que les synthèses vocales.
Les logos situés dans les volets d'accueil et de paramétrage de la fenêtre des cookies doivent avoir un attribut « alt » retranscrivant leur contenu textuel, comme par exemple « Logo Assurance Prévention : Ensemble agir, chaque jour prévenir ».
Figure n°1 : Exemple d'image porteuse d'information sans alternative textuelleFigure n°2 : ContexteFigure n°3 : Contexte
Image devant indiquer la présence d’une description détaillée
OK Urbilog 06/06/2025
Le texte mis en alternative est supposé être la description détaillée car elle est trop lourde en terme de vocalisation. L'alternative attendue est "Affiche de prévention sur le changement d'heure - Voir la description détaillée en dessous" et ajouter le contenu de la fiche (mise dans l'attribut alt) en masquage accessible afin de ne surcharger ni la page, ni la vocalisation de l'image.
Chaque image porteuse d'information doit avoir une alternative textuelle transmettant une information équivalente aux aides techniques telles que les synthèses vocales.
L'image d'annonce sur le changement d'heure nécessite une description détaillée (voir critère 1.6). L'attribut « alt » devra indiquer la présence de cette description.
Par exemple « présence d'une description détaillée après l'image » ou encore « présence d'un lien vers la description détaillée après l'image ».
Figure n°4 : Image devant indiquer la présence d’une description détaillée
Critère 1.2 - Chaque image de décoration est-elle correctement ignorée par les technologies d’assistance ?
Images décoratives non ignorées par les technologies d'assistance
OK Urbilog 28/05/2025
Les différentes images du carrousel possèdent une alternative textuelle « alt » et sont associées à des liens dont l'intitulé est identique à ces alternatives textuelles, et elles possèdent également une légende <figcaption> qui est aussi identique à l'alternative textuelle. Cette implémentation en doublon n'est pas conforme : il faut supprimer la légende <figcaption> et transférer son contenu au sein du lien correspondant, tout en vidant l'alternative textuelle de l'image : voir critère 6.2.
Figure n°5 : Exemple d'image décorative non ignorée par les technologies d'assistance
Critère 1.3 - Pour chaque image porteuse d’information ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers) ?
Non applicable
Critère 1.4 - Pour chaque image utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle, cette alternative permet-elle d’identifier la nature et la fonction de l’image ?
Non applicable
Critère 1.5 - Pour chaque image utilisée comme CAPTCHA, une solution d’accès alternatif au contenu ou à la fonction du CAPTCHA est-elle présente ?
Non applicable
Critère 1.6 - Chaque image porteuse d’information a-t-elle, si nécessaire, une description détaillée ?
Image comportant une grande quantité d'informations, nécessitant une description détaillée
OK Urbilog 06/06/2025
Le texte mis en alternative est supposé être la description détaillée car elle est trop lourde en terme de vocalisation. L'alternative attendue est "Affiche de prévention sur le changement d'heure - Voir la description détaillée en dessous" et ajouter le contenu de la fiche (mise dans l'attribut alt) en masquage accessible afin de ne surcharger ni la page, ni la vocalisation de l'image.
Lorsqu'une image transmet une grande quantité d'informations, on ne peut pas utiliser une simple alternative textuelle, et il faut mettre en place une solution adaptée pour transmettre cette information.
Cette description détaillée pourra être placée dans la page après l'image (par exemple dans un accordéon replié par défaut et piloté par un lien ou bouton explicite), ou encore dans une page dédiée, vers laquelle un lien sera fourni après l'image.
L’alternative textuelle de l'image précisera « présence d'une description détaillée après l'image » ou « présence d'un lien vers la description détaillée après l'image ».
L'image d'annonce sur le changement d'heure contient un grand nombre d'informations et nécessite une description détaillée.
Figure n°6 : Image comportant une grande quantité d'informations, nécessitant une description détaillée
Critère 1.7 - Pour chaque image porteuse d’information ayant une description détaillée, cette description est-elle pertinente ?
Non applicable
Critère 1.8 - Chaque image texte porteuse d’information, en l’absence d’un mécanisme de remplacement, doit si possible être remplacée par du texte stylé. Cette règle est-elle respectée (hors cas particuliers) ?
Non applicable
Critère 1.9 - Chaque légende d’image est-elle, si nécessaire, correctement reliée à l’image correspondante ?
Non applicable
2. Cadres
Critère 2.1 - Chaque cadre a-t-il un titre de cadre ?
Conforme
Critère 2.2 - Pour chaque cadre ayant un titre de cadre, ce titre de cadre est-il pertinent ?
Conforme
3. Couleurs
Critère 3.1 - Dans chaque page web, l’information ne doit pas être donnée uniquement par la couleur. Cette règle est-elle respectée ?
Conforme
Critère 3.2 - Dans chaque page web, le contraste entre la couleur du texte et la couleur de son arrière-plan est-il suffisamment élevé (hors cas particuliers) ?
Contraste insuffisant au survol entre le texte et son arrière-plan
OK Urbilog 28/05/2025
Le texte des différents boutons de la fenêtre des cookies permettant d'accepter, refuser ou paramétrer les cookies ont un taux de contraste avec l'arrière-plan au survol du pointeur inférieur au minimum requis de 4,5:1.
Figure n°7 : Exemple de contraste insuffisant au survol entre le texte et son arrière-plan (1,6:1)Figure n°8 : Exemple de contraste insuffisant au survol entre le texte et son arrière-plan (1,6:1)
Critère 3.3 - Dans chaque page web, les couleurs utilisées dans les composants d’interface ou les éléments graphiques porteurs d’informations sont-elles suffisamment contrastées (hors cas particuliers) ?
[CTRL] Contraste insuffisant entre un élément d'interface et son arrière-plan
URBILOG OK (02/06/2025)
Dans le pied de page, la case à cocher permettant d'accepter la politique de confidentialité pour la newsletter a un taux de contraste avec son arrière-plan inférieur au minimum requis de 3:1.
Figure n°9 : URBILOG OK - Contraste insuffisant entre un élément d'interface et son arrière-plan (1,2:1)
[CTRL] Contraste insuffisant entre des éléments d'interface et leur arrière-plan
OK Urbilog 06/06/2025
Dans la fenêtre de gestion des cookies, les liens permettant d'accéder aux politiques de confidentialité de YouTube et Google ont un contraste avec l'arrière-plan inférieur au minimum requis de 3:1.
Figure n°10 : URBILOG KO - Contraste insuffisant entre des éléments d'interface et leur arrière-plan (1,1:1)
[CTRL] Contraste insuffisant entre des éléments d'interface et leur arrière-plan
URBILOG OK (02/06/2026)
Les boutons permettant de sélectionner une diapositive du carrousel ont un contour dont le taux de contraste avec l'arrière-plan est inférieur au minimum requis de 3:1.
Figure n°11 : URBILOG OK - Contraste insuffisant entre des éléments d'interface et leur arrière-plan (1,2:1)
[CTRL] Contraste insuffisant entre des éléments d'interface et leur arrière-plan
URBILOG OK (02/06/2025)
Les cases à cocher et boutons radio situés dans les fenêtres modales de filtrage des résultats de recherche et des médias ont un contraste avec l'arrière-plan inférieur au minimum requis de 3:1, aussi bien dans leur état par défaut qu'au survol du pointeur.
Figure n°12 : Urbilog OK - Exemple de contraste insuffisant entre un élément d'interface et son arrière-plan (1,1:1)Figure n°13 : Urbilog OK - Exemple de contraste insuffisant entre des éléments d'interface et leur arrière-plan (1,1:1)Figure n°14 : Urbilog OK - Exemple de contraste insuffisant au survol entre des éléments d'interface et leur arrière-plan (1,2:1)
[CTRL] Contraste insuffisant entre des éléments d'interface et leur arrière-plan
URBILOG OK (02/06/2025)
Les cases à cocher et boutons radio du questionnaire ont un contraste avec l'arrière-plan inférieur au minimum requis de 3:1.
Figure n°15 : URBILOG OK - Exemple de contraste insuffisant entre des éléments d'interface et leur arrière-plan (1,1:1)Figure n°16 : URBILOG OK - Exemple de contraste insuffisant entre des éléments d'interface et leur arrière-plan (1,1:1)
4. Multimédia
Critère 4.1 - Chaque média temporel pré-enregistré a-t-il, si nécessaire, une transcription textuelle ou une audiodescription (hors cas particuliers) ?
Non applicable
Critère 4.2 - Pour chaque média temporel pré-enregistré ayant une transcription textuelle ou une audiodescription synchronisée, celles-ci sont-elles pertinentes (hors cas particuliers) ?
Non applicable
Critère 4.3 - Chaque média temporel synchronisé pré-enregistré a-t-il, si nécessaire, des sous-titres synchronisés (hors cas particuliers) ?
Non applicable
Critère 4.4 - Pour chaque média temporel synchronisé pré-enregistré ayant des sous-titres synchronisés, ces sous-titres sont-ils pertinents ?
Non applicable
Critère 4.5 - Chaque média temporel pré-enregistré a-t-il, si nécessaire, une audiodescription synchronisée (hors cas particuliers) ?
Non applicable
Critère 4.6 - Pour chaque média temporel pré-enregistré ayant une audiodescription synchronisée, celle-ci est-elle pertinente ?
Non applicable
Critère 4.7 - Chaque média temporel est-il clairement identifiable (hors cas particuliers) ?
Non applicable
Critère 4.8 - Chaque média non temporel a-t-il, si nécessaire, une alternative (hors cas particuliers) ?
Non applicable
Critère 4.9 - Pour chaque média non temporel ayant une alternative, cette alternative est-elle pertinente ?
Non applicable
Critère 4.10 - Chaque son déclenché automatiquement est-il contrôlable par l’utilisateur ?
Non applicable
Critère 4.11 - La consultation de chaque média temporel est-elle, si nécessaire, contrôlable par le clavier et tout dispositif de pointage ?
Non applicable
Critère 4.12 - La consultation de chaque média non temporel est-elle contrôlable par le clavier et tout dispositif de pointage ?
Non applicable
Critère 4.13 - Chaque média temporel et non temporel est-il compatible avec les technologies d’assistance (hors cas particuliers) ?
Non applicable
5. Tableaux
Critère 5.1 - Chaque tableau de données complexe a-t-il un résumé ?
Non applicable
Critère 5.2 - Pour chaque tableau de données complexe ayant un résumé, celui-ci est-il pertinent ?
Non applicable
Critère 5.3 - Pour chaque tableau de mise en forme, le contenu linéarisé reste-t-il compréhensible ?
Conforme
Critère 5.4 - Pour chaque tableau de données ayant un titre, le titre est-il correctement associé au tableau de données ?
Non applicable
Critère 5.5 - Pour chaque tableau de données ayant un titre, celui-ci est-il pertinent ?
Non applicable
Critère 5.6 - Pour chaque tableau de données, chaque en-tête de colonne et chaque en-tête de ligne sont-ils correctement déclarés ?
En-têtes de colonne de tableaux simples mal déclarés
OK Urbilog 28/05/2025
Les cellules qui sont des en-têtes de ligne ou de colonne, et qui permettent donc d'identifier le contenu des cellules de données associées, doivent être identifiées comme des en-têtes.
Si les en-têtes s'appliquent à la totalité d'une colonne ou d'une ligne, alors :
Une première solution consistera à les coder comme des éléments <th>.
Une deuxième solution consistera à leur donner un attribut « role » avec la valeur « columnheader » pour les en-têtes de colonne.
Dans les tableaux des types de données collectées et de durée de conservation des données, les en-têtes de colonne ne sont pas correctement déclarés.
Figure n°17 : Exemple d'en-têtes de colonne de tableau simple mal déclarésFigure n°18 : Exemple d'en-têtes de colonne de tableau simple mal déclarés
Critère 5.7 - Pour chaque tableau de données, la technique appropriée permettant d’associer chaque cellule avec ses en-têtes est-elle utilisée (hors cas particuliers) ?
Conforme
Critère 5.8 - Chaque tableau de mise en forme ne doit pas utiliser d’éléments propres aux tableaux de données. Cette règle est-elle respectée ?
Les liens-images de la section « Sur les réseaux sociaux » autres que LinkedIn contiennent une image SVG décorative qui n'est pas masquée aux technologies d'assistance : il faut masquer ces images en leur donnant un attribut « aria-hidden="true" ».
Intitulés visibles de liens non repris dans l'intitulé accessible
Lorsqu'un lien a un libellé qui n'est pas assez explicite et qu'on l'a rendu explicite au moyen d'un attribut « aria-label » ou « title », le contenu de cet attribut doit reprendre le libellé visible du lien en le complétant.
Les attributs « title » des deux liens fournis en source ne reprennent pas leur intitulé visible, leur contenu devrait être par exemple « « Grand froid : quelques précautions à prendre ! », INPES » ou « « Grand froid : information du public », Ministère de la Santé ».
Figure n°21 : Intitulés visibles de liens non repris dans l'intitulé accessible
Les deux liens de contact ne précisent pas le nom de la personne concernée. De plus, ils ont comme alternative textuelle « Ouvre un nouvel onglet », ce qui ne reprend pas leur intitulé visible. Le contenu de leur attribut « title » devrait être par exemple « Contacter Jean-Baptiste Mounier - Ouvre un nouvel onglet ».
Figure n°22 : Exemple d'intitulé de lien non suffisamment explicite
Critère 6.2 - Dans chaque page web, chaque lien a-t-il un intitulé ?
Les quatre liens-images de la section « Découvrez notre écosystème » contiennent une image avec une alternative vide. Il faut donner à ces images une alternative textuelle reprenant le nom des sites vers lesquels ces liens dirigent.
L'intitulé des différents liens du carrousel n'est implémenté qu'avec un attribut « title », et le contenu des balises <a> correspondantes est vide, ce qui n'est pas une implémentation conforme.
Comme évoqué au critère 1.2, il faut supprimer la légende <figcaption> des images correspondantes et transférer leur contenu au sein des liens, et il faut également vider l'alternative textuelle des images (« alt="" »).
Figure n°24 : Exemple de lien sans intitulé
7. Scripts
Critère 7.1 - Chaque script est-il, si nécessaire, compatible avec les technologies d’assistance ?
Lors de la recette, nous vous avions préconisé l'utilisation de l'élément HTML <dialog> avec l'utilisation de la méthode JS .showModal (permettant la déclaration implicite de l'élément comme modale).
OK Urbilog 28/05/2025
Il s'avère que cet élément HTML et ses méthodes associées soient trop jeunes pour être pleinement intégrés par l'ensemble des navigateurs.
Malheureusement, afin d'être conforme sur l'ensemble des environnements possibles des utilisateurs (notamment le navigateur web Firefox) il est nécessaire d'ajouter l'attribut « aria-modal="true" ».
Figure n°25 : Mauvaise vocalisation d'une fenêtre modaleFigure n°26 : Exemple de mauvaise vocalisation d'une fenêtre modaleFigure n°27 : Exemple de mauvaise vocalisation d'une fenêtre modale
Un compteur est un affichage graphique d'une valeur numérique qui varie dans une plage définie.
Par exemple, un compteur pourrait être utilisé pour indiquer le pourcentage actuel de batterie d'un appareil ou le niveau de carburant d'une voiture.
Note :
Un compteur ne doit pas être utilisé pour représenter une valeur telle que la population mondiale actuelle, car il n’a pas de limite maximale significative.
Le compteur ne doit pas être utilisé pour indiquer la progression, comme le chargement ou le pourcentage d'achèvement d'une tâche. Pour communiquer les progressions, utilisez plutôt le rôle "progressbar".
Le compteur affichant la progression de l'utilisateur dans le questionnaire n'interagit pas correctement à la vocalisation.
Il faut se baser sur le motif de conception WAI-ARIA "Meter".
Figure n°28 : Compteur avec une mauvaise vocalisation
Critère 7.2 - Pour chaque script ayant une alternative, cette alternative est-elle pertinente ?
Non applicable
Critère 7.3 - Chaque script est-il contrôlable par le clavier et par tout dispositif de pointage (hors cas particuliers) ?
Lorsqu'un menu comporte peu d'entrées et ne supporte qu'un seul niveau de sous-menu, il serait exagérément lourd de le coder en reproduisant de façon stricte le comportement clavier d'un menu natif fourni par le système d'exploitation.
On pourra se contenter du comportement suivant :
Lorsque l'on actionne un élément de menu, cela déplie le sous-menu mais le focus reste positionné sur l'élément de menu. Si l'on refait "entrée" cela referme le sous menu, et si l'on fait ensuite "tab" on va sur l'élément du menu suivant.
Une fois le sous-menu ouvert, si l'on fait "tab", on va sur le premier élément du sous-menu, et ainsi de suite jusqu'au dernier élément du sous-menu.
Lorsque l'on est sur le dernier élément du sous-menu, si l'on fait "tab" cela referme le sous-menu, et l'on va sur l'élément de menu suivant.
Le menu de navigation de l'en-tête n'a pas le comportement clavier attendu.
Figure n°29 : Menu simple non utilisable au clavier
Un carrousel présente un ensemble d'éléments, appelés diapositives, en affichant séquentiellement un sous-ensemble d'une ou plusieurs diapositives.
En règle générale, une diapositive est affichée à la fois et les utilisateurs peuvent activer un contrôle de diapositive suivant ou précédent qui masque la diapositive actuelle et « fait pivoter » la diapositive suivante ou précédente pour l'afficher.
Dans certaines implémentations, la rotation démarre automatiquement lors du chargement de la page, et elle peut également s'arrêter automatiquement une fois que toutes les diapositives ont été affichées.
Si le carrousel dispose d'une fonction de rotation automatique, la rotation automatique des diapositives s'arrête lorsqu'un élément du carrousel reçoit le focus clavier ou le survol de la souris.
Elle ne reprend que si l'utilisateur active le contrôle de rotation.
La tabulation et le retour à la tabulation déplacent le focus sur les éléments interactifs du carrousel comme spécifié par la séquence d'onglets de la page, le comportement à la tabulation ne devant pas être surchargé via les scripts.
Les boutons de commande sont idéalement des éléments natifs <button>.
Remarque : L'activation du contrôle de rotation, de la diapositive suivante et de la diapositive précédente ne déplace pas le focus, les utilisateurs peuvent donc facilement les activer de manière répétitive autant de fois qu'ils le souhaitent.
S'il est présent, le contrôle de rotation est le premier élément de la séquence d'onglets à l'intérieur du carrousel.
Il est essentiel qu'il précède le contenu en rotation afin de pouvoir le localiser facilement.
Figure n°30 : Mauvaise interaction au clavier d'un carrousel
Lorsqu'en actionnant un élément d'interface, on déclenche une action qui interagit sur la page, le focus doit être replacé de telle sorte que la continuité de la navigation clavier soit assurée.
Dans les différentes étapes du questionnaire, lorsque l'on navigue entre les différentes cases à cocher ou boutons radio, le focus se déplace vers l'étape précédente ou suivante dès qu'il arrive à une extrémité, et le reste des éléments de la page ne peuvent être atteints qu'après être arrivé à la première ou dernière étape du questionnaire. Ce fonctionnement n'est pas pertinent pour les utilisateurs de la navigation au clavier : il est préférable de supprimer le système de navigation entre les étapes avec « Maj+Tab », et de faire en sorte que l'utilisateur puisse naviguer entre les étapes grâce aux boutons situés en bas du questionnaire.
Figure n°31 : Repositionnement du focus non pertinent
Critère 7.4 - Pour chaque script qui initie un changement de contexte, l’utilisateur est-il averti ou en a-t-il le contrôle ?
Présence d'un script provoquant un changement de contexte à signaler
OK Urbilog 28/05/2025
Lorsqu'un élément provoque dynamiquement une modification importante de la page, il est indispensable d'en informer à l’avance l'utilisateur de façon à ce qu'il ne soit pas surpris, ou à lui en laisser le contrôle de façon à ce qu'il déclenche cette action en toute connaissance de cause.
Cela peut être fait par du texte relié à l'élément déclencheur, inséré avant l'élément, ou par le contenu d'un « aria-label » posé sur ce déclencheur.
Lorsque l'on actionne l'un des boutons radio permettant de sélectionner une thématique, cela provoque un rechargement de la page sans que l'utilisateur en soit prévenu. Cela est particulièrement problématique pour les utilisateurs de la navigation au clavier, car le rechargement de la page est déclenché dès que le focus se déplace sur un bouton radio différent de celui sélectionné par défaut.
Une solution possible serait de faire en sorte que l'actionnement d'un bouton radio ne déclenche plus le rechargement de la page, et implémenter un bouton permettant à l'utilisateur de confirmer sa sélection pour recharger la page.
Une autre solution possible serait d'implémenter ces filtres sous la forme d'une liste <ul><li> d'éléments <button>. Le filtre sélectionné (le bouton) possédera un attribut « aria-selected="true" ».
Remarque : L'utilisation de la méthode "POST" au lieu de "GET" serait appropriée.
Figure n°32 : Exemple de présence d'un script provoquant un changement de contexte à signaler
Critère 7.5 - Dans chaque page web, les messages de statut sont-ils correctement restitués par les technologies d’assistance ?
Conforme
8. Éléments obligatoires
Critère 8.1 - Chaque page web est-elle définie par un type de document ?
Conforme
Critère 8.2 - Pour chaque page web, le code source généré est-il valide selon le type de document spécifié ?
La validité du code de chaque page doit être vérifiée, en soumettant la page au validateur HTML.
Toutefois, toutes les erreurs de validation signalées par le validateur ne sont pas toutes gênantes pour l'accessibilité.
Voici les règles à respecter pour l'accessibilité, concernant la validité du code :
Les balises, attributs et valeurs d'attributs respectent les règles d'écriture :
pas de balise ouvrante ou fermante sans < ou >
pas de balise fermante avec / manquant
pas de valeur d'attribut avec des " ou " manquants
pas de valeurs multiples d'attribut séparées par un espace sans " ou '
pas d'espaces manquants entre les attributs
pas de balise fermante manquante pour les éléments qui en exigent une
L'imbrication des balises est conforme
L'ouverture et la fermeture des balises sont conformes
Les valeurs d'attribut « id » sont uniques dans la page
Les attributs ne sont pas doublés sur un même élément
La présence d'attributs "propriétaires" ne constitue pas forcément une erreur, exemple : l'erreur « Attribute cz-shortcut-listen not allowed on element body at this point » provenant de l’extension « ColorZilla ».
Le passage des pages au validateur signale de nombreuses erreurs.
Figure n°33 : Exemple d'erreur de validation
Critère 8.3 - Dans chaque page web, la langue par défaut est-elle présente ?
Conforme
Critère 8.4 - Pour chaque page web ayant une langue par défaut, le code de langue est-il pertinent ?
Conforme
Critère 8.5 - Chaque page web a-t-elle un titre de page ?
Conforme
Critère 8.6 - Pour chaque page web ayant un titre de page, ce titre est-il pertinent ?
Conforme
Critère 8.7 - Dans chaque page web, chaque changement de langue est-il indiqué dans le code source (hors cas particuliers) ?
Non applicable
Critère 8.8 - Dans chaque page web, le code de langue de chaque changement de langue est-il valide et pertinent ?
Non applicable
Critère 8.9 - Dans chaque page web, les balises ne doivent pas être utilisées uniquement à des fins de présentation. Cette règle est-elle respectée ?
[CTRL] Éléments HTML utilisés à des fins de présentation
URBILOG KO (02/06/2025) : Modale des cookies ;
URBILOG OK (02/06/2025) : Utilisation de mise en gras pour les autres éléments présents dans cette anomalie.
Les balises HTML ne doivent pas être détournées de leur rôle sémantique natif, notamment :
Les balises html <p>, <h>, <blockquote>, <br>, ne doivent pas servir à créer un effet visuel.
Les balises <div>, <span> ou <br> ne doivent pas servir à créer visuellement un paragraphe.
À plusieurs reprises sur le site et dans la fenêtre des cookies, des balises <strong> sont utilisées à des fins de présentation pour créer un effet de gras, il vaudrait mieux utiliser des feuilles de style.
Figure n°34 : Exemple d'élément HTML utilisé à des fins de présentationFigure n°35 : URBILOG OK - Exemple d'élément HTML utilisé à des fins de présentationFigure n°36 : URBILOG OK - Exemple d'élément HTML utilisé à des fins de présentationFigure n°37 : URBILOG OK - Exemple d'élément HTML utilisé à des fins de présentationFigure n°38 : URBILOG OK - Exemple d'élément HTML utilisé à des fins de présentation
Les balises HTML ne doivent pas être détournées de leur rôle sémantique natif, notamment :
Les balises html <p>, <h>, <blockquote>, <br>, ne doivent pas servir à créer un effet visuel.
Les balises <div>, <span> ou <br> ne doivent pas servir à créer visuellement un paragraphe.
À plusieurs reprises, des balises <em> sont utilisées à des fins de présentation pour créer un effet italique, il vaudrait mieux utiliser des feuilles de style.
Figure n°40 : Exemple d'élément HTML utilisé à des fins de présentationFigure n°41 : Exemple d'élément HTML utilisé à des fins de présentation
De nombreux liens ont leur libellé implémenté en tant que titre de niveau 3 alors qu'ils sont situés dans un cadre ne contenant que la date de l'article lié, et ne constituent donc pas des titres de section : il faut retirer les balises <h3> des liens correspondants.
Figure n°43 : Exemple de libellé identifié à tort comme un titreFigure n°44 : Exemple de libellé identifié à tort comme un titre
Tous les liens du plan du site sont implémentés en tant que titre de niveau 3 alors qu'ils ne constituent donc pas des titres de section : il faut retirer les balises <h3> des liens correspondants.
Figure n°45 : Exemple de libellé identifié à tort comme un titre
Critère 9.2 - Dans chaque page web, la structure du document est-elle cohérente (hors cas particuliers) ?
Conforme
Critère 9.3 - Dans chaque page web, chaque liste est-elle correctement structurée ?
Conforme
Critère 9.4 - Dans chaque page web, chaque citation est-elle correctement indiquée ?
Non applicable
10. Présentation de l'information
Critère 10.1 - Dans le site web, des feuilles de styles sont-elles utilisées pour contrôler la présentation de l’information ?
Contenus porteurs d'information insérés via des feuilles de style
OK 28/05/2025
Attention à l'intitulé remplaçant le bouton ouvrant/fermant le menu de navigation
Lorsque des éléments de contenus porteurs d'information sont insérés via du CSS, ces éléments ne peuvent pas être restitués par les techniques d'assistance.
Chaque contenu porteur d'information (texte et images) visible devra être visible lorsque le CSS est désactivé.
Les boutons-images de l'en-tête permettant d'afficher la fenêtre de recherche ainsi que le menu de navigation en fenêtre réduite ont leur contenu inséré par du CSS.
Figure n°47 : Exemple de contenu porteur d'information inséré via des feuilles de styleFigure n°48 : Exemple de contenu porteur d'information inséré via des feuilles de style
Contenus porteurs d'information insérés via des feuilles de style
OK 28/05/2025
Lorsque des éléments de contenus porteurs d'information sont insérés via du CSS, ces éléments ne peuvent pas être restitués par les techniques d'assistance.
Chaque contenu porteur d'information (texte et images) visible devra être visible lorsque le CSS est désactivé.
Les liens-images vers les réseaux sociaux situés dans le pied de page ont leur contenu inséré par du CSS.
Figure n°49 : Contenus porteurs d'information insérés via des feuilles de style
Critère 10.3 - Dans chaque page web, l’information reste-t-elle compréhensible lorsque les feuilles de styles sont désactivées ?
Conforme
Critère 10.4 - Dans chaque page web, le texte reste-t-il lisible lorsque la taille des caractères est augmentée jusqu’à 200%, au moins (hors cas particuliers) ?
Conforme
Critère 10.5 - Dans chaque page web, les déclarations CSS de couleurs de fond d’élément et de police sont-elles correctement utilisées ?
Conforme
Critère 10.6 - Dans chaque page web, chaque lien dont la nature n’est pas évidente est-il visible par rapport au texte environnant ?
Non applicable
Critère 10.7 - Dans chaque page web, pour chaque élément recevant le focus, la prise de focus est-elle visible ?
L’absence de matérialisation visuelle de l'emplacement du focus clavier est bloquante pour les utilisateurs voyants qui naviguent au clavier, ils ne peuvent pas repérer l'élément interactif sur lequel est positionné le focus à un instant donné.
La feuille de style par défaut du navigateur met en œuvre la propriété "outline" qui répond de façon satisfaisante à ce besoin.
Si l'on altère ou supprime cette propriété, il faut fournir une solution équivalente.
Dans le cas où on l'a supprimée pour des raisons de design mais que l'on a fourni pour le survol souris un traitement visuel suffisamment perceptible, il suffit de le dupliquer pour la prise de focus.
Dans la fenêtre des cookies, plusieurs éléments interactifs ont une prise de focus matérialisée par un changement de couleur ayant un taux de contraste inférieur au minimum requis de 3:1 avec la couleur d'origine, ou bien par l'apparition d'un contour dont le taux de contraste avec l'arrière-plan est inférieur au minimum requis de 3:1.
Figure n°50 : Exemple de prise de focus pas assez perceptible (1,1:1)Figure n°51 : Exemple de prise de focus pas assez perceptible (1,3:1)Figure n°52 : Exemple de prise de focus pas assez perceptible (1,3:1)
Le lien du fil d'Ariane permettant de revenir à la page d'accueil ne présente aucune matérialisation visuelle lorsqu'il reçoit le focus de la navigation au clavier.
Figure n°53 : Exemple de prise de focus non perceptible
Les boutons radio permettant de sélectionner une thématique ne présentent aucune matérialisation visuelle lorsqu'ils reçoivent le focus de la navigation au clavier.
Figure n°54 : Exemple de prise de focus non perceptibleFigure n°55 : Exemple de prise de focus non perceptibleFigure n°56 : Exemple de prise de focus non perceptible
Lorsque le lien du fil d'Ariane permettant de revenir à la page d'accueil reçoit le focus de la navigation au clavier, cela est matérialisé par l'apparition d'un contour dont le contraste avec l'arrière-plan est inférieur au minimum requis de 3:1.
Figure n°57 : Exemple de prise de focus pas assez perceptible (1,8:1)Figure n°58 : Exemple de prise de focus pas assez perceptible (1,4:1)
Lorsque la page est affichée en fenêtre réduite et que le bouton permettant d'afficher ou masquer l'intégralité du texte d'introduction reçoit le focus de la navigation au clavier, cela est matérialisé par l'apparition d'un contour dont le contraste avec l'arrière-plan est inférieur au minimum requis de 3:1.
Figure n°59 : Prise de focus pas assez perceptible (1,8:1)
Lorsque la page est affichée en fenêtre réduite et que le bouton permettant d'afficher ou masquer l'intégralité du texte d'introduction reçoit le focus de la navigation au clavier, il ne présente aucune matérialisation visuelle .
Figure n°60 : Prise de focus non perceptible
Critère 10.8 - Pour chaque page web, les contenus cachés ont-ils vocation à être ignorés par les technologies d’assistance ?
Conforme
Critère 10.9 - Dans chaque page web, l’information ne doit pas être donnée uniquement par la forme, taille ou position. Cette règle est-elle respectée ?
Non applicable
Critère 10.10 - Dans chaque page web, l’information ne doit pas être donnée par la forme, taille ou position uniquement. Cette règle est-elle implémentée de façon pertinente ?
Non applicable
Critère 10.11 - Pour chaque page web, les contenus peuvent-ils être présentés sans perte d’information ou de fonctionnalité et sans avoir recours soit à un défilement vertical pour une fenêtre ayant une hauteur de 256 px, soit à un défilement horizontal pour une fenêtre ayant une largeur de 320 px (hors cas particuliers) ?
Conforme
Critère 10.12 - Dans chaque page web, les propriétés d’espacement du texte peuvent-elles être redéfinies par l’utilisateur sans perte de contenu ou de fonctionnalité (hors cas particuliers) ?
Conforme
Critère 10.13 - Dans chaque page web, les contenus additionnels apparaissant à la prise de focus ou au survol d’un composant d’interface sont-ils contrôlables par l’utilisateur (hors cas particuliers) ?
Non applicable
Critère 10.14 - Dans chaque page web, les contenus additionnels apparaissant via les styles CSS uniquement peuvent-ils être rendus visibles au clavier et par tout dispositif de pointage ?
Non applicable
11. Formulaires
Critère 11.1 - Chaque champ de formulaire a-t-il une étiquette ?
Conforme
Critère 11.2 - Chaque étiquette associée à un champ de formulaire est-elle pertinente (hors cas particuliers) ?
Conforme
Critère 11.3 - Dans chaque formulaire, chaque étiquette associée à un champ de formulaire ayant la même fonction et répétée plusieurs fois dans une même page ou dans un ensemble de pages est-elle cohérente ?
Non applicable
Critère 11.4 - Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés (hors cas particuliers) ?
Conforme
Critère 11.5 - Dans chaque formulaire, les champs de même nature sont-ils regroupés, si nécessaire ?
Dans le formulaire du pied de page permettant de s'inscrire à la newsletter, ainsi que la section « Dans votre boîte mail » de la page « Nous suivre », l'élément <div> contenant la case à cocher d'acceptation de la politique de confidentialité présente un attribut « role="group" » alors qu'il ne correspond qu'à un seul champ et est déjà présent au sein d'un élément <fieldset> : il faut retirer cet attribut.
Figure n°61 : Exemple d'utilisation inadaptée de regroupement de champs
[CTRL] Utilisation inadaptée de regroupement de champs
URBILOG OK (02/06/2025) : Simple remarque
Chaque étape du questionnaire est bien regroupée grâce à un attribut « role="group" », mais l'ensemble du questionnaire est également implémenté au sein d'un élément <fieldset> avec une légende reprenant le titre de la section. Cette imbrication de regroupements de champs n'est pas pertinente, et il est préférable de supprimer l'élément <fieldset> englobant l'ensemble du questionnaire, ainsi que l'élément <legend> correspondant.
Figure n°62 : Utilisation inadaptée de regroupement de champs
Critère 11.6 - Dans chaque formulaire, chaque regroupement de champs de même nature a-t-il une légende ?
Conforme
Critère 11.7 - Dans chaque formulaire, chaque légende associée à un regroupement de champs de même nature est-elle pertinente ?
La légende du regroupement contenant le formulaire du pied de page permettant de s'inscrire à la newsletter a un contenu non adapté et en anglais : il faut changer cette légende afin qu'elle soit en français et explicite sur l'objectif du formulaire.
Figure n°63 : Légende de regroupement non pertinente
Critère 11.8 - Dans chaque formulaire, les items de même nature d’une liste de choix sont-ils regroupés de manière pertinente ?
Non applicable
Critère 11.9 - Dans chaque formulaire, l’intitulé de chaque bouton est-il pertinent (hors cas particuliers) ?
Alternative de bouton ne reprenant pas l'intitulé visible
OK Urbilog 28/05/2025
Le bouton permettant de lancer une recherche a un attribut « title » dont le contenu ne correspond pas à son intitulé visible : il faut le modifier le contenu de cet attribut afin qu'il reprenne bien l'intitulé, comme par exemple « Chercher : Lancer la recherche ».
Figure n°64 : Alternative de bouton ne reprenant pas l'intitulé visible
Les boutons permettant d'accéder aux différentes diapositives du carrousel sont numérotés de 1 à 15, alors que le carrousel ne présente que 5 diapositives différentes, chaque diapositive étant ainsi dupliquée 3 fois. Ce n'est pas une implémentation conforme, et il faut supprimer les boutons en excès de telle sorte qu'il n'y ait que 5 boutons numérotés correspondant aux 5 diapositives différentes.
Lors de chaque étape du questionnaire, un bouton « Valider la réponse » ainsi qu'un bouton « Continuer » sont simultanément présents, ce qui n'est pas pertinent et peut entraîner une confusion chez l'utilisateur. Il faudrait supprimer l'un de ces deux boutons, et donner au bouton restant au moyen d'un attribut « aria-label » une alternative explicite sur son fonctionnement, comme par exemple « Valider la réponse et continuer » pour les étapes intermédiaires, et « Valider la réponse et voir les résultats » pour la dernière étape.
Figure n°66 : Exemple de présence d'un bouton non pertinentFigure n°67 : Exemple de présence d'un bouton non pertinent
Critère 11.10 - Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente (hors cas particuliers) ?
Le message d'erreur s'affichant lorsque la case à cocher permettant d'accepter la politique de confidentialité pour s'inscrire à la newsletter n'est pas sélectionnée doit être relié à la case à cocher, une bonne solution consiste à utiliser un attribut « aria-describedby » :
Le container du message d'erreur doit avoir un attribut « id » ayant une valeur unique dans la page. L'élément de formulaire aura un attribut « aria-describedby » dont le contenu reprendra celui de l'attribut « id » du container du message d'erreur.
Dans le cas présent, l'attribut « aria-describedby » a été placé sur l'élément <div> englobant la case à cocher, ce qui entraîne une restitution incorrecte : il faut déplacer cet attribut sur l'élément <input> correspondant à la case à cocher.
Figure n°68 : Exemple de message d'erreur non relié au champ concernéFigure n°69 : Exemple de message d'erreur non relié au champ concerné
Dans le formulaire du pied de page d'inscription à la newsletter, seul le champ de saisie de l'adresse e-mail présente un astérisque indiquant son caractère obligatoire, tandis que la case à cocher d'acceptation de la politique de confidentialité n'en présente pas.
Comme le formulaire ne présente que ces deux champs, il serait préférable de supprimer l'astérisque associé au champ de saisie et de remplacer la mention « *champs obligatoires » par « Tous les champs sont obligatoires ».
Figure n°70 : Absence d'indication d'un champ obligatoire
La notification concernant le caractère obligatoire des champs de saisie des formulaires de la page est implémentée à la fin des formulaires correspondants, ce qui n'est pas conforme : cette notification doit être implémentée au tout début du formulaire.
Par ailleurs, comme tous les champs de ces formulaires sont obligatoires, il serait préférable de supprimer les astérisques associés aux champs de saisie et de remplacer les mentions « *champs obligatoires » par « Tous les champs sont obligatoires ».
Figure n°71 : URBILOG OK - Exemple de champs obligatoires mal indiquésFigure n°72 : URBILOG OK - Exemple de champs obligatoires mal indiqués
Les différentes étapes du formulaire présentent chacune un astérisque indiquant leur caractère obligatoire, mais leur signification n'est pas expliquée, ce qui n'est pas conforme. Comme chaque étape consiste en un unique groupement de cases à cocher ou boutons radio, l'indication de leur caractère obligatoire n'est pas nécessaire et il serait préférable de supprimer l'astérisque.
Figure n°73 : Exemple de champs obligatoires mal indiqués
Le message d'erreur s'affichant lorsque l'utilisateur tente de passer à l'étape suivante sans sélectionner de réponse contient simplement « Ce champ est obligatoire ». Ce message n'est pas pertinent car il est relié à toutes les cases à cocher ou boutons radio de l'étape, et peut porter à confusion : un meilleur message serait par exemple « Veuillez sélectionner au moins une réponse » pour les cases à cocher, ou « Veuillez sélectionner une réponse » pour les boutons radio.
Figure n°74 : Message d'erreur non pertinent
Critère 11.11 - Dans chaque formulaire, le contrôle de saisie est-il accompagné, si nécessaire, de suggestions facilitant la correction des erreurs de saisie ?
Lorsque la saisie d'un champ nécessite le respect d'un format particulier, il faut que le message d'erreur affiché par le contrôle de saisie en fournisse une suggestion, par exemple « L'adresse de courriel doit être du format vous@domaine.com ».
Les messages d'erreur s'affichant en cas de saisie incorrecte dans les champs de saisie de l'adresse e-mail doivent fournir une suggestion de format.
Figure n°75 : Exemple d'absence de suggestion de saisieFigure n°76 : Exemple d'absence de suggestion de saisie
Critère 11.12 - Pour chaque formulaire qui modifie ou supprime des données, ou qui transmet des réponses à un test ou à un examen, ou dont la validation a des conséquences financières ou juridiques, les données saisies peuvent-elles être modifiées, mises à jour ou ou récupérées par l’utilisateur ?
Non applicable
Critère 11.13 - La finalité d’un champ de saisie peut-elle être déduite pour faciliter le remplissage automatique des champs avec les données de l’utilisateur ?
Les champs de saisie correspondant au nom, prénom et à l'adresse e-mail de l'utilisateur doivent avoir un attribut « autocomplete » avec respectivement la valeur « family-name », « given-name » et « email ».
Figure n°77 : Exemple d'absence d'attribut autocompleteFigure n°78 : Exemple d'absence d'attribut autocompleteFigure n°79 : Exemple d'absence d'attribut autocomplete
12. Navigation
Critère 12.1 - Chaque ensemble de pages dispose-t-il de deux systèmes de navigation différents, au moins (hors cas particuliers) ?
Conforme
Critère 12.2 - Dans chaque ensemble de pages, le menu et les barres de navigation sont-ils toujours à la même place (hors cas particuliers) ?
Conforme
Critère 12.3 - La page « plan du site » est-elle pertinente ?
Conforme
Critère 12.4 - Dans chaque ensemble de pages, la page « plan du site » est-elle atteignable de manière identique ?
Conforme
Critère 12.5 - Dans chaque ensemble de pages, le moteur de recherche est-il atteignable de manière identique ?
Non applicable
Critère 12.6 - Les zones de regroupement de contenus présentes dans plusieurs pages web (zones d’en-tête, de navigation principale, de contenu principal, de pied de page et de moteur de recherche) peuvent-elles être atteintes ou évitées ?
Conforme
Critère 12.7 - Dans chaque page web, un lien d’évitement ou d’accès rapide à la zone de contenu principal est-il présent (hors cas particuliers) ?
Conforme
Critère 12.8 - Dans chaque page web, l’ordre de tabulation est-il cohérent ?
L'ordre de tabulation doit suivre l'ordre des éléments interactifs dans le flux HTML et dans l'ordre d'affichage visuel dans la page.
Par défaut il est pertinent, il peut toutefois être altéré par la présence d’attributs « tabindex » avec des valeurs supérieures à « 0 », par du JavaScript, ou par du positionnement CSS.
Dans plusieurs sections de la page listant des articles, le lien permettant d'accéder à l'ensemble des articles de la thématique correspondante est affiché avant les liens vers les articles individuels, mais est parcouru par la navigation au clavier après ceux-ci.
Figure n°80 : Exemple d'ordre de tabulation non cohérentFigure n°81 : Exemple d'ordre de tabulation non cohérentFigure n°82 : Exemple d'ordre de tabulation non cohérentFigure n°83 : Exemple d'ordre de tabulation non cohérentFigure n°84 : Exemple d'ordre de tabulation non cohérentFigure n°85 : Exemple d'ordre de tabulation non cohérent
Critère 12.9 - Dans chaque page web, la navigation ne doit pas contenir de piège au clavier. Cette règle est-elle respectée ?
Conforme
Critère 12.10 - Dans chaque page web, les raccourcis clavier n’utilisant qu’une seule touche (lettre minuscule ou majuscule, ponctuation, chiffre ou symbole) sont-ils contrôlables par l’utilisateur ?
Non applicable
Critère 12.11 - Dans chaque page web, les contenus additionnels apparaissant au survol, à la prise de focus ou à l’activation d’un composant d’interface sont-ils si nécessaire atteignables au clavier ?
Conforme
13. Consultation
Critère 13.1 - Pour chaque page web, l’utilisateur a-t-il le contrôle de chaque limite de temps modifiant le contenu (hors cas particuliers) ?
Non applicable
Critère 13.2 - Dans chaque page web, l’ouverture d’une nouvelle fenêtre ne doit pas être déclenchée sans action de l’utilisateur. Cette règle est-elle respectée ?
Conforme
Critère 13.3 - Dans chaque page web, chaque document bureautique en téléchargement possède-t-il, si nécessaire, une version accessible (hors cas particuliers) ?
Document bureautique téléchargeable non accessible
Lorsqu'un document bureautique est proposé au téléchargement, il doit être accessible. Si ce n'est pas le cas, une version accessible du document doit être proposée, si nécessaire, dans un format différent. Par exemple en HTML pour un document PDF non accessible.
Suivant les formats de document, il est possible de les modifier pour les rendre accessibles.
Afin de rendre accessible un document PDF, il est nécessaire de passer par le logiciel « Adobe Acrobat Reader DC » dans le but d'accéder aux options de balisages ou encore à l'ordre de lecture des éléments.
Il est préférable de proposer le document au téléchargement pour que l'utilisateur puisse l'ouvrir avec le lecteur de document qui lui convient. Pour rappel, pour les utilisateurs d'un lecteur d'écran, la consultation des documents PDF au travers d'un navigateur internet peut varier d'un navigateur à l'autre.
Note : S'il s'agit d'un document texte de type Word, il est primordial de ne pas faire « Imprimer → Imprimer au format PDF », mais « Exporter → Format PDF » (ou bien « Enregistrer sous → .pdf ») en veillant bien à activer l'option d'accessibilité « PDF/A » lors de l'exportation.
Le communiqué de presse disponible au téléchargement sur la page n'est pas accessible, il faut proposer une version alternative accessible de ce document.
Figure n°86 : Document bureautique téléchargeable non accessible
Critère 13.4 - Pour chaque document bureautique ayant une version accessible, cette version offre-t-elle la même information ?
Non applicable
Critère 13.5 - Dans chaque page web, chaque contenu cryptique (art ASCII, émoticône, syntaxe cryptique) a-t-il une alternative ?
Non applicable
Critère 13.6 - Dans chaque page web, pour chaque contenu cryptique (art ASCII, émoticône, syntaxe cryptique) ayant une alternative, cette alternative est-elle pertinente ?
Non applicable
Critère 13.7 - Dans chaque page web, les changements brusques de luminosité ou les effets de flash sont-ils correctement utilisés ?
Non applicable
Critère 13.8 - Dans chaque page web, chaque contenu en mouvement ou clignotant est-il contrôlable par l’utilisateur ?
Non applicable
Critère 13.9 - Dans chaque page web, le contenu proposé est-il consultable quelle que soit l’orientation de l’écran (portrait ou paysage) (hors cas particuliers) ?
Conforme
Critère 13.10 - Dans chaque page web, les fonctionnalités utilisables ou disponibles au moyen d’un geste complexe peuvent-elles être également disponibles au moyen d’un geste simple (hors cas particuliers) ?
Non applicable
Critère 13.11 - Dans chaque page web, les actions déclenchées au moyen d’un dispositif de pointage sur un point unique de l’écran peuvent-elles faire l’objet d’une annulation (hors cas particuliers) ?
Conforme
Critère 13.12 - Dans chaque page web, les fonctionnalités qui impliquent un mouvement de l’appareil ou vers l’appareil peuvent-elles être satisfaites de manière alternative (hors cas particuliers) ?
[CTRL] Images porteuses d'information sans alternative textuelle
URBILOG OK (02/06/2025): Passage en simple remarque
Chaque image porteuse d'information doit avoir une alternative textuelle transmettant une information équivalente aux aides techniques telles que les synthèses vocales.
Les logos situés dans les volets d'accueil et de paramétrage de la fenêtre des cookies doivent avoir un attribut « alt » retranscrivant leur contenu textuel, comme par exemple « Logo Assurance Prévention : Ensemble agir, chaque jour prévenir ».
Image devant indiquer la présence d’une description détaillée
OK Urbilog 06/06/2025
Le texte mis en alternative est supposé être la description détaillée car elle est trop lourde en terme de vocalisation. L'alternative attendue est "Affiche de prévention sur le changement d'heure - Voir la description détaillée en dessous" et ajouter le contenu de la fiche (mise dans l'attribut alt) en masquage accessible afin de ne surcharger ni la page, ni la vocalisation de l'image.
Chaque image porteuse d'information doit avoir une alternative textuelle transmettant une information équivalente aux aides techniques telles que les synthèses vocales.
L'image d'annonce sur le changement d'heure nécessite une description détaillée (voir critère 1.6). L'attribut « alt » devra indiquer la présence de cette description.
Par exemple « présence d'une description détaillée après l'image » ou encore « présence d'un lien vers la description détaillée après l'image ».