Checklist dev

Après avoir réalisé une nouvelle fonctionnalité ou une nouvelle page, les développeurs et développeuses peuvent faire quelques tests et vérifications rapides avant de livrer leur travail pour la revue de code ou en recette.

Les six points ci-dessous ne constituent pas des vérifications suffisantes pour établir que la fonctionnalité ou la page seront accessibles mais sont des tests qui devraient être systématiquement opérés avant de transmettre le code pour la revue ou la recette.

Les tests et explications

  • Comment vérifier ?

    S'assurer que le titre de chaque page (contenu de la balise title dans le head, visible en titre de l'onglet du navigateur) permet de la distinguer des autres pages et reflète bien son contenu.

    À quoi ça sert ?

    Pour les personnes aveugles, utilisateurs de lecteurs d'écran, le titre de la page est le premier élément vocalisé. Pour des utilisateurs qui naviguent avec l'historique de navigation ou la liste des onglets, il est important qu'ils puissent retrouver les pages facilement en se basant sur leur titre.

  • Comment vérifier ?

    Vérifier dans le code source que la balise html comporte bien cet attribut et qu'il est bien renseigné. Si des passages de texte sont dans d'autres langues il faudra ajouter cet attribut dans les balises conteneurs correspondantes.

    À quoi ça sert ?

    Déclarer la langue de traitement permettra aux outils de synthèse vocales de prononcer le contenu avec l'accent qui convient à la langue utilisée.

  • Comment vérifier ?

    La validation doit s'effectuer sur le code source généré (avec JavaScript).

    Pour une page publique, on peut utiliser le https://validator.w3.org/. Pour une page locale il existe plusieurs extensions pour navigateur. On peut aussi prévoir cette validation dans le workflow de l'usine de développement.

    À quoi ça sert ?

    Un code source valide est essentiel pour la robustesse du site et pour s'assurer d'un rendu homogène avec tous les navigateurs. En effet, un code mal structuré est généralement « réparé » par le navigateur mais tous les navigateurs ne le font pas de la même manière, ce qui peut générer des différences importantes d'un navigateur à l'autre.

    Pour le RGAA, un code source valide est un code source :

    • dont les balises respectent les règles d'écriture (les balises sont conformes au type de document déclaré) ;
    • dont l'imbrication des balises est conforme ;
    • dont l'ouverture et la fermeture des balises sont conformes ;
    • dont les attributs respectent les règles d'écriture ;
    • dont les valeurs des attributs respectent les règles d'écriture (par exemple, les valeurs d'identifiant dupliquées ne sont pas conformes).
  • Comment vérifier ?

    Rafraîchir la page. S'assurer qu'on peut naviguer de lien en lien (ou tout autre élément focusable tel que bouton, champ de formulaire...) à l'aide de la touche tabulation. Lorsque le focus est posé sur un lien ou un bouton la touche d'espacement active ledit lien ou bouton. Les boutons sont également activables grâce à la touche Return.

    Lors du test, on utilisera aussi la combinaison de touches maj + tab pour vérifier qu'on peut naviguer à reculons.

    Additionnellement, on s'assure que le focus est visible, c'est-à-dire qu'on distingue bien où la tabulation nous a conduit.

    À quoi ça sert ?

    Les utilisateurs qui ont des problèmes de motricité fine utilisent principalement le clavier pour se déplacer sur la page. Ils doivent pouvoir effectuer leur navigation et utiliser toutes les fonctionnalités sans devoir recourir à une souris.

  • Comment vérifier ?

    Quelques exemples :

    • Les balises a sont utilisées lorsque le clic doit diriger vers une autre page ou un autre site.
    • Les balises button sont utilisées lorsque leur activation déclenche une action au sein de la page ou l'envoi d'un formulaire.
    • La balise span n'est utilisée que pour des passages de texte au sein de balises structurantes (p, ul, hx).
    • Les listes sont structurées avec les balises html sémantiques correspondantes et non simulées à l'aide de règles de présentation.

    À quoi ça sert ?

    L'utilisation des balises sémantiques correctes permet une bonne restitution des contenus. Les cas les plus courants des détournements perturbants sont l'utilisation de liens pour des boutons ou inversement et le choix de telle ou telle balise html en fonction de sa présentation plutôt que sa sémantique.

  • Comment vérifier ?

    Dans les formulaires cliquer sur chaque étiquette pour s'assurer que le focus se place bien dans le champ correspondant ou active bien le bouton radio ou la checkbox.

    À quoi ça sert ?

    L'identification des champs de formulaire est un élément essentiel. Beaucoup d'utilisateurs handicapés vont accéder aux champs de manières très diverses.

    Les utilisateurs de lecteurs d'écran disposent de raccourcis clavier leur permettant de naviguer rapidement d'un champ à l'autre et certains dispositifs de navigation vocale proposent d'accéder aux champs par leur nom.

    Dans ce type de contexte, il est important que chaque champ de formulaire possède une étiquette liée, afin qu'elle soit restituée lors de la prise de focus. Cela permettra aux personnes aveugles d'utiliser à profit les raccourcis clavier et aux utilisateurs de navigation vocale d'accéder rapidement aux champs. Pour les utilisateurs de dispositifs de pointage adapté, l'étiquette d'un champ permet d'étendre la surface de clic et ainsi améliore l'efficacité des manipulations.

Suivez notre actualité !

DesignGouv, c’est aussi des événements, des rencontres et des discussions pour faire vivre la culture design au sein des administrations. Rejoignez-nous !

Recevoir notre newsletter

Sur Twitter : @design_gouv