La page d’accueil des services de communication au public en ligne affiche obligatoirement l’une des mentions suivantes :

• « Accessibilité : totalement conforme » si tous les critères de contrôle du RGAA sont respectés ;
• « Accessibilité : partiellement conforme » si au moins 50 % des critères de contrôle du RGAA sont respectés ;
• « Accessibilité : non conforme » s’il n’existe aucun résultat d’audit en cours de validité permettant de mesurer le respect des critères ou si moins de 50 % des critères de contrôle du RGAA sont respectés.

Cette mention peut être cliquable et conduire vers la page Accessibilité ou vers la déclaration d’accessibilité.

Le schéma pluriannuel, d’une durée maximum de trois ans, présente la politique de l’entité concernée en matière d’accessibilité numérique. A ce titre, il contient des informations sur :

• la prise en compte de l’accessibilité numérique dans la stratégie numérique de l’entité et dans sa politique en faveur de l’intégration des personnes en situation de handicap ;
• la position fonctionnelle et les missions du référent accessibilité numérique de l’entité ;
• les ressources humaines et financières affectées à l’accessibilité numérique ;
• la prise en compte des compétences ou connaissances requises dans les fiches de poste et dans les processus de recrutement ;
• les actions de formation et de sensibilisation des agents ;
• la mise en oeuvre des ressources et expertises externes auxquelles il est, le cas échéant, fait appel, des moyens techniques et de l’outillage pour gérer et tester l’accessibilité numérique l’organisation interne pour mettre en oeuvre les obligations d’accessibilité des services de communication au public en ligne, y compris les modalités de contrôle des services numériques et d’organisation pour le traitement des demandes des usagers ;
• l’intégration de l’accessibilité numérique dans les clauses contractuelles (appels d’offres et devis), des critères de notation et de sélection des prestataires et les procédures de recette et, le cas échéant, dans les conventions établies avec leurs opérateurs, délégataires ou partenaires.

Il présente également les travaux de mise en conformité des services de communication au public en ligne de l’entité, notamment :

• la prise en compte de l’accessibilité numérique dans les nouveaux projets ;
• la prise en compte des personnes en situation de handicap dans les tests utilisateurs ;
• les évaluations (ou audits) de conformité prévus pour l’ensemble des services de communication ;
• les mesures correctives qui seront prises pour traiter les contenus non accessibles, y compris un calendrier de mise en oeuvre de ces mesures, tenant compte du caractère prioritaire des contenus les plus consultés et des services les plus utilisés ;
• les mesures d’accessibilité non obligatoires, notamment l’accès aux contenus audios et vidéos en langue des signes, la traduction de certains contenus en langage simplifié et tout autre mesure permettant de prendre en compte des critères de niveau triple AAA, des normes internationales, listés en annexe de la norme de référence ;
• le bilan des plans d’actions annuels.

Publication du schéma

Le schéma pluriannuel et le plan d’action de l’année en cours sont accessibles en ligne sur le site de l’entité. Des liens vers ces documents figurent au sein de la déclaration d’accessibilité des services de communication au public en ligne dépendant de l’entité. Ils sont publiés dans un format accessible.

La charte graphique est cohérente sur l’ensemble du site.

Le bloc Marque, la police et les couleurs sont conformes au système de design de l’État.

Appliquer des propriétés communes de style, de couleur, de graisse, de casse, de soulignement aux ensembles de liens de même nature.

L’apparence et le libellé des boutons d’action de même nature sont identiques sur toutes les pages.

Références

• Système de design de l’État : Éléments d’interface
• La marque de l’État
• Règles Opquast : OPQ 175, OPQ 133

L’en-tête et le pied de page doivent être présents sur toutes les pages, y compris les pages d’erreur.

L’emplacement, la forme, le contenu et le comportement des éléments principaux de l’en-tête et du pied de page doivent être identiques sur toutes les pages du site du site et conformes au Système de design de l’État.

Références

• Système de design de l’État :

  • Composant En-tête
  • Composant Pied de page

Le Système de design de l’État met à disposition une sélection d’icônes issue de la librairie Remix Icons (libre de droits). Il s’agit pour l’essentiel des icônes utilisées par les composants du Système de design de l’État. Si l’icône recherchée est absente de notre sélection, il est possible de compléter en recherchant en priorité dans Remix Icons.

Références

• Système de design de l’État : Icônes

Une page « Mentions légales » doit être présente sur le site et accessible depuis toutes les pages.

Les mentions légales doivent fournir les informations suivantes :

• Informations sur l’éditeur.
• Informations sur le traitement des données personnelles.
• Informations sur la présence de liens hypertextes (par exemple autoriser des sites tiers à effectuer des liens de renvoi vers le site et sensibiliser l’internaute aux liens contenus sur le site, qui n’engagent pas la responsabilité de l’éditeur).
• Informations sur les droits de copie et de réutilisation des divers éléments du site.

Les conditions d’utilisation des lettres d’information doivent figurer sur la page « Mentions légales » du site émetteur.

Références

• Règles Opquast : OPQ 2

Afin d’évaluer la conformité du service de communication au public en ligne avec la norme de référence, l’organisme doit conduire un audit d’accessibilité.

L’audit (ou évaluation) peut être effectué par l’organisme lui-même (auto-évaluation) ou par un tiers. L’évaluation est réalisée sur un échantillon de pages représentatif du service de communication au public en ligne. La vérification de la conformité des pages de l’échantillon avec les critères applicables s’effectue à l’aide des critères de contrôle du RGAA qui contiennent des tests techniques.

La phase finale de l’audit est la déclaration d’accessibilité qui rend compte de la conformité des services de communication au public en ligne avec les règles applicables.

La déclaration d’accessibilité doit être publiée sur le site dans un format accessible.

Elle comporte :

• Un signalement des contenus non accessibles, distingués selon qu’il s’agit de non-conformité avec le RGAA, de contenus exemptés ou de contenus soumis à dérogation pour charge disproportionnée. Dans ce dernier cas,les dérogations doivent être expliquées et motivées. Le signalement est assorti, le cas échéant, d’une présentation des alternatives accessibles prévues.
• Une information désignant les dispositifs d’assistance et de contact : un mécanisme accessible (adresse électronique ou formulaire) pour permettre à toute personne de signaler à l’organisme concerné tout défaut d’accessibilité et à une personne handicapée de demander les informations correspondantes ou une solution alternative accessible.
• La mention de la faculté pour la personne concernée de saisir le Défenseur des droits, en cas d’absence de réponse ou de solution, une fois les démarches effectuées via le mécanisme mentionné ci-dessus.

Indiquer dans la page d’accueil, ou au sein de la page des mentions légales, dans la page d’à propos, d’aide, ou encore dans les conditions générales, un moyen de contacter (e-mail, téléphone, fax…) le responsable des réclamations.

Références

• Règles Opquast : OPQ 107

Toute création de site ou refonte majeure doit faire l’objet d’une demande d’agrément préalable, avant dépôt du nom de domaine, auprès du SIG à l’adresse suivante : comgouv.sig@pm.gouv.fr. Il en va de même pour les URL de communication (ou alias) et domaines de messagerie, quelle que soit l’extension du nom de domaine choisie (.gouv.fr, .fr, .com…).

Indiquer les horaires et tarifs de fonctionnement des services mis à la disposition des utilisateurs dans au moins une des pages suivantes : la page d’accueil, la page consacrée aux mentions légales, la page d’aide ou encore dans les pages consacrées aux conditions générales d’utilisation ou de vente.

Références

• Règles Opquast : OPQ 104

Indiquer le délai chiffré de réponse prévu pour chaque formulaire de demande d’information pour :

• Informer les utilisateurs sur les délais chiffrés de réponse.
• Limiter les risques de relance de la part des utilisateurs.
• Rassurer sur la capacité à prendre en compte les demandes.

Références

• Règles Opquast : OPQ 103

Un suivi rigoureux des certificats de sécurité utilisés sur le site et une anticipation des dates de renouvellement contribuent à la sécurisation des transactions.

Références

• Règles Opquast : OPQ 193

Une page d’erreur 404 personnalisée informe l’utilisateur sur l’erreur rencontrée, sur la continuité de fonctionnement du serveur et lève le doute sur un éventuel problème lié à sa connexion.

Une page d’interdiction 403 personnalisée :

• Rassure l’internaute sur le fait qu’il est toujours dans le même site ;
• Permet à l’administrateur du site de mettre des éléments de guidage pour l’utilisateur ;
• Informe l’utilisateur sur l’erreur rencontrée, sur la continuité de fonctionnement du serveur et met hors de cause sa connexion.

Le menu principal de navigation figure sur ces pages d’erreur.

Références

• Règles Opquast : OPQ 216, OPQ 217, OPQ 218

Configurer le serveur de façon à ce qu’il gère les adresses sans www (acheminement) permet aux utilisateurs de rejoindre le site même lorsqu’ils oublient de taper le préfixe www.

Références

• Règles Opquast : OPQ 211

Il est obligatoire de proposer un mécanisme d’aide aux usagers comprenant au minimum une foire aux questions. La FAQ doit répondre aux principales questions posées par les utilisateurs.

L’usager a accès au sens de la démarche qu’il effectue ; il complètera d’autant plus volontiers les différentes rubriques qu’il en comprend l’utilité. Des exemples peuvent également l’aider, en s’assurant qu’ils seront bien compris comme des exemples et non comme des mentions à reproduire.

La foire aux questions (FAQ) et/ou la page d’aide doivent être accessibles sans que l’usager n’ait à s’authentifier. En complément, les formulaires en ligne ont l’avantage de pouvoir fournir des explications à l’usager au fur et à mesure qu’il progresse dans le remplissage.

Il convient également de préciser l’assistance dont l’usager peut bénéficier en cas de difficulté. Il faut dans tous les cas veiller à ce que l’usager soit correctement orienté dès sa première demande.

En outre, une aide contextuelle est également apportée dans les formulaires pour le remplissage des champs.

Fournir à l’utilisateur un mécanisme lui permettant de désactiver globalement toutes les connexions actives de ses différents appareils au service ou à l’espace privé.

Références

• Règles Opquast : OPQ 22

L’intégration du dispositif FranceConnect à un site permet à l’usager de s’authentifier plus facilement tout en sécurisant son identification.

Le dispositif FranceConnect permet aux usagers d’accéder à différents services publics en ligne en s’appuyant sur des comptes vérifiés existants sans devoir créer de nouveaux comptes. Cela vise à limiter les identifiants et mots de passe.

Après l’authentification, FranceConnect orchestre la circulation des données personnelles de l’usager, avec son consentement, dans le cadre d’une démarche qu’il initie.

Mettre en place un système de type authentification à double facteur ou autre authentification forte, et non une identification simple de type identifiant/mot de passe.

Références

• Règles Opquast : OPQ 21, OPQ 18

Le site propose au moins deux moyens de contact différents.

L’objectif est d’optimiser les possibilités de retour d’information de la part des utilisateurs.

L’utilisation d’un formulaire comme l’un des moyens de contact est obligatoire, sauf problématique justifiée.

Références

• Règles Opquast : OPQ 102

Avant activation du compte créé en ligne, envoyer une demande de confirmation automatique à l’adresse e-mail correspondant à celui-ci.

Références

• Règles Opquast : OPQ 17

La procédure d’accès, de rectification et de suppression des données personnelles est décrite dans une section de contenu dédiée.

Si le site propose un espace personnel ou abonné, il est possible de télécharger les contenus personnels dans un format bureautique courant.

Références

• Règles Opquast : OPQ 15, OPQ 20

Une démarche en ligne ne doit pas demander de fournir des informations ou des justificatifs qu’une autre administration possède déjà. Sous réserve de l’accord de l’usager, les administrations s’échangent ces données entre elles.

De manière générale, les formalités administratives courantes doivent demander peu de temps. Il faut donc veiller à ne pas mettre en œuvre une procédure complexe pour des effets dérisoires. Sauf nécessité absolue, il faut proscrire les demandes d’informations supposant de la part de l’usager une recherche trop importante, en particulier les demandes de pièces justificatives dont la réunion impose souvent de lourdes contraintes à l’usager sans réel bénéfice pour le service gestionnaire.

Utiliser, pour les vignettes de prévisualisation d’images, des versions spécifiques de celles-ci et non les images originales redimensionnées via leurs attributs HTML ou leurs propriétés CSS.

Références

• Règles Opquast : OPQ 114

Depuis fin 2016, le trafic internet mobile a officiellement dépassé celui du trafic internet fixe dans le monde. De ce fait, il est indispensable de développer des services en ligne dont l’affichage s’adapte selon la taille de l’écran utilisé.

De manière générale, l’expérience de l’usager doit être homogène et cohérente sur l’ensemble des canaux utilisés ; elle doit pouvoir être identique selon le canal choisi et être sans coutures, c’est-à-dire que l’usager doit avoir la possibilité de passer d’un canal à l’autre sans difficultés et avec uniformité (ordinateur, mobile, tablette, mais aussi téléphone, guichet...).

Pour chaque page web,

• lorsque le contenu dont le sens de lecture est horizontal est affiché dans une fenêtre réduite à une largeur de 320 pixels, l’ensemble des informations et des fonctionnalités sont disponibles sans aucun défilement horizontal.
• lorsque le contenu dont le sens de lecture est vertical est affiché dans une fenêtre réduite à une hauteur de 256 pixels, l’ensemble des informations et des fonctionnalités sont disponibles sans aucun défilement vertical.

Références

• RGAA : RGAA 10.11

L’adresse postale complète et le numéro de téléphone des sociétés et organisations sont accessibles depuis toutes les pages du site ou dans une page Contact ou À propos, accessible directement depuis chaque page du site.

Références

• Règles Opquast : OPQ 100

Les adresses électroniques cliquables (attribut « mailto ») sont interdites pour des raisons de sécurité et de compatibilité avec le poste de travail de l’utilisateur sur l’ensemble des pages du site.

Objectif : laisser à l’utilisateur le contrôle de l’interface sonore et visuelle lors de la consultation du site ; ne pas surprendre l’utilisateur par la diffusion inattendue d’un contenu audio ; ne pas imposer à l’utilisateur le déclenchement d’un contenu animé.

Solution technique : ne pas mettre en place des contenus audio ou vidéo dont le démarrage est automatique et sans action explicite de l’utilisateur en ce sens.

Pour chaque page dont l’accès est précédé par une animation : Vérifier qu’il est possible d’outrepasser l’animation sans devoir attendre la fin de son déroulement, soit par le biais d’un lien d’accès direct au site, soit par un contrôle permettant son arrêt.

Références

• RGAA : RGAA 4.10, RGAA 13.7, RGAA 13.8.
• Règles Opquast : OPQ 119, OPQ 120, OPQ 121, OPQ 122

Dans chaque page Web, chaque image animée (balise img, svg, canvas, embed ou object) qui provoque un changement brusque de luminosité ou un effet de flash vérifie-t-elle une de ces conditions ?

• La fréquence de l’effet est inférieure à 3 par seconde
• La surface totale cumulée des effets est inférieure ou égale à 21 824 pixels

Dans chaque page Web, chaque script qui provoque un changement brusque de luminosité ou un effet de flash vérifie-t-il une de ces conditions ?

• La fréquence de l’effet est inférieure à 3 par seconde
• La surface totale cumulée des effets est inférieure ou égale à 21 824 pixels

Dans chaque page Web, chaque mise en forme CSS qui provoque un changement brusque de luminosité ou un effet de flash vérifie-t-elle une de ces conditions ?

• La fréquence de l’effet est inférieure à 3 par seconde
• La surface totale cumulée des effets est inférieure ou égale à 21 824 pixels

Références

• RGAA : RGAA 13.7

Les contenus publicitaires ou sponsorisés sont identifiés comme tels.

Références

• Règles Opquast : OPQ 8

La date de publication ou de mise à jour de l’article doit être indiquée sur la page de l’article en question. Utiliser l’élément HTML time pour baliser les dates de publication et de mise à jour du contenu affichées sur le site, et son attribut datetime pour indiquer celles-ci au format standard requis par la spécification HTML5.

Si une possibilité d’imprimer l’article est proposée, une feuille de style dédiée à l’impression doit être appliquée. Celle-ci reprend au moins les éléments suivants :

• l’émetteur du site (y compris son identifiant visuel) ;
• la date de l’impression ;
• l’URL de la page ;
• le chemin de la page dans le site (fil d’Ariane).

Associer à chaque contenu qui le nécessite (article, actualité, produit, etc.) sa date de publication affichée.

Références

• Règles Opquast : OPQ 6, OPQ 224

Le site doit mettre à disposition de l’usager un système de glossaire (page ou infobulle) définissant les termes complexes utilisés selon un des moyens suivants :

• Une section, une page ou une série de pages de glossaire explicitant le vocabulaire technique ou sectoriel utilisé dans le contenu du site. Ce glossaire devra être disponible directement depuis chaque page du site.
• Un mécanisme permettant à l’utilisateur d’accéder à la définition des termes du vocabulaire technique ou sectoriel, depuis au moins leur première occurrence dans chaque page du site.
• Expliciter les sigles, acronymes ou abréviations (soit dans le texte soit au moyen d’une balise abbr)

Références

• Règles Opquast : OPQ 5, OPQ 7

La politique de confidentialité et de respect de la vie privée est accessible depuis toutes les pages.

Références

• Règles Opquast : OPQ 14

Les comptes ou abonnements ouverts en ligne peuvent être fermés par le même moyen.

Références

• Règles Opquast : OPQ 19

Afficher de manière structurée, dans le contexte immédiat du graphique, toutes les données numériques qu’il représente, par exemple sous forme de tableau de données (ou fournir dans le contexte immédiat du graphique un lien vers un contenu du même type).

Références

• Règles Opquast : OPQ 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, la saisie des données vérifie-t-elle une de ces conditions ?

• L’utilisateur peut modifier ou annuler les données et les actions effectuées sur ces données après la validation du formulaire.
• L’utilisateur peut vérifier et corriger les données avant la validation d’un formulaire en plusieurs étapes.
• Un mécanisme de confirmation explicite, via une case à cocher (balise <input> de type checkbox ou balise ayant un attribut WAI-ARIA role="checkbox") ou une étape supplémentaire, est présent.

Pour chaque formulaire, la suppression des données à caractère financier, juridique ou personnelle vérifie-t-elle une de ces conditions ?

• Un mécanisme permet de récupérer les données supprimées ou modifiées par l’utilisateur.
• Un mécanisme de demande de confirmation explicite de la suppression ou de la modification, via un champ de formulaire ou une étape supplémentaire, est proposé.

Références

• RGAA : RGAA 11.12

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 est-elle cohérente ?

Chaque étiquette associée à un champ de formulaire ayant la même fonction et répétée dans un ensemble de pages est-elle cohérente ?

Références

• RGAA : RGAA 11.3

La création d’un mot de passe par l’utilisateur fait l’objet d’un mécanisme de prévention des erreurs de saisie.

Références

• Règles Opquast : OPQ 73

Afficher un bouton associé à un script qui bascule la valeur de l’attribut type du champ de saisie entre les valeurs password et text.

Références

• Règles Opquast : OPQ 74

Il convient de fournir à l’utilisateur un retour immédiat et explicite sur l’action qu’il vient d’effectuer afin d’écarter tout doute.

Références

• RGAA : RGAA 7.5
• Règles Opquast : OPQ 83

• Les opérations relatives aux mots de passe peuvent être effectuées intégralement en ligne.
• Le mot de passe peut être personnalisé dès la création du compte.
• Le mot de passe peut être modifié ou réinitialisés depuis la gestion du compte utilisateur.
• L’utilisateur est averti avant la soumission du formulaire du degrés de sécurisation attendu.

Références

• Règles Opquast : OPQ 196, OPQ 197, OPQ 198, OPQ 199

La création de compte est possible sans recours à un système d’identification tiers.

Références

• Règles Opquast : OPQ 16

Une description des différentes pages doit être présentée en amont du formulaire, de même qu’une page de synthèse récapitulant les différentes informations saisies doit être intercalée avant la soumission finale du formulaire.

Les différentes étapes de la démarche en ligne sont visibles à tout moment, l’usager peut se déplacer et sait à quelle étape il en est. Le dernier écran présenté à l’usager avant transmission de sa demande est un récapitulatif des informations saisies et prêtes à être communiquées à l’administration.

Références

• Règles Opquast : OPQ 81

Les différentes étapes de la démarche en ligne sont visibles à tout moment, l’usager peut se déplacer et sait à quelle étape il en est. Le dernier écran présenté à l’usager avant transmission de sa demande est un récapitulatif des informations saisies et prêtes à être communiquées à l’administration.

Pour tout processus complexe, afficher avant la première étape de celui-ci la liste des documents ou informations spécifiques qui devront être fournis par l’utilisateur pour finaliser le processus.

Références

• Règles Opquast : OPQ 84, OPQ 85

Dans le cas de processus complexes, l’étape en cours est indiquée sur chaque page. L’utilisateur peut déterminer la page sur laquelle il se trouve et le nombre d’étapes restantes.

Les différentes étapes de la démarche en ligne sont visibles à tout moment.

L’étape en cours est indiquée :

• Dans le titre de page (balise title) ;
• Dans le contenu de page, sous la forme d’une mise en évidence dans le chemin d’étapes en tête de page ou de formulaire.

Références

• Règles Opquast : OPQ 86

Un système de navigation dédié au formulaire doit permettre à tout moment à l’utilisateur de revenir à une étape précédente et :

• de pouvoir modifier sa saisie si les étapes déjà franchies ne sont pas impactées ;
• ou d’être averti avant la validation d’une étape ne pouvant être modifiée ;
• ou d’être averti que la modification d’une étape antérieure annule la saisie des étapes suivantes.

Références

• Règles Opquast : OPQ 87

Chaque script qui génère ou contrôle un composant d’interface vérifie-t-il ces conditions ?

• Le composant possède un nom pertinent.
• Le nom accessible du composant contient au moins l’intitulé visible.
• Le composant possède un rôle pertinent.

Dans chaque formulaire, l’intitulé de chaque bouton est-il pertinent (hors cas particuliers)?

• L’intitulé de chaque bouton est-il pertinent ?

  • S’il est présent, le contenu de l’attribut WAI-ARIA aria-label est pertinent.
  • S’il est présent, le passage de texte lié au bouton via un attribut WAI-ARIA aria-labelledby est pertinent.
  • S’il est présent, le contenu de l’attribut value d’une balise <input> de type submit,reset ou button est pertinent.•S’il est présent, le contenu de la balise <button> est pertinent.
  • S’il est présent, le contenu de l’attribut alt d’une balise <input> de type image est pertinent.
  • S’il est présent, le contenu de l’attribut title est pertinent.

• Chaque bouton affichant un intitulé visible vérifie-t-il ces conditions (hors cas particuliers) ?

  • S’il est présent, le contenu de l’attribut WAI-ARIA aria-label contient au moins l’intitulé visible.
  • S’il est présent, le passage de texte lié au bouton via un attribut WAI-ARIA aria-labelledby contient au moins l’intitulé visible.
  • S’il est présent, le contenu de l’attribut value d’une balise <input> de type submit,reset ou button contient au moins l’intitulé visible.
  • S’il est présent, le contenu de la balise <button> contient au moins l’intitulé visible.
  • S’il est présent, le contenu de l’attribut alt d’une balise <input> de type image contient au moins l’intitulé visible.
  • S’il est présent, le contenu de l’attribut title contient au moins l’intitulé visible.

Références

• RGAA : RGAA 7.1.3, RGAA 11.9

Mettre en place une prévisualisation des informations saisies avant la soumission définitive du formulaire, avec possibilité de les modifier.

Références

• Règles Opquast : OPQ 10

Chaque page doit faire apparaître le favicon « Marianne » proposé par le Système de Design de l'État.

Références

• Système de design de l’État : Icône de favoris

L’identité de l’auteur, de la société ou de l’organisation et l’identité de la personne ou du service responsable des contenus sont indiquées.

• Indiquer, au moins sur une page et idéalement sur chaque page, le nom de l’auteur, de l’entité ou de la société qui propose le service
• Indiquer le nom d’une personne physique responsable des contenus sur le site.

Si le nom du site est identique à celui de l’entité qui le propose, ce qui est relativement fréquent, notamment pour les entreprises, la mention de ce nom dans le logo ou la baseline suffit à respecter la bonne pratique.

Références

• Règles Opquast : OPQ 96, OPQ 109

Dans l’ensemble du site, et notamment dans la page d’accueil, la page des mentions légales, la page d’à propos, d’aide ou d’accessibilité ou encore dans les pages consacrées aux conditions générales de vente ou aux conditions de livraison ou de remboursement : Vérifier la présence d’un lien vers chaque standard ou référentiel que le site ou le service déclare respecter.

Références

• Règles Opquast : OPQ 110

Faire figurer sur la page d’accueil un message d’avertissement explicite sur la nature des contenus et le public auquel ils sont destinés ou réservés.

Références

• Règles Opquast : OPQ 95

Dans chaque ensemble de pages, chaque page ayant un menu ou barre de navigation vérifie-t-elle ces conditions (hors cas particuliers) ?

• Le menu et les barres de navigation sont toujours à la même place dans la présentation.
• Le menu et les barres de navigation se présentent toujours dans le même ordre relatif dans le code source.
• Le menu et les barres de navigation sont conformes au Système de design de l’État

Références

• Système de design de l’État :

  • Navigation principale
  • Menu latéral
• RGAA : RGAA 12.2
• Règles Opquast : OPQ 153

Chaque ensemble de pages vérifie-t-il une de ces conditions (hors cas particuliers) ?

• Un menu de navigation et un plan du site sont présents.
• Un menu de navigation et un moteur de recherche sont présents.
• Un moteur de recherche et un plan du site sont présents.

Les menu de navigation, plan du site et moteur de recherche sont conformes au Système de design de l’État

Références

• Les composants du Système de design de l’État
• RGAA : RGAA 12.1
• Règles Opquast : OPQ 163, OPQ 166

Dans chaque mail adressé à l’utilisateur, y compris ceux en "no-reply", indiquer à l’utilisateur au moins un moyen de contact : adresse, téléphone, formulaire en ligne, mail, etc.

Références

• Règles Opquast : OPQ 106

Chaque lien texte, lien image, lien composite ou lien SVG vérifie-t-il une de ces conditions (hors cas particuliers) ?

• L’intitulé de lien seul permet d’en comprendre la fonction et la destination.
• L’intitulé du lien additionné au contexte du lien permet d’en comprendre la fonction et la destination.

Références

• RGAA : RGAA 6.1.1, RGAA 6.1.2, RGAA 6.1.3, RGAA 6.1.4
• Règles Opquast : OPQ 131, OPQ 132

Dans chaque page web des raccourcis doivent être proposés pour faciliter la navigation au clavier et éviter des actions au clavier répétées pour parcourir la page et atteindre la zone souhaitée. Ces raccourcis peuvent être masqués au chargement de la page et s’afficher lors de la première tabulation.

En début de code HTML, un groupe de liens atteignable dès la première tabulation vise, si ces éléments sont présents dans la page :

• le menu principal ;
• le contenu principal ;
• le moteur de recherche.

Des liens permettent également d’éviter ou d’accéder directement :

• à chaque groupe de liens importants ;
• à une zone de contenu identifiée.

Les liens d’évitement ou d’accès rapide :

• sont visuellement situés à la même place sur toutes les pages ;
• se présentent toujours dans le même ordre relatif dans le code source ;
• sont directement visibles ou au moins visibles à la prise de focus de tabulation.

Cette bonne pratique concerne toutes les pages du site (y compris les pages d’erreurs et les pages de succès ou d’échec suite à la soumission d’un formulaire).

Références

• RGAA : RGAA 12.7
• Règles Opquast : OPQ 82, OPQ 159, OPQ 165

Vérifiez que :

• le "plan du site" est représentatif de l’architecture générale du site ;
• les liens du plan du site sont fonctionnels ;
• la page "plan du site" est accessible depuis chacune des pages ;
• le lien vers la page "plan du site" est situé à la même place dans chacune des pages.

Références

• RGAA : RGAA 12.4
• Règles Opquast : OPQ 166

Pour chaque page Web, chaque procédé de rafraîchissement ou de redirection automatique (balise object, embed, svg, canvas ou meta) vérifie-t-il une de ces conditions (hors cas particuliers) ?

• L’utilisateur peut arrêter ou relancer le rafraîchissement.
• L’utilisateur peut augmenter la limite de temps entre deux rafraîchissements de dix fois, au moins.
• L’utilisateur est averti de l’imminence du rafraîchissement et dispose de vingt secondes, au moins, pour augmenter la limite de temps avant le prochain rafraîchissement.
• La limite de temps entre deux rafraîchissements est de vingt heures, au moins.

Références

• RGAA : RGAA 13.1.1
• Règles Opquast : OPQ 14

Dans chaque page Web, l’ouverture d’une nouvelle fenêtre ne doit pas être déclenchée sans action de l’utilisateur. L’utilisateur est prévenu que le lien va s’ouvrir dans une nouvelle fenêtre.

Références

• RGAA : RGAA 13.2
• Règles Opquast : OPQ 141, OPQ 149

Les mécanismes de fermeture de fenêtres sont visuellement rattachées à leur contenu.

Les nouvelles fenêtres dimensionnées et les fenêtres modales sont dotées d’un bouton de fermeture explicite.

Les mécanismes de fermetures de fenêtres sont affichés aux mêmes emplacements sur toutes les pages et immédiatement disponibles.

Références

• Règles Opquast : OPQ 155, OPQ 156, OPQ 157, OPQ 158

Il s’agit de permettre aux utilisateurs d’avoir l’ensemble des informations essentielles relatives à la recherche qu’ils ont effectuée.

• Le nombre global de résultats est généralement annoncé et rappelé dans le titre de chaque page de résultats (par exemple : 246 résultats correspondent à votre requête « Exemple »).
• Le nombre de pages de résultats est généralement indiqué dans le menu de navigation entre les pages de résultats.
• Le nombre de résultats par page est généralement indiqué avant la liste des résultats.

Références

• Règles Opquast : OPQ 13

Les icônes de navigation sont accompagnées d’une légende explicite.

Références

• Règles Opquast : OPQ 154

Un mécanisme de désinscription à l’abonnement aux lettres d’information doit être disponible dans chacune des lettres et sur le site.

Références

• Règles Opquast : OPQ 169, OPQ 171

L’inscription aux newsletters est soumise à un processus de confirmation.

Références

• Règles Opquast : OPQ 168

Tous les sites doivent désormais être développés pour permettre une navigation optimisée sur mobiles et tablettes.

Les sites antérieurs doivent intégrer cette nécessité dans le cadre de leur prochaine refonte.

Références

• Éco-conception : 7
• Règles Opquast : OPQ 189

Indiquer la fréquence d’envoi des newsletters.

Références

• Règles Opquast : OPQ 174

Dans chaque page web, l’information ne doit pas être donnée uniquement par la couleur, la forme, la taille ou la position pour chaque :

• texte ou ensemble de textes,
• image ou ensemble d’images,
• média temporel,
• média non temporel,

Références

• RGAA : RGAA 3.1, RGAA 10.9, RGAA 10.10
• Règles Opquast : OPQ 176, OPQ 179

• Vérifier que le mois n’est pas indiqué dans un format numérique, mais en lettre (complet ou abrégé).
• Vérifier que l’année est indiquée sur quatre chiffres.

Les dates à saisir par l’utilisateur final dans les formulaires ne sont pas concernées par cette bonne pratique : leur format, quel qu’il soit, est considéré comme suffisamment explicite, dès lors que la saisie s’effectue via un datepicker ou bien manuellement mais avec une indication du format attendu (du type "JJ/MM/AA").

Références

• Règles Opquast : OPQ 4

Pour chaque formulaire, les indications du caractère obligatoire de la saisie des champs vérifient une de ces conditions :

• Une indication de champ obligatoire est visible et permet d’identifier nommément le champ concerné préalablement à la validation du formulaire
• Le champ obligatoire dispose de l’attribut aria-required="true" ou required préalablement à la validation du formulaire

Pour chaque champ de formulaire, les champs obligatoires ayant l’attribut aria-required="true" ou required vérifient une de ces conditions :

• Une indication de champ obligatoire est visible et située dans l’étiquette associé au champ préalablement à la validation du formulaire
• Une indication de champ obligatoire est visible et située dans le passage de texte associé au champ préalablement à la validation du formulaire

Pour chaque formulaire, les messages d’erreur indiquant l’absence de saisie d’un champ obligatoire vérifient une de ces conditions :

• Le message d’erreur indiquant l’absence de saisie d’un champ obligatoire est visible et permet d’identifier nommément le champ concerné
• Le champ obligatoire dispose de l’attribut aria-invalid="true"

Pour chaque formulaire, les champs obligatoires ayant l’attribut aria-invalid="true" vérifient une de ces conditions :

• Une indication de champ obligatoire est visible et située dans l’étiquette associée au champ
• Une indication de champ obligatoire est visible et située dans le passage de texte associé au champ.

Références

• Système de design de l’État :

  • Champs de saisie
  • Case à cocher
  • Liste déroulante
  • Boutons radio
  • Boutons radio riches
  • Interrupteur
  • Ajout de fichier
• RGAA : RGAA 11.10.1, 11.10.2, 11.10.3, 11.10.4
• Règles Opquast : OPQ 69

Pour tout champ de formulaire présentant un type de donnée ou un format obligatoire, l’utilisateur doit être accompagné lors de la saisie ou en cas d’erreur signalée.

Aide à la saisie :

• Les instructions et indications du type de données et/ou de format obligatoires vérifient-elles une de ces conditions ?

  • Une instruction ou une indication du type de données et/ou de format obligatoire est visible et permet d’identifier nommément le champ concerné préalablement à la validation du formulaire.
  • Une instruction ou une indication du type de données et/ou de format obligatoire est visible dans l’étiquette ou le passage de texte associé au champ préalablement à la validation du formulaire.

• Les champs ayant l’attribut aria-invalid="true" dont la saisie requiert un type de données et/ou de format obligatoires vérifient-ils une de ces conditions ?

  • Une instruction ou une indication du type de données et/ou de format obligatoire est visible et située dans la balise <label> associée au champ.
  • Une instruction ou une indication du type de données et/ou de format obligatoire est visible et située dans le passage de texte associé au champ.

Correction des erreurs de saisie :

• Les messages d’erreur fournissant une instruction ou une indication du type de données et/ou de format obligatoire des champs vérifient-ils une de ces conditions ?

  • Le message d’erreur fournissant une instruction ou une indication du type de donnéeset/ou de format obligatoires est visible et identifie le champ concerné.
  • Le champ dispose de l’attribut aria-invalid="true".
• Pour chaque erreur de saisie, les types et les formats de données sont-ils suggérés, si nécessaire?
• Pour chaque erreur de saisie, des exemples de valeurs attendues sont-ils suggérés, si nécessaire?

S’assurer que tous les messages d’erreur prévus par les outils de gestion d’erreur de saisie sont traduits et délivrés dans la même langue que les autres libellés du formulaire (étiquettes, etc.)

Pour chaque champ faisait l’objet d’une limitation spécifique du nombre de caractères qui peuvent être saisis, indiquer le nombre de caractères maximum dans l’étiquette du champ, ou dans une mention explicitement associée à celle-ci dans le code HTML.

Références

• RGAA : RGAA 11.10.6, 11.10.7, RGAA 11.11
• Règles Opquast : OPQ 68, OPQ 70, OPQ 71, OPQ 72, OPQ 77, OPQ 78, OPQ 80

Dans chaque formulaire :

• Chaque étiquette de champ et son champ associé sont adjacents. L’étiquette doit être accolée soit immédiatement au-dessus ou à gauche du champ (pour une lecture de gauche à droite), soit immédiatement au-dessus ou à droite du champ (pour une lecture de droite à gauche).
• Les informations qui viennent compléter l’étiquette du champ (aide à la saisie, signalement des erreurs, etc.) sont affichées à proximité immédiate du champ et de son étiquette, afin que le rapport entre ceux-ci puisse être perçu sans ambiguïté.
• Chaque composant respecte le Système de design de l’État.

Références

• Système de design de l’État :

  • Champs de saisie
  • Case à cocher
  • Liste déroulante
  • Boutons radio
  • Boutons radio riches
  • Interrupteur
  • Ajout de fichier
• RGAA : RGAA 11.4
• Règles Opquast : OPQ 75, OPQ 76

Le soulignement est réservé aux liens hypertextes dans le respect du composant Liens du Système de design de l’État.

Références

• Système de design de l’État : Liens
• Règles Opquast : OPQ 134

Afin de permettre une bonne lisibilité des contenus et de limiter la charge mentale lors de la consultation, le ratio de contraste entre le texte - y compris du texte sous forme d’image - et son arrière plan doit être d’au moins 4,5:1 (une taille restituée inférieure à 24px). Pour les textes agrandis (taille restituée supérieure ou égale à 24px ou caractères gras), ce ratio doit être d’au moins 3:1.

Dans le cas de graphiques, le contraste entre chaque élement (courbe, bâton, part de camenbert, etc) doit être suffisant.

Les polices avec des traits particulièrement fins ou des aspects et des caractéristiques inhabituels qui réduisent la reconnaissance de la forme des lettres sont plus difficiles à lire, spécialement à des niveaux de contrastes bas.

Références

• RGAA : RGAA 3.2, 3.3
• Règles Opquast : OPQ 177

Le site n’applique pas le même style aux liens visités et non visités.

Références

• Règles Opquast : OPQ 136

Les liens du système de navigation principal s’ouvrent dans la fenêtre active.

Les liens vers des sites externes doivent :

• s’ouvrir dans une nouvelle fenêtre
• se distinguer visuellement d’un lien interne
• avoir la formule « Nouvelle fenêtre » dans l’attribut TITLE
• respecter les critères d’accessibilité RGAA 13.2 (cf Pi-324)

S’assurer que les liens externes qui ouvrent une nouvelle fenêtre ne partagent pas d’information de contexte en ajoutant l’attribut rel="noreferrer noopener" à chaque lien ayant un attribut target="_blank".

Références

• Système de design de l’État : Liens
• Règles Opquast : OPQ 137,OPQ 25

Dans chaque page web, chaque lien texte signalé uniquement par la couleur, et dont la nature n’est pas évidente, vérifie les conditions suivantes :

• La couleur du lien à un rapport de contraste supérieur ou égal à 3:1 par rapport au texte environnant
• Le lien dispose d’une indication visuelle au survol autre qu’un changement de couleur
• Le lien dispose d’une indication visuelle au focus autre qu’un changement de couleur

Les hyperliens peuvent être différenciés à l’aide des propriétés CSS de couleur de texte, de couleur d’arrière-plan, de soulignement, de mise en gras, de bordures, de police de caractères,

L’utilisation du composant prévu par le Système de Design de l’État facilite grandement la prise en compte de ces règles et bonnes pratiques.

Références

• Système de design de l’État : Liens
• RGAA : RGAA 10.6.1
• Règles Opquast : OPQ 135

Les numéros de téléphone sont activables via le protocole approprié.

Références

• Règles Opquast : OPQ 140

L’alternative textuelle d’une image porteuse d’information (ou non décorative), d’une zone réactive ou d’un bouton de type image est pertinente.

Si nécessaire, les images porteuses d’information ont une description détaillée adajacente.

Références

• RGAA : RGAA 1.1, RGAA 1.3, RGAA 1.6
• Règles Opquast : OPQ 112, OPQ 113, OPQ 184

Chaque image pourvue d’une légende (balise <img> ou <input> avec l’attribut type="image" ou possédant un attribut WAI-ARIA role="img", balise <object> avec l’attribut type="image/…", balises <embed>, <svg> ou <canvas> associée à une légende adjacente) vérifie les conditions suivantes :

• La légende adjacente est contenue dans une balise <figure>.
• La balise <figure> possède un attribut WAI-ARIA role="figure" ou role="group".
• La balise <figure> possède un attribut WAI-ARIA aria-label dont le contenu est identique au contenu de la légende.
• La légende est contenue dans une balise <figcaption>.

Références

• RGAA : RGAA 1.9.1, 1.9.2, 1.9.3, 1.9.4, 1.9.5

Chaque média non temporel inséré via un élément img, embed, object, video, audio, svg ou canvas est associé à une alternative pertinente.

Pour chaque média non temporel, on trouve un lien (ou bouton) adjacent permettant d’accéder à une alternative.

Chaque média non temporel associé à une alternative vérifie-t-il une de ces conditions ?

• La page référencée par le lien ou bouton adjacent est accessible.
• L’alternative dans la page, référencée par le lien ou bouton adjacent, est accessible.
• L’alternative est pertinente ou permet d’accéder au même contenu et à des fonctionnalités similaires

Chaque média temporel pré-enregistré seulement vidéo vérifie-t-il une de ces conditions ?

• La transcription textuelle est pertinente
• L’audio-description synchronisée est pertinente
• L’audio-description synchronisée de la version alternative est pertinente
• La version alternative audio seulement est pertinente

Chaque média temporel synchronisé pré-enregistré vérifie-t-il une des conditions ?

• La transcription textuelle est pertinente
• L’audio-description synchronisée est pertinente
• L’audio-description synchronisée de la version alternative est pertinente

Références

• RGAA : RGAA 1.1, RGAA 1.3, RGAA 4.2, RGAA 4.8, RGAA 4.9
• Règles Opquast : OPQ 115, OPQ 116

Chaque élément non textuel mis à jour par un script (dans la page, ou dans un cadre) et ayant une alternative vérifie-t-il ces conditions ?

• L’alternative de l’élément non textuel est mise à jour ;
• L’alternative mise à jour est pertinente.

Références

• RGAA : RGAA 7.2.2
• Règles Opquast : OPQ 1, OPQ 2, OPQ 3

Présenter les items dans un ordre identifiable, par exemple par ordre alphabétique ou chronologique.

Les éléments d’une liste déroulante qui peuvent être regroupés le sont via l’élément optgroup doté d’un attribut label pertinent.

• Pour chaque balise <select>, les items de même nature d’une liste de choix sont-ils regroupés avec une balise <optgroup>, si nécessaire ?
• Dans chaque balise <select>, chaque balise <optgroup> possède-t-elle un attribut label ?
• Pour chaque balise <optgroup> ayant un attribut label, le contenu de l’attribut label est-il pertinent ?

Références

• RGAA : RGAA 11.8
• Règles Opquast : OPQ 91, OPQ 92

Chaque champ de formulaire vérifie-t-il une de ces conditions ?

• Le champ de formulaire possède un attribut WAI-ARIA aria-labelledby référençant un passage de texte identifié ;
• Le champ de formulaire possède un attribut WAI ARIA aria-label ;
• Une balise <label> ayant un attribut for est associée au champ de formulaire ;
• Le champ de formulaire possède un attribut title ;
• Un bouton adjacent au champ de formulaire lui fournit une étiquette visible et un attribut WAI-ARIA aria-label, aria-labelledby ou title lui fournit un nom accessible.

Chaque champ de formulaire associé à une balise <label> ayant un attribut for, vérifie-t-il ces conditions ?

• Le champ de formulaire possède un attribut id ;
• La valeur de l’attribut for est égale à la valeur de l’attribut id du champ de formulaire associé.

Chaque champ de formulaire ayant une étiquette dont le contenu n’est pas visible ou à proximité (masqué, aria-label) ou qui n’est pas accolé au champ (aria-labelledby), vérifie-t-il une de ses conditions ?

• Le champ de formulaire possède un attribut title dont le contenu permet de comprendre la nature de la saisie attendue ;
• Le champ de formulaire est accompagné d’un passage de texte accolé au champ qui devient visible à la prise de focus permettant de comprendre la nature de la saisie attendue ;
• Le champ de formulaire est accompagné d’un passage de texte visible accolé au champ permettant de comprendre la nature de la saisie attendue.

Chaque balise <label> permet-elle de connaître la fonction exacte du champ de formulaire auquel elle est associée ?

• Chaque attribut title permet-il de connaître la fonction exacte du champ de formulaire auquel il est associé ?
• Chaque étiquette implémentée via l’attribut WAI-ARIA aria-label permet-elle de connaître la fonction exacte du champ de formulaire auquel elle est associée ?
• Chaque passage de texte associé via l’attribut WAI-ARIA aria-labelledby permet-il de connaître la fonction exacte du champ de formulaire auquel il est associée ?

• Chaque champ de formulaire ayant un intitulé visible vérifie-t-il ces conditions ?

  • S’il est présent, le contenu de l’attribut WAI-ARIA aria-label du champ de formulaire contient au moins l’intitulé visible ;
  • S’il est présent, le passage de texte lié au champ de formulaire via un attribut WAI-ARIA aria-labelledby contient au moins l’intitulé visible ;
  • S’il est présent, le contenu de l’attribut title du champ de formulaire contient au moins l’intitulé visible ;
  • S’il est présent le contenu de la balise <label> associé au champ de formulaire contient au moins l’intitulé visible.
• Chaque bouton adjacent au champ de formulaire qui fournit une étiquette visible permet-il de connaître la fonction exacte du champ de formulaire auquel il est associé ?

Références

• RGAA : RGAA 11.1, RGAA 11.2
• Règles Opquast : OPQ 67

Test 11.5.1

Les champs de même nature vérifient-ils l’une de ces conditions, si nécessaire ?

• Les champs de même nature sont regroupés dans une balise <fieldset>.
• Les champs de même nature sont regroupés dans une balise possédant un attribut WAI-ARIA role="group".
• Les champs de même nature de type radio (<input type="radio"> ou balises possédant un attribut WAI-ARIA role="radio") sont regroupés dans une balise possédant un attribut WAI-ARIA role="radiogroup" ou role="group".

Test 11.6.1

Chaque regroupement de champs de même nature possède-t-il une légende ?

Test 11.7.1

Chaque légende associée à un regroupement de champs de même nature est-elle pertinente ?

Références

• RGAA : RGAA 11.5.1, RGAA 11.6.1, RGAA 11.7.1

En cas de rejet des données saisies dans un formulaire, toutes les données saisies peuvent être modifiées par l’utilisateur.

Références

• Règles Opquast : OPQ 79

Le copier coller est possible dans les champs de formulaire.

Références

• Règles Opquast : OPQ 90

Les champs de saisie de type mail, URL, téléphone, nombre, recherche, mots de passe, heure et date sont dotés de l’attribut type correspondant à la saisie attendue (email, url, tel, number, search, password, time et date).

Références

• Règles Opquast : OPQ 93

Lorsque les contributeurs mettent en ligne des fichiers (traitement de texte, images, audio, vidéo, etc.), il est nécessaire d’exclure certains formats propriétaires et de favoriser les formats ouverts. Les formats acceptés sont listés au §4.2 du Référentiel général d’interopérabilité (RGI).

En matière de documents bureautiques, le RGI conseille l’utilisation des formats ODF et PDF (statut « recommandé »), tandis que le format Office Open XML est placé au statut « en observation ».

Ces dispositions du RGI nécessitent des recommandations complémentaires :

• Pour mettre à disposition des documents que le destinataire n’a pas besoin de modifier, il faut utiliser le format PDF. Le RGI recommande le format PDF en version 1.7, conforme à la norme ISO32000. Attention cependant, certains fichiers PDF « remplissables » en ligne qui ont été très utilisés par les administrations pour dématérialiser les formulaires papier ne sont pas interopérables, ils utilisent la norme propriétaire XFA de la société Adobe, qui n’est pas interprétée par les lecteurs PDF autres que ceux d’Adobe ; pour envoyer des documents modifiables par le destinataire, le RGI recommande le format ODF en version 1.2.
• Pour diffuser un document de type texte, le format recommandé est ODT.
• Pour diffuser un document de type présentation, le format recommandé est ODP.
• Pour diffuser un document de type feuille de calcul, le format recommandé est ODS.

Si le format propriétaire n’est pas évitable, on proposera également une alternative, par exemple au format PDF.

Références

• Référentiel général d’interopérabilité : RGI 4.2

Un fil d’ariane est présent sur chaque page web et est représentatif de la position de la page dans l’arborescence du site.

Le fil d’ariane du site est conforme au composant du Système de Design de l’État.

Références

• Système de design de l’État : Fil d’ariane
• Règles Opquast : OPQ 151

Différencier l’item actif de menu correspondant à la section ou la page en cours des autres lien du menu, au moins visuellement.

Références

• Règles Opquast : OPQ 152

Les liens provoquant l’ouverture d’un logiciel externe ont un libellé explicite.

Références

• Règles Opquast : OPQ 139

Dans chaque page web, l’ouverture d’une nouvelle fenêtre ne doit pas être déclenchée sans action de l’utilisateur.

Références

• Système de design de l’État : Liens
• RGAA : RGAA 13.2
• Règles Opquast : OPQ 141

Chaque zone cliquable d’une image réactive coté serveur est-t-elle doublée d’un lien dans la page ?

Références

• RGAA : RGAA 1.1.4

Organiser les contenus dans l’ordre linéaire du code HTML de manière à regrouper et ordonner logiquement les liens et les contrôles de formulaires qui apparaissent les uns à la suite des autres à l’affichage et ordonner logiquement les principaux blocs de navigation et de contenu composant la page.

Gérer spécifiquement l’ordre de navigation au clavier en cas de fenêtre modale ou de widget.

Chaque élément possédant un gestionnaire d’événement contrôlé par un script vérifie-t-il une de ces conditions ?

• L’élément est accessible par le clavier et tout dispositif de pointage.
• Un élément accessible par le clavier et tout dispositif de pointage permettant de réaliser la même action est présent dans la page.

Références

• RGAA : RGAA 7.3.1, RGAA 12.8
• Règles Opquast : OPQ 161, OPQ 162

Un script ne doit pas supprimer le focus d’un élément qui le reçoit.

Références

• RGAA : RGAA 7.3.2
• Règles Opquast : OPQ 160

Dans chaque page web où elles sont présentes, les zones d’en-tête, de navigation principale, de contenu principal, de pied de page et de moteur de recherche respectent au moins une de ces conditions :

• la zone possède un rôle WAI-ARIA de type landmark correspondant à sa nature ;
• la zone possède un titre de hiérarchie dont le contenu permet de comprendre la nature du contenu de la zone ;
• la zone peut être masquée par le biais d’un bouton précédant directement la zone dans l’ordre du code source ;
• la zone peut être évitée par le biais d’un lien d’évitement précédant directement la zone dans l’ordre du code source ;
• la zone peut être atteinte par le biais d’un lien d’accès rapide visible à la prise de focus lors d’une tabulation.

Références

• RGAA : RGAA 12.6

Chaque script qui initie un changement de contexte vérifie une de ces conditions :

• L’utilisateur est averti par un texte de l’action du script et du type de changement avant son déclenchement ;
• Le changement de contexte est initié par un bouton (input de type submit, button ou image ou balise button) explicite ;
• Le changement de contexte est initié par un lien explicite.

Références

• RGAA : RGAA 7.4.1

Ne pas utiliser la propriété CSS text-align avec la valeur justify, ou tout autre équivalent.

Références

• Règles Opquast : OPQ 186

Saisir les contenus HTML en respectant l’usage typographique pour les majuscules (début de phrase, noms propres, etc.).

Utiliser la propriété CSS text-transform avec la valeur uppercase pour gérer les mises en majuscules décoratives.

Références

• Règles Opquast : OPQ 187

Dans chaque page web, chaque déclaration CSS de couleurs de police (color), d’un élément susceptible de contenir du texte, est-elle accompagnée d’une déclaration de couleur de fond (background, background-color), au moins héritée d’un parent ?

Dans chaque page web, chaque déclaration de couleur de fond (background, background-color), d’un élément susceptible de contenir du texte, est-elle accompagnée d’une déclaration de couleur de police (color), au moins héritée d’un parent ?

Dans chaque page web, chaque utilisation d’une image pour créer une couleur de fond d’un élément susceptible de contenir du texte, via CSS (background, background-image), est-elle accompagnée d’une déclaration de couleur de fond (background, background-color), au moins héritée d’un parent ?

Références

• RGAA : RGAA 10.5

Si une possibilité d’imprimer l’article est proposée, une feuille de style dédiée à l’impression doit être appliquée. Celle-ci doit reprendre les éléments suivants :

• l’émetteur du site (y compris son identifiant visuel)
• la date de l’impression
• l’URL de la page
• le chemin de la page dans le site (fil d’Ariane).

Références

• Éco-conception : 30
• Règles Opquast : OPQ 191

Si une possibilité d’imprimer l’article est proposée, une feuille de style dédiée à l’impression doit être appliquée. Celle-ci doit reprendre les éléments suivants :

• l’émetteur du site (y compris son identifiant visuel)
• la date de l’impression
• l’URL de la page
• le chemin de la page dans le site (fil d’Ariane).

Références

• Règles Opquast : OPQ 190

Test 1.8.1

Chaque image texte (balise <img> ou possédant un attribut WAI-ARIA role="img") 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) ?

Test 1.8.2

Chaque bouton « image texte » (balise <input> avec l’attribut type="image") porteur d’information, en l’absence d’un mécanisme de remplacement, doit si possible être remplacé par du texte stylé. Cette règle est-elle respectée (hors cas particuliers) ?

Test 1.8.3

Chaque image texte objet (balise <object> avec l’attribut type="image/…") 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) ?

Test 1.8.4

Chaque image texte embarquée (balise <embed> avec l’attribut type="image/…") 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) ?

Test 1.8.5

Chaque image texte bitmap (balise <canvas>) 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) ?

Références

• RGAA : RGAA 1.8.1, 1.8.2, 1.8.3, 1.8.4, 1.8.5
• Éco-conception : 26
• Règles Opquast : OPQ 182

Les mises en forme et présentation doivent être réalisées via les feuilles de style.

Dans chaque page Web, l’utilisation des espaces vérifie-t-elle ces conditions ?

• Les espaces ne sont pas utilisés pour séparer les lettres d’un mot.
• Les espaces ne sont pas utilisés pour simuler des tableaux.
• Les espaces ne sont pas utilisés pour simuler des colonnes de texte.

Références

• RGAA : RGAA 10.1.3

Dans chaque page web, chaque contenu caché vérifie-t-il une de ces conditions ?

• Le contenu caché a vocation à être ignoré par les technologies d’assistance.
• Le contenu caché n’a pas vocation à être ignoré par les technologies d’assistances et est rendu restituable par les technologies d’assistance suite à une action de l’utilisateur réalisable au clavier ou par tout dispositif de pointage sur un élément précédent le contenu caché ou suite à un repositionnement du focus dessus.

Références

• RGAA : RGAA 10.8.1
• Règles Opquast : OPQ 180

De plus, les contenus générés via les styles sont dotés d’une alternative appropriée.

• Dans chaque page web, l’information reste-t-elle présente lorsque les feuilles de styles sont désactivées ?
• Dans chaque page Web, l’information reste-t-elle compréhensible lorsque les feuilles de styles sont désactivées ?

Références

• RGAA : RGAA 10.2.1, RGAA 10.3.1
• Règles Opquast : OPQ 178, OPQ 183

Dans les feuilles de styles du site web, les unités non relatives (pt, pc, mm, cm, in) ne doivent pas être utilisées pour les types de média screen, tv, handheld, projection. Cette règle est-elle respectée ?

Dans les feuilles de styles du site web, pour les types de média screen, tv, handheld, projection, les tailles de caractères utilisent-elles uniquement des unités relatives ?

Références

• RGAA : RGAA 10.4.1

Dans chaque page web, l’augmentation de la taille des caractères jusqu’à 200%, au moins, ne doit pas provoquer de perte d’information. Cette règle est-t-elle respectée selon une de ces conditions ?

• Lors de l’utilisation de la fonction d’agrandissement du texte du navigateur ;
• Lors de l’utilisation des fonctions de zoom graphique du navigateur ;
• Lors de l’utilisation d’un composant d’interface propre au site permettant d’agrandir le texte ou de zoomer.

Dans chaque page web, l’augmentation de la taille des caractères jusqu’à 200%, au moins, doit être possible pour l’ensemble du texte dans la page. Cette règle est-t-elle respectée selon une de ces conditions ?

• Lors de l’utilisation de la fonction d’agrandissement du texte du navigateur ;
• Lors de l’utilisation des fonctions de zoom graphique du navigateur ;
• Lors de l’utilisation d’un composant d’interface propre au site permettant d’agrandir le texte ou de zoomer.

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é ?

Dans chaque page web, le texte reste-t-il lisible lorsque l’affichage est modifié selon ces conditions ?

• L’espacement entre les lignes (line-height) est augmenté jusqu’à 1,5 fois la taille de la police ;
• L’espacement suivant les paragraphes (balise <p>) est augmenté jusqu’à 2 fois la taille de la police ;
• L’espacement des lettres (letter-spacing) est augmenté jusqu’à 0,12 fois la taille de la police ;
• L’espacement des mots (word-spacing) est augmenté jusqu’à 0,16 fois la taille de la police.

Références

• RGAA : RGAA 10.4.2, RGAA 10.4.3, 10.12

Dans chaque page web les balises (à l’exception de div, span et table) ne doivent pas être utilisées uniquement à des fins de présentation. Cette règle est-elle respectée ?

Dans chaque page web, les balises servant à la présentation de l’information ne doivent pas être présentes dans le code source des pages. Cette règle est-elle respectée ?

Dans chaque page Web, les attributs servant à la présentation de l’information ne doivent pas être présents dans le code source des pages. Cette règle est-elle respectée ?

Références

• RGAA : RGAA 8.9.1, RGAA 10.1.1, 10.1.2

Le site ne bloque pas les fonctionnalités de zoom du navigateur.

Références

• Règles Opquast : OPQ 188

Une famille générique de police est indiquée comme dernier élément de substitution.

Références

• Règles Opquast : OPQ 185

Les polices utilisées pour l’impression sont économes en consommation d’encre.

Références

• Éco-conception : 30

Les feuilles de style d’impression ne créent pas d’aplats de couleur.

Références

• Éco-conception : 30

Test 7.1.1

Chaque script qui génère ou contrôle un composant d’interface vérifie-t-il, si nécessaire, une de ces conditions ?

• Le nom, le rôle, la valeur, le paramétrage et les changements d’états sont accessibles aux technologies d’assistance via une API d’accessibilité.
• Un composant d’interface accessible permettant d’accéder aux mêmes fonctionnalités est présent dans la page.
• Une alternative accessible permet d’accéder aux mêmes fonctionnalités.

Test 7.1.2

Chaque script qui génère ou contrôle un composant d’interface respecte-t-il une de ces conditions ?

• Le composant d’interface est correctement restitué par les technologies d’assistance.
• Une alternative accessible permet d’accéder aux mêmes fonctionnalités.

Références

• RGAA : RGAA 7.1.1, 7.1.2

Chaque script qui génère ou contrôle un composant d’interface vérifie-t-il ces conditions (hors cas particuliers) ?

• Le composant possède un nom pertinent.
• Le nom accessible du composant contient au moins l’intitulé visible.
• Le composant possède un rôle pertinent.

Références

• RGAA : RGAA 7.1.3

• Chaque message de statut qui informe de la réussite, du résultat d’une action ou bien de l’état d’une application utilise-t-il l’attribut WAI-ARIA role="status" ?
• Chaque message de statut qui présente une suggestion, ou avertit de l’existence d’une erreur utilise-t-il l’attribut WAI-ARIA role="alert" ?
• Chaque message de statut qui indique la progression d’un processus utilise-t-il l’un des attributs WAI-ARIA role="log", role="progressbar" ou role="status" ?

Références

• RGAA : RGAA 7.5

Chaque champ de formulaire dont l’objet se rapporte à une information concernant l’utilisateur vérifie-t-il ces conditions ?

• Le champ de formulaire possède un attribut autocomplete ;
• L’attribut autocomplete est pourvu d’une valeur présente dans la liste des valeurs possibles pour l’attribut autocomplete associés à un champ de formulaire ;
• La valeur indiquée pour l’attribut autocomplete est pertinente au regard du type d’information attendu.

Références

• RGAA : RGAA 11.13

Chaque script débutant par la balise script et ayant une alternative vérifie-t-il une de ces conditions ?

• L’alternative entre <noscript> et </noscript> permet d’accéder à des contenus et des fonctionnalités similaires ;
• La page affichée, lorsque JavaScript est désactivé, permet d’accéder à des contenus et des fonctionnalités similaires ;
• La page alternative permet d’accéder à des contenus et des fonctionnalités similaires ;
• Le langage de script côté serveur permet d’accéder à des contenus et des fonctionnalités similaires ;
• L’alternative présente dans la page permet d’accéder à des contenus et des fonctionnalités similaires.

Références

• RGAA : RGAA 7.2.1

Les fonctions de scripts du site sont placées dans des fichiers externes (scripts javascript, css...).

Références

• Éco-conception : 16

Les feuilles de style internes et le scripts du site sont minifiées.

Références

• Éco-conception : 78
• Règles Opquast : OPQ 222, OPQ 223

Vérifier qu’un fichier sitemap.xml existe à la racine du site, en y accédant directement dans le navigateur avec une URL du type http://example.com/sitemap.xml. À défaut, consulter le fichier robots.txt pour y rechercher une URL spécifique mentionnée sous la forme sitemap : http://example.com/adresse/du/fichier.xml.

Références

• Règles Opquast : OPQ 213

test 1.2.1

Chaque image (balise <img>) de décoration, sans légende, vérifie-t-elle une de ces conditions ?

• La balise <img> possède un attribut alt vide (alt="") et est dépourvue de tout autre attribut permettant de fournir une alternative textuelle.
• La balise <img> possède un attribut WAI-ARIA aria-hidden="true" ou role="presentation".

test 1.2.2

Chaque zone non cliquable (balise <area> sans attribut href) de décoration, vérifie-t-elle une de ces conditions ?

• La balise <area> possède un attribut alt vide (alt="") et est dépourvue de tout autre attribut permettant de fournir une alternative textuelle.
• La balise <area> possède un attribut WAI-ARIA aria-hidden="true" ou role="presentation".

Test 1.2.3

Chaque image objet (balise <object> avec l’attribut type="image/…") de décoration, sans légende, vérifie-t-elle ces conditions ?

• La balise <object> possède un attribut WAI-ARIA aria-hidden="true".
• La balise <object> est dépourvue d’alternative textuelle.
• Il n’y a aucun texte faisant office d’alternative textuelle entre <object> et </object>.

Test 1.2.4

Chaque image vectorielle (balise <svg>) de décoration , sans légende, vérifie-t-elle ces conditions ?

• La balise <svg> possède un attribut WAI-ARIA aria-hidden="true".
• La balise <svg> et ses enfants sont dépourvus d’alternative textuelle.
• Les balises <title> et <desc> sont absentes ou vides.
• La balise <svg> et ses enfants sont dépourvus d’attribut title.

Test 1.2.5

Chaque image bitmap (balise <canvas>) de décoration, sans légende, vérifie-t-elle ces conditions ?

• La balise <canvas> possède un attribut WAI-ARIA aria-hidden="true".
• La balise <canvas> et ses enfants sont dépourvus d’alternative textuelle.
• Il n’y a aucun texte faisant office d’alternative textuelle entre <canvas> et </canvas>.

Test 1.2.6

Chaque image embarquée (balise <embed> avec l’attribut type="image/…") de décoration, sans légende, vérifie-t-elle ces conditions ?

• La balise <embed> possède un attribut WAI-ARIA aria-hidden="true".
• La balise <embed> et ses enfants sont dépourvus d’alternative textuelle.

Références

• RGAA : RGAA 1.2.1, RGAA 1.2.2, RGAA 1.2.3 RGAA 1.2.4, RGAA 1.2.5, RGAA 1.2.6

Chaque cadre en ligne (balise <iframe> ou <frame>) a-t-il un attribut title ?

Pour chaque cadre (balise <iframe> ou <frame>) ayant un attribut title, le contenu de cet attribut est-il pertinent ?

Références

• RGAA : RGAA 2.1.1, RGAA 2.2.1

Pour chaque page web, le type de document (balise doctype) est-il présent ?

Pour chaque page web, le type de document (balise doctype) est-il valide ?

Pour chaque page web possédant une déclaration de type de document, celle-ci est-elle située avant la balise html dans le code source ?

Pour chaque page web, chaque attribut id est-il unique ?

Références

• RGAA : RGAA 8.1.1, 8.1.2, 8.1.3
• Règles Opquast : OPQ 229

Test 8.10.1

Dans chaque page web, chaque texte dont le sens de lecture est différent du sens de lecture par défaut est contenu dans une balise possédant un attribut dir ?

Test 8.10.2

Dans chaque page web, chaque changement du sens de lecture (attribut dir) vérifie-t-il ces conditions ?

• La valeur de l’attribut dir est conforme (rtl ou ltr) ;
• La valeur de l’attribut dir est pertinente.

Références

• RGAA : RGAA 8.10.1, 8.10.2

Pour chaque déclaration de type de document, le code source généré de la page vérifie-t-il ces conditions (hors cas particuliers) ?

• Les balises, attributs et valeurs d’attributs respectent les règles d’écriture ;
• 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.

Références

• RGAA : RGAA 8.2.1
• Éco-conception : 15

Test 8.3.1

Pour chaque page web, l’indication de langue par défaut vérifie-t-elle une de ces conditions ?

• L’indication de la langue de la page (attribut lang et/ou xml:lang) est donnée pour l’élément html.
• L’indication de la langue de la page (attribut lang et/ou xml:lang) est donnée sur chaque élément de texte ou sur l’un des éléments parents.

Test 8.4.1

Pour chaque page web ayant une langue par défaut, le code de langue vérifie-t-il ces conditions ?

• Le code de langue est valide.
• Le code de langue est pertinent.

Test 8.7.1

Dans chaque page web, chaque texte écrit dans une langue différente de la langue par défaut vérifie-t-il une de ces conditions (hors cas particuliers) ?

• L’indication de langue est donnée sur l’élément contenant le texte (attribut lang et/ou xml:lang).
• L’indication de langue est donnée sur un des éléments parents (attribut lang et/ou xml:lang).

Test 8.8.1

Pour chaque page web, le code de langue de chaque changement de langue vérifie-t-il ces conditions ?

• Le code de langue est valide.
• Le code de langue est pertinent.

Références

• RGAA : RGAA 8.3.1, RGAA 8.4.1, RGAA 8.7.1, RGAA 8.8.1
• Règles Opquast : OPQ 125, OPQ 127

Test 9.1.1

Dans chaque page web, la hiérarchie entre les titres (balise <hx> ou balise possédant un attribut WAI-ARIA role="heading" associé à un attribut WAI-ARIA aria-level) est-elle pertinente ?

Test 9.1.2

Dans chaque page web, le contenu de chaque titre (balise <hx> ou balise possédant un attribut WAI-ARIA role="heading" associé à un attribut WAI-ARIA aria-level) est-il pertinent ?

Test 9.1.3

Dans chaque page web, chaque passage de texte constituant un titre est-il structuré à l’aide d’une balise <hx> ou d’une balise possédant un attribut WAI-ARIA role="heading" associé à un attribut WAI-ARIA aria-level ?

Références

• RGAA : RGAA 9.1.1, 9.1.2, 9.1.3
• Règles Opquast : OPQ 227

Test 9.2.1

Dans chaque page web, la structure du document vérifie-t-elle ces conditions (hors cas particuliers ) ?

• La zone d’en-tête de la page est structurée via une balise <header>.
• Les zones de navigation principales et secondaires sont structurées via une balise <nav>.
• La balise <nav> est réservée à la structuration des zones de navigation principales et secondaires.
• La zone de contenu principal est structurée via une balise <main>.
• La structure du document utilise une balise <main> visible unique.
• La zone de pied de page est structurée via une balise <footer>.

Test 12.6.1

Dans chaque page web où elles sont présentes, la zone d’en-tête, de navigation principale, de contenu principal, de pied de page et de moteur de recherche respectent-elles au moins une de ces conditions :

• la zone possède un rôle WAI-ARIA de type landmark correspondant à sa nature.
• la zone possède un titre de hiérarchie dont le contenu permet de comprendre la nature du contenu de la zone.
• la zone peut être masquée par le biais d’un bouton précédant directement la zone dans l’ordre du code source.
• la zone peut être évitée par le biais d’un lien d’évitement précédant directement la zone dans l’ordre du code source.
• la zone peut être atteinte par le biais d’un lien d’accès rapide visible à la prise de focus lors d’une tabulation.

Références

• RGAA : RGAA 9.2.1, RGAA 12.6

Test 9.3.1

Dans chaque page web, les informations regroupées visuellement sous forme de liste non ordonnée vérifient-elles une de ces conditions ?

• La liste utilise les balises HTML <ul> et <li> ;
• La liste utilise les attributs WAI-ARIA role="list" et "listitem".

Test 9.3.2

Dans chaque page web, les informations regroupées visuellement sous forme de liste ordonnée vérifient-elles une de ces conditions ?

• La liste utilise les balises HTML <ol> et <li> ;
• La liste utilise les attributs WAI-ARIA role="list" et "listitem".

Références

• RGAA : RGAA 9.3.1, 9.3.2
• Règles Opquast : OPQ 228

Dans chaque page web, les informations regroupées sous forme de liste de description utilisent-elles les balises <dl> et <dt>/<dd> ?

Références

• RGAA : RGAA 9.3.3
• Règles Opquast : OPQ 228

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 ?

Chaque contenu additionnel devenant visible à la prise de focus ou au survol d’un composant d’interface peut-il être masqué par une action utilisateur sans déplacer le focus ou le pointeur de la souris ?

Chaque contenu additionnel qui apparaît au survol d’un composant d’interface peut-il être survolé par le pointeur de la souris sans disparaître ?

Chaque contenu additionnel qui apparaît à la prise de focus ou au survol d’un composant d’interface vérifie-t-il une de ces conditions ?

• Le contenu additionnel reste visible jusqu’à ce que l’utilisateur retire le pointeur souris ou le focus du contenu additionnel et du composant d’interface ayant déclenché son apparition ;
• Le contenu additionnel reste visible jusqu’à ce l’utilisateur déclenche une action masquant ce contenu sans déplacer le focus ou le pointeur souris du composant d’interface ayant déclenché son apparition ;
• Le contenu additionnel reste visible jusqu’à ce qu’il ne soit plus valide.

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 ?

Dans chaque page web, les contenus additionnels apparaissant au survol d’un composant d’interface via les styles CSS respectent-ils si nécessaire une de ces conditions ?

• Les contenus additionnels apparaissent également à l’activation du composant via le clavier et tout dispositif de pointage ;
• Les contenus additionnels apparaissent également à la prise de focus du composant ;
• Les contenus additionnels apparaissent également par le biais de l’activation ou de la prise de focus d’un autre composant.

Dans chaque page web, les contenus additionnels apparaissant au focus d’un composant d’interface via les styles CSS respectent-ils si nécessaire une de ces conditions ?

• Les contenus additionnels apparaissent également à l’activation du composant via le clavier et tout dispositif de pointage ;
• Les contenus additionnels apparaissent également au survol du composant ;
• Les contenus additionnels apparaissent également par le biais de l’activation ou du survol d’un autre composant.

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 ?

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 ?

Références

• RGAA : RGAA 10.13, RGAA 10.14, RGAA 12.11

Afin de faciliter l’identification visuelle du site dans le navigateur, dans les favoris ou dans l’historique, le code source contient un lien du type :

<link rel="icon" type="image/png" href="/img/favicon.png"/>

Références

• Règles Opquast : OPQ 99

Objectif

• Permettre à l’utilisateur de cliquer sur les éléments interactifs ;
• Limiter les fausses manipulations et les manipulations inutiles ;
• Améliorer la compatibilité avec les terminaux mobiles ;
• Améliorer l’accessibilité des contenus aux personnes handicapées.

Mise en œuvre

• Donner à chaque élément cliquable (boutons, liens) une taille par défaut d’au moins 44 par 44 pixels.

Références

• Règles Opquast : OPQ 181

Le code source de chaque page contient une métadonnée qui définit le jeu de caractères.

Le codage de caractères utilisé est UTF-8.

Références

• Règles Opquast : OPQ 225, OPQ 226

Utiliser l’élément HTML th et son attribut scope pour baliser les cellules d’en-têtes et expliciter leur portée (scope de valeur col pour un en-tête de colonne, de valeur row pour un en-tête de ligne).

Pour les en-têtes qui ne s’appliquent qu’à une partie d’une ligne ou d’une colonne, contrôler la présence systématique de l’attribut id pour l’élément th et de l’attribut headers pour les éléments td.

L’utilisation du composant prévu par le Système de Design de l’État facilite la prise en compte de ces règles.

Références

• Système de design de l’État : Tableau
• RGAA : RGAA 5.6, RGAA 5.7
• Règles Opquast : OPQ 236

Pour chaque tableau de données complexe un résumé est-il disponible ?

Pour chaque tableau de données complexe ayant un résumé, celui-ci est-il pertinent ?

Pour chaque tableau de données ayant un titre, le titre est-il correctement associé au tableau de données ?

Pour chaque tableau de données ayant un titre, celui-ci est-il pertinent ?

Références

• RGAA : RGAA 5.1, 5.2, 5.4, 5.5
• Règles Opquast : OPQ 237

Chaque tableau de mise en forme vérifie-t-il ces conditions (hors cas particuliers) ?

• Le contenu linéarisé reste compréhensible ;
• La balise <table> possède un attribut role="presentation".

Chaque tableau de mise en forme (balise <table>) vérifie-t-il ces conditions ?

• Le tableau de mise en forme (balise <table>) ne possède pas de balises <caption>, <th>, <thead>, <tfoot>, <colgroup> ou de balises ayant un attribut WAI-ARIA role="rowheader" ou role="columnheader" ;
• Les cellules du tableau de mise en forme (balise <td>) ne possèdent pas d’attributs scope, headers, axis.

Références

• RGAA : RGAA 5.3, 5.8
• Règles Opquast : OPQ 238

Un utilisateur lit une page web par l’intermédiaire d’un navigateur qui interprète le code HTML du site internet. La capacité d’interprétation des navigateurs évolue au fur et à mesure de l’évolution des normes de développement des sites. C’est la version HTML 5 qui est actuellement recommandée dans le Référentiel général d’interopérabilité (RGI).

Les sites internet de l’administration doivent être compatibles avec les versions stabilisées des principaux navigateurs (Internet Explorer, Safari, Chrome et Firefox). Les versions sont listées au §4.2.3 du RGI. La compatibilité avec les navigateurs s’effectue d’abord en respectant les normes de développement web et ensuite en effectuant des tests sur les versions de référence des navigateurs.

Références

• Référentiel général d’interopérabilité : RGI 4.2.3

Les applications mobiles ou applications natives que l’on télécharge à partir des magasins d’applications de Google (Androïd), d’Apple (iOS) ou de Microsoft (Windows Phone), par définition, ne sont pas interopérables, puisqu’elles sont dépendantes de réseaux de distribution privés. Pour ne pas rendre l’utilisateur dépendant d’une seule de ces sociétés, il existe plusieurs solutions :

• ne pas développer d’application mobile et privilégier le développement d’un site internet adaptable à toutes les tailles d’écran (sites responsive design) ;
• développer une application en HTML 5, ce qui permet d’être compatible avec tous les systèmes d’exploitation mobile, mais peut limiter le recours à certaines fonctionnalités ;
• développer une application pour chaque magasin d’application, c’est-à-dire des applications natives qui seront référencées dans chaque magasin d’application. Dans ce cas, il convient de mutualiser les bases de données.

Références

• Référentiel général d’interopérabilité : RGI 4.2.3

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 ?

Dans chaque page web, chaque raccourci clavier n’utilisant qu’une seule touche (lettres minuscule ou majuscule, ponctuation, chiffre ou symbole) vérifie-t-il l’une de ces conditions ?

• Un mécanisme est disponible pour désactiver le raccourci clavier.
• Un mécanisme est disponible pour configurer la touche de raccourci clavier au moyen des touches de modification (Ctrl, Alt, Maj, etc).
• Dans le cas d’un composant d’interface utilisateur, le raccourci clavier qui lui est associé ne peut être activé que si le focus clavier est sur ce composant.

Références

• RGAA : RGAA 12.10

Dans chaque page web, chaque contenu vérifie-t-il ces conditions ?

• La consultation est possible quel que soit le mode d’orientation de l’écran.
• Le contenu proposé reste le même quel que soit le mode d’orientation de l’écran utilisé même si sa présentation et le moyen d’y accéder peut différer.

Références

• RGAA : RGAA 13.9

Dans chaque page web, chaque fonctionnalité utilisable ou disponible suite à un contact multipoint est-elle également utilisable ou disponible suite à un contact en un point unique de l’écran.

Dans chaque page web, chaque fonctionnalité utilisable ou disponible suite à un geste basé sur le suivi d’une trajectoire sur l’écran est-elle également utilisable ou disponible suite à un contact en un point unique de l’écran.

Références

• RGAA : RGAA 13.10

Dans chaque page web, les actions déclenchées au moyen d’un dispositif de pointage sur un point unique de l’écran vérifient-elles l’une de ces conditions ?

• L’action est déclenchée au moment où le dispositif de pointage est relâché ou relevé ;
• L’action est déclenchée au moment où le dispositif de pointage est pressé ou posé puis annulée lorsque le dispositif de pointage est relâché ou relevé ;
• Un mécanisme est disponible pour abandonner (avant achèvement de l’action) ou annuler (après achèvement) l’exécution de l’action ;

Références

• RGAA : RGAA 13.11

Dans chaque page web, les fonctionnalités disponibles en bougeant l’appareil peuvent-elles être accomplies avec des composants d’interface utilisateur ?

Dans chaque page web, les fonctionnalités disponibles en faisant un geste en direction de l’appareil peuvent-elles être accomplies avec des composants d’interface utilisateur (hors cas particuliers ) ?

L’utilisateur a-t-il la possibilité de désactiver la détection du mouvement pour éviter un déclenchement accidentel de la fonctionnalité

Références

• RGAA : RGAA 13.12

L’objectif est d’informer les utilisateurs de la prise en compte de leur demande et de leur permettre d’obtenir une confirmation archivable de la bonne réception de leur demande d’information.

Techniquement, il faut faire en sorte que la validation de chaque formulaire de contact ou de demande d’information déclenche l’envoi d’un accusé de réception à l’attention de l’envoyeur. Cela suppose bien entendu de rendre obligatoire le champ de saisie de l’adresse e-mail dans chaque formulaire.

Références

• Règles Opquast : OPQ 105, OPQ 66

Chaque image (balises <img>, <area>, <input> avec attribut type="img", <object> avec attribut type="image/...", <embed> avec attribut type="image/...", <svg>, <canvas>) utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle, vérifie-t-elle ces conditions ?

• S’il est présent, le contenu de l’attribut alt est pertinent ;
• S’il est présent, le contenu de l’attribut title est pertinent ;
• S’il est présent, le contenu de l’attribut WAI-ARIA aria-label est pertinent ;
• S’il est présent, le passage de texte lié via l’attribut WAI-ARIA aria-labelledby est pertinent ;
• S’il est présent, le contenu alternatif est pertinent.

Chaque image (balises <img> , <area>, <object>, <embed>, <svg>, <canvas> ou balise possédant un attribut WAI-ARIA role="img") ou bouton associé à une image (balise <input> avec l’attribut type="image"), utilisée comme CAPTCHA ou comme image-test, vérifie-t-elle une de ces conditions ?

• Il existe une autre forme de CAPTCHA non graphique, au moins ;
• Il existe une autre solution d’accès à la fonctionnalité sécurisée par le CAPTCHA.

Références

• RGAA : 1.4, 1.5

Chaque image (balises <img>, <area>, <input> avec attribut type="img", <object> avec attribut type="image/...", <embed> avec attribut type="image/...", <svg>, <canvas>) utilisée comme CAPTCHA ou comme image-test, ayant une alternative textuelle, l’alternative textuelle vérifie-t-elle ces conditions ?

• L’alternative textuelle décrit seulement la nature et la fonction de l’image.

Références

• RGAA : Glossaire "Alternative textuelle"

Chaque média temporel pré-enregistré seulement audio, vérifie-t-il, si nécessaire, l’une de ces conditions (hors cas particuliers) ?

• Il existe une transcription textuelle accessible via un lien ou bouton adjacent ;
• Il existe une transcription textuelle adjacente clairement identifiable.

Chaque média temporel pré-enregistré seulement vidéo vérifie-t-il, si nécessaire, l’une de ces conditions (hors cas particuliers) ?

• Il existe une version alternative « audio seulement » accessible via un lien ou bouton adjacent ;
• Il existe une version alternative « audio seulement » adjacente clairement identifiable ;
• Il existe une transcription textuelle accessible via un lien ou bouton adjacent ;
• Il existe une transcription textuelle adjacente clairement identifiable ;
• Il existe une audio-description synchronisée ;
• Il existe une version alternative avec une audio-description synchronisée accessible via un lien ou bouton adjacent.

Chaque média temporel synchronisé pré-enregistré vérifie-t-il, si nécessaire, une de ces conditions (hors cas particuliers) ?

• Il existe une transcription textuelle accessible via un lien ou bouton adjacent ;
• Il existe une transcription textuelle adjacente clairement identifiable ;
• Il existe une audio-description synchronisée ;
• Il existe une version alternative avec une audio-description synchronisée accessible via un lien ou bouton adjacent.

Références

• RGAA : 4.1.1, 4.1.2, 4.1.3
• Règles Opquast : OPQ 116

Chaque média temporel synchronisé pré-enregistré vérifie-t-il, si nécessaire, l’une de ces conditions (hors cas particuliers) ?

• Le média temporel synchronisé possède des sous-titres synchronisés ;
• Il existe une version alternative possédant des sous-titres synchronisés accessible via un lien ou bouton adjacent.

Pour chaque média temporel synchronisé pré-enregistré ayant des sous-titres synchronisés diffusés via la balise <track>, la balise <track> possède-t-elle un attribut kind="captions".

Références

• RGAA : 4.3.1, 4.3.2
• Règles Opquast : OPQ 117

Chaque média temporel seulement audio en direct vérifie-t-il, si nécessaire, une de ces conditions (hors cas particuliers) ?

• Il existe des sous-titres synchronisés ;
• Il existe une version ayant des sous-titres synchronisés accessible via un lien adjacent (une url ou une ancre) ;
• Il existe une transcription textuelle accessible via un lien adjacent (une url ou une ancre) ;
• Il existe une transcription textuelle adjacente clairement identifiable.

Chaque média temporel synchronisé en direct vérifie-t-il, si nécessaire, une de ces conditions (hors cas particuliers) ?

• Il existe des sous-titres synchronisés ;
• Il existe une version ayant des sous-titres synchronisés accessible via un lien adjacent (une url ou une ancre) ;
• Il existe une transcription textuelle accessible via un lien adjacent (une url ou une ancre) ;
• Il existe une transcription textuelle adjacente clairement identifiable.

Références

• Règles Opquast : OPQ 117

Chaque média temporel pré-enregistré seulement vidéo vérifie-t-il, si nécessaire, une de ces conditions (hors cas particuliers) ?

• Il existe une audio-description synchronisée ;
• Il existe une version alternative avec une audio-description synchronisée.

Chaque média temporel synchronisé pré-enregistré vérifie-t-il, si nécessaire, une de ces conditions (hors cas particuliers) ?

• Il existe une audio-description synchronisée ;
• Il existe une version alternative avec une audio-description synchronisée.

Références

• RGAA : 4.5.1, 4.5.2

Si un contenu audio ou vidéo est disponible en téléchargement, sa durée doit être signalée en plus des informations requises pour tout fichier.

Références

• Règles Opquast : OPQ 118

Chaque média temporel a-t-il, si nécessaire, les fonctionnalités de contrôle de sa consultation ?

Références

• RGAA : 4.11.1

Chaque média temporel et non temporel vérifie-t-il une de ces conditions (hors cas particuliers) ?

• Le nom, le rôle, la valeur, le paramétrage et les changements d’états des composants d’interfaces sont accessibles aux technologies d’assistance via une API d’accessibilité ;
• Une alternative compatible avec une API d’accessibilité permet d’accéder aux mêmes fonctionnalités.

Chaque média temporel et non temporel qui possède une alternative compatible avec les technologies d’assistance vérifie-t-il une de ces conditions ?

• L’alternative est adjacente au média temporel ou non temporel ;
• L’alternative est accessible via un lien ou un bouton adjacent ;
• Un mécanisme permet de remplacer le média temporel ou non temporel par son alternative.

Références

• RGAA : 4.13.1, 4.13.2

Chaque page a un élément title. Cet élément title contient le titre de la page, suivi du nom du site.

Références

• RGAA : RGAA 8.5, RGAA 8.6
• Règles Opquast : OPQ 97, OPQ 98

L’utilisateur est averti de la perte d’information en cas d’utilisation de l’historique de son navigateur dans un processus complexe.

Références

• Règles Opquast : OPQ 88

Prévoir un lien vers la page d’accueil sur chaque page du site de préférence toujours au même endroit. Si un logo de site est présent dans les pages, il doit être cliquable et permettre de revenir vers l’accueil.

Références

• Règles Opquast : OPQ 150

Les informations saisies doivent être automatiquement enregistrées à chaque page pour limiter la ressaisie par l’utilisateur.

Notamment, lorsqu’une démarche en ligne comporte plusieurs pages de saisie, les données sont automatiquement sauvegardées au fur et à mesure de la saisie, au minimum à chaque changement de page.

L’enregistrement automatique limite la ressaisie par l’usager, facilite la saisie et sa correction dans les formulaires répartis par étapes et réduit les risques d’abandon en cours de procédure.

Références

• Règles Opquast : OPQ 89

Tous les hyperliens internes du site sont valides et éviter les erreurs de type 404.

Références

• Règles Opquast : OPQ 147

Pour chaque page Web, chaque procédé de redirection effectué via une balise <meta> est-il immédiat (hors cas particuliers) ?

Pour chaque page Web, chaque procédé de redirection effectué via un script vérifie-t-il une de ces conditions (hors cas particuliers) ?

• L’utilisateur peut arrêter ou relancer la redirection ;
• L’utilisateur peut augmenter la limite de temps avant la redirection de dix fois, au moins ;
• L’utilisateur est averti de l’imminence de la redirection et dispose de vingt secondes, au moins, pour augmenter la limite de temps avant la prochaine redirection ;
• La limite de temps avant la redirection est de vingt heures, au moins.

Références

• RGAA : 13.1.2, 13.1.3
• Règles Opquast : OPQ 232

Chaque page de résultats de recherche peut être atteint via une adresse Web.

Références

• Règles Opquast : OPQ 164

La désinscription depuis une newsletter ne demande pas de confirmation par courriel.

Fournir une page dédiée à la newsletter, dans laquelle le formulaire d’abonnement est accompagné d’un formulaire de désabonnement.

Faire figurer le lien de désabonnement dans les autres éventuels formulaires d’inscription « rapides » intégrés à d’autres pages du site.

Références

• Règles Opquast : OPQ 170, OPQ 171

Pour chaque page Web, chaque procédé limitant le temps d’une session vérifie-t-il une de ces conditions ?

• L’utilisateur est informé de la limite de temps ;
• L’utilisateur peut supprimer la limite de temps ;
• L’utilisateur peut augmenter la limite de temps ;
• La limite de temps avant la fin de la session est de vingt heures au moins.

Références

• RGAA : 13.1.4
• Règles Opquast : OPQ 167

La racine du site contient des instructions pour les robots d’indexation.

Références

• Règles Opquast : OPQ 212

Le serveur ne force pas la redirection vers la version ou l’application mobile.

Références

• Règles Opquast : OPQ 214

Les données sensibles ne sont pas transmises en clair dans les url.

Références

• Règles Opquast : OPQ 27

Les échanges de données sensibles sont sécurisés et signalés comme tels.

Références

• Règles Opquast : OPQ 26

Les en-têtes envoyés par le serveur désactivent la détection automatique du type MIME de chaque ressource.

Références

• Règles Opquast : OPQ 201

Le serveur indique le type MIME de chaque ressource.

Références

• Règles Opquast : OPQ 202

Le serveur n’envoie pas la liste des fichiers des répertoires n’ayant pas de page d’index.

Références

• Règles Opquast : OPQ 204

Le serveur envoie les informations d’activation de protection cross site scripting.

Références

• Règles Opquast : OPQ 205

Le serveur envoie les informations indiquant les domaines autorisés à intégrer ses pages dans des cadres.

Références

• Règles Opquast : OPQ 206

Le site propose un mécanisme de sécurité permettant de restreindre l’origine des contenus

Références

• Règles Opquast : OPQ 207

Le serveur envoie un code http 404 pour les ressources non trouvées.

Références

• Règles Opquast : OPQ 215

Les en-têtes envoyés par le serveur contiennent les informations relatives au jeu de caractères employé.

Références

• Règles Opquast : OPQ 221

Héberger les ressources (CSS/JS) sur un domaine sans cookie

Références

• Éco-conception : 96

• Mettre en cache les réponses Ajax
• Configurer les ETags
• Ajouter des entêtes Expires ou Cache-Control
• Mettre en cache le favicon.ico

Références

• Éco-conception : 107, 106, 105, 104
• Règles Opquast : OPQ 220

Compresser les librairies CSS et Javascript.

Compresser la sortie HTML.

Références

• Éco-conception : 80, 83
• Règles Opquast : OPQ 219

Renseigner la balise <meta name="description" content="" />, ou à défaut un élément spécifique ayant la même fonction, avec une description du contenu de la page ou du site.

Références

• Règles Opquast : OPQ 3

Rendre publique

• la dernière newsletter envoyée en rendant son contenu disponible sur le site et en faisant en sorte que l’accès à ce contenu reste possible à partir de la page d’accueil ou du plan de site.
• la totalité des newsletters envoyées en rendant leur contenu disponible sur le site.

Références

• Règles Opquast : OPQ 172, OPQ 173

Les fils de syndication sont détectables par les agents utilisateurs.

Références

• Règles Opquast : OPQ 235

Vérifier que chaque page et ressource de page du site utilise le protocole HTTPS et non HTTP. Vérifier la validité du certificat à l’aide d’un outil en ligne, ou bien à l’aide des outils fournis par les navigateurs Utiliser pour chaque page l’entête HTTP Strict Transport Security et son paramètre max-age pour spécifier que le navigateur doit convertir toutes les requêtes en HTTP en requêtes HTTPS. Pour chaque page du site envoyée par le serveur en HTTPS, fournir toutes les ressources qui la composent (images, fichiers CSS, JS, etc.) via le protocole HTTPS et non via HTTP.

Référence

• Règles Opquast : OPQ 192, OPQ 193, OPQ 194, OPQ 195

Dans chaque page Web, chaque fonctionnalité de téléchargement d’un document bureautique vérifie-t-elle une de ces conditions ?

• Le document en téléchargement est compatible avec l’accessibilité ;
• Il existe une version alternative du document en téléchargement compatible avec l’accessibilité ;
• Il existe une version alternative du document en téléchargement au format HTML.

Chaque document bureautique ayant une version accessible vérifie-t-il une de ces conditions ?

• La version compatible avec l’accessibilité offre la même information ;
• La version alternative au format HTML est pertinente et offre la même information.

Les documents PDF internes sont dotés d’une structure de titre et le texte est sélectionnable.

Références

• RGAA : 13.3.1, 13.4.1
• Règles Opquast : OPQ 233, OPQ 234

Optimiser les PDF.

Références

• Éco-conception : 109

L’indicatif international est mentionné pour tous les numéros de téléphone.

Références

• Règles Opquast : OPQ 123

Le pays est précisé pour toutes les adresses postales.

Références

• Règles Opquast : OPQ 124

Dans chaque page Web, chaque contenu cryptique (art ASCII, émoticon, syntaxe cryptique) vérifie-t-il une de ces conditions ?

• Un attribut title est disponible ;
• Une définition est donnée par le contexte adjacent.

Dans chaque page Web, chaque contenu cryptique (art ASCII, émoticon, syntaxe cryptique) ayant une alternative, vérifie-t-il une de ces conditions ?

• Le contenu de l’attribut title est pertinent ;
• La définition donnée par le contexte adjacent est pertinente.

Références

• RGAA : 13.5.1, 13.6.1

Pour chaque média temporel pré-enregistré, seulement vidéo ou synchronisé, ayant une audio-description synchronisée, celle-ci est-elle pertinente ?

Pour chaque média temporel pré-enregistré, seulement vidéo ou synchronisé, ayant une version alternative dotée d’une audio-description synchronisée, celle-ci est-elle pertinente ?

Références

• RGAA : 4.2.2, 4.2.3, 4.6.1, 4.6.2

La langue principale de la page cible d’un hyperlien est identifiable lorsqu’elle diffère de celle de la page d’origine.

Références

• Règles Opquast : OPQ 126

Fournir sur chaque page dont le contenu a été traduit un lien ou un formulaire de navigation donnant immédiatement accès à la version traduite de la page courante, sans retour à la page d’accueil de la version linguistique concernée.

Rédiger les liens et les alternatives textuelles d’images-liens concernées dans la langue de chaque page cible. Par exemple, inscrire « English version » pour un lien menant vers une version anglaise de la page actuellement rédigée en français.

Références

• Règles Opquast : OPQ 128, OPQ 129

Dans chaque page Web, l’utilisation des espaces vérifie-t-elle ces conditions ?

• Les espaces ne sont pas utilisés pour séparer les lettres d’un mot ;
• Les espaces ne sont pas utilisés pour simuler des tableaux ;
• Les espaces ne sont pas utilisés pour simuler des colonnes de texte.

Références

• RGAA : 10.1.3
• Règles Opquast : OPQ 240

Objectif

• Permettre ou améliorer la compréhension du graphique.
• Faciliter le partage des données.
• Améliorer l’accessibilité des contenus aux personnes handicapées.
• Améliorer la prise en compte des contenus par les moteurs de recherche et outils d’indexation

Solution technique

• Utiliser systématiquement l’élément table et les éléments associés (tr, td, th, caption) pour baliser les tableaux de données, et non des images reproduisant le tableau.
• Afficher de manière structurée, dans le contexte immédiat du graphique, toutes les données numériques qu’il représente, par exemple sous forme de tableau de données (ou fournir dans le contexte immédiat du graphique un lien vers un contenu du même type).

Moyen de controle

• S’assurer qu’aucun tableau de données n’est géré sous forme d’image.
• Vérifier la présence, pour chaque graphique, d’un contenu structuré indiquant toutes les données numériques qu’il représente, ou d’un lien vers une page fournissant celles-ci.

Références

• Règles Opquast : OPQ 239, OPQ 12

Le format, la taille et la langue des fichiers proposés en téléchargement est indiqué dans le libellé du lien ou grâce à l’attribut title.

De plus le nommage des fichiers internes proposés en téléchargement permet d’en identifier le contenu et la provenance. Pour chaque fichier interne téléchargeable par l’utilisateur, utiliser un nom de fichier mentionnant explicitement le site ou le service de manière à permettre de l’identifier, ainsi que la nature du contenu (facture, contrat, etc).

Références

• Règles Opquast : OPQ 142, OPQ 143, OPQ 144, OPQ 145

L’administration doit veiller à utiliser un langage clair, des formulations simples et des questionnements logiques.

Références

• gouvernement.fr : Les grands principes de rédaction

Les traceurs regroupent toutes les technologies consistant en des opérations de lecture ou écriture dans le terminal d’un utilisateur, et comprennent pas exemple les différents types de cookies (http, javascript, flash), les pixels espions (tracking pixels, web beacons), les prises d’empreintes du terminal (fingerprinting) ou les identifiant publicitaires. Ceux-ci doivent être classés dans deux catégories :

• Les traceurs strictement nécessaires : ils ne sont pas concernés par l’obligation de recueil du consentement. Ce sont notamment :

  • les traceurs conservant le choix exprimé par l’utilisateur sur le dépôt de traceurs;
  • les traceurs destinés à l’authentification auprès d’un service, y compris ceux visant à assurer la sécurité du mécanisme d’authentification, par exemple en limitant les tentatives d’accès robotisées ou inattendues;
  • les traceurs destinés à garder en mémoire le contenu d’un panier d’achat sur un site marchand ou à facturer, à l’utilisateur, le(s) produit(s) et/ou service(s) acheté(s);
  • les traceurs de personnalisation de l’interface utilisateur (par exemple, pour le choix de la langue ou de la présentation d’un service), lorsqu’une telle personnalisation constitue un élément intrinsèque et attendu du service;
  • les traceurs permettant l’équilibrage de la charge des équipements concourant à un service de communication;
  • les traceurs permettant aux sites payants de limiter l’accès gratuit à un échantillon de contenu demandé par les utilisateurs (quantité prédéfinie et/ou sur une période limitée);
  • les traceurs de mesure d’audience (analytics) qui s’avèrent nécessaires au bon fonctionnement des sites, dans la mesure où ils respectent certaines conditions. Voir le critère Pi-602.
• Tous les autres traceurs : leur liste doit être mise à disposition des utilisateurs dans la partie dédiée à la politique de confidentialité ; ils doivent respecter les critères Pi-603, Pi-604 et Pi-605.

Références

• Les lignes directrices cookies et autres traceurs
• La recommandation cookies et autres traceurs
• Loi informatique et Liberté

La condition pour pouvoir utiliser des traceurs de mesure d’audience sans consentement est de s’assurer qu’ils sont bien strictement nécessaires au fonctionnement du site web. La CNIL considère ainsi que, pour remplir cette condition de stricte nécessité, l’usage de ces traceurs devrait :

• avoir une finalité limitée à la seule mesure de l’audience du site ou de l’application (mesure des performances, détection de problèmes de navigation, optimisation des performances techniques ou de son ergonomie, estimation de la puissance des serveurs nécessaires, analyse des contenus consultés), pour le compte de l’éditeur;
• ne pas permettre le suivi global de la navigation de la personne à travers le web ou des applications;
• servir uniquement à produire des données statistiques anonymes;
• ne pas mener à recouper des données avec d’autres traitements ou bien les transmettre à des tiers.

La CNIL recommande de plus que :

• les utilisateurs soient informés de la mise en œuvre de ces traceurs, par exemple via la politique de confidentialité du site ou de l’application mobile;
• la durée de vie des traceurs soit limitée à une durée permettant une comparaison pertinente des audiences dans le temps comme c’est le cas d’une durée de treize mois et qu’elle ne soit pas prorogée automatiquement lors des nouvelles visites;
• les informations collectées par l’intermédiaire des traceurs soient conservées pendant une durée maximale de vingt-cinq mois;
• que les durées de vie et de conservation ci-dessus mentionnées fassent l’objet d’un examen périodique.

Références

• Les lignes directrices cookies et autres traceurs
• La recommandation cookies et autres traceurs
• Loi informatique et Liberté

Attention : le critère Pi-601 liste les types de traceurs qui ne sont pas concernés par cette règle.

L’interface de recueil de consentement à l’utilisation de traceurs respecte les conditions suivantes :

• La liste des finalités est présentée avant tout choix ;
• L’utilisateur peut refuser aussi facilement qu’accepter, par des boutons d’acceptation ou de refus mis au même niveau par exemple ;
• L’utilisateur à accès à la liste des responsables du ou des traitements utilisant des traceurs sur le site directement ou via un lien sur le premier niveau d’information ;
• L’utilisateur est informé à l’avance des conséquences qui s’attachent à un refus ou une acceptation des traceurs. L’interface est disponible à tout moment dans la navigation sur le site, par exemple en pied de page et permet à l’utilisateur de retirer son consentement à tout moment.

Il est, de plus, recommandé :

• de donner à l’utilisateur a la possibilité de donner son consentement de manière indépendante pour chaque finalité ;
• d’intégrer un bouton « toute refuser » au même niveau et avec le même code graphique que le bouton « tout accepter » ;
• de ne pas implémenter de pratiques de design trompeuse : bouton décoloré, barre de défilement (slider bar) non-compréhensible.

Références

• Légifrance

  • Les lignes directrices cookies et autres traceurs
  • La recommandation cookies et autres traceurs
  • Loi informatique et Liberté
• Règles Opquast : OPQ 28

Attention : le critère Pi-601 liste les types de traceurs qui ne sont pas concernés par cette règle.

• En cas de refus de l’utilisateur, les seuls traceurs utilisés sont des traceurs strictement nécessaires (par exemple, les traceurs de mesures d’audience encadrés par le critère Pi-601).
• La durée de validité du refus est choisie de manière à ne pas influencer l’utilisateur dans ses choix. Une durée de six mois, tant pour le consentement que pour le refus est, en général, appropriée.

Références

• Les lignes directrices cookies et autres traceurs
• La recommandation cookies et autres traceurs
• Loi informatique et Liberté

Attention : le critère Pi-601 liste les types de traceurs qui ne sont pas concernés par cette règle.

L’existence et la validité du consentement recueilli à une date donnée peut être démontrée par une ou une combinaison des mesures suivantes :

• Les différentes versions du code informatique utilisé par l’organisme recueillant le consentement peuvent être mises sous séquestre auprès d’un tiers, ou, plus simplement, un condensat (ou « hash ») de ce code peut être publié de façon horodatée sur une plate-forme publique, pour pouvoir prouver son authenticité a posteriori ;
• Une capture d’écran du rendu visuel affiché sur un terminal mobile ou fixe peut être conservée, de façon horodatée, pour chaque version du site ou de l’application ;
• Des audits réguliers des mécanismes de recueil du consentement mis en œuvre par les sites ou applications depuis lesquels il est recueilli peuvent être mis en œuvre par des tiers mandatés à cette fin ;
• Les informations relatives aux outils mis en œuvre et à leurs configurations successives (tels que les solutions de recueil du consentement, également connues sous l’appellation CMP, pour « Consent Management Plateform ») peuvent être conservées, de façon horodatée, par les tiers éditant ces solutions.

Références

• Les lignes directrices cookies et autres traceurs
• La recommandation cookies et autres traceurs
• Loi informatique et Liberté