La shortlist du développeur

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

Les 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.

Tests et explications

  • SD-01 Le title de la page est unique et pertinent

    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.

  • SD-02 La balise html possède l'attribut lang avec la valeur de la langue principale

    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.

  • SD-03 Le code html est valide au regard de la DTD

    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 validateur du W3C. 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).
  • SD-04 La page est entièrement navigable et utilisable au clavier

    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.

  • SD-05 La sémantique des balises html est correctement utilisée

    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.

  • SD-06 Chaque champ de formulaire est associé à son étiquette

    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.

Memo développement

Les recommandations ci-dessous sont extraites du Guide de l'intégrateur RGAA établi par la DISIC. Ce guide propose des fiches pour chaque thématique avec des conseils de développement, l'explication du besoin pour les utilisateurs et des ressources complémentaires.

Gabarit général

  • Déclarer un doctype valide.
  • Déclarer toujours la langue de traitement sur la balise html.
  • Valider le code source.
  • Structurer votre page avec les landmarks ARIA.
  • Si le site est en HTML5, structurer la page avec les balises HTML5 et les landmarks ARIA.

Navigation

  • Définir des titres de pages pertinents.
  • Implémenter un lien d'accès rapide au contenu.
  • Implémenter un lien d'accès rapide à la navigation principale.
  • Implémenter des liens d'évitement pour tous les groupes de liens importants.
  • Implémenter deux systèmes de navigation au moins.

Contenus

  • Donner un titre pertinent aux cadres en ligne.
  • Utiliser les balises appropriées pour structurer les listes.
  • Indiquer les changements de langue et de sens de lecture.
  • Indiquer les ouvertures de nouvelles fenêtres.
  • Indiquer le format et le poids des documents en téléchargements.

Tableaux

  • Implémenter le role="presentation" sur les tableaux de mise en forme.
  • Déclarer les cellules d'en-têtes dans des éléments th.
  • Implémenter un attribut scope="col" pour les en-têtes de colonnes.
  • Implémenter un attribut scope="row" pour les en-têtes de lignes.
  • Utiliser les relations id, headers pour relier les cellules de données à leurs en-têtes dans le cas de cellules fusionnées.

Liens

  • Attention aux liens vides.
  • Définir des intitulés de liens pertinents.
  • Respecter la construction des titres de liens.

Formulaires

  • Définir des étiquettes pertinentes.
  • Utiliser une méthode conforme pour relier les champs à leurs étiquettes respectives.
  • Pour les champs obligatoires avec un format de saisie, pensez toujours à l'indiquer (de préférence dans l'étiquette du champ).
  • Pour les erreurs de saisie, reliez l'erreur au champ concerné et indiquez un exemple de saisie réelle lorsque nécessaire.

Prise de focus

  • La prise de focus est visible, les valeurs de l'outline ne la dégradent pas.
  • Une mise en forme autre que la couleur permet d'identifier les liens ainsi que leur survol et la prise de focus.
  • Lors de la navigation au clavier la prise de focus est cohérente et ne reste pas bloquée sur un élément (piège au clavier).

Distinction fond et forme

  • Aucun contenu ne disparaît lors de l'activation ou de la désactivation des styles.
  • La page reste compréhensible et les différentes zones sont correctement ordonnées lorsque les styles sont désactivés.

Images

  • Définir un alt sur toutes les images img.
  • Définir un alt="" sur les images de décoration.
  • Définir une alternative conforme et pertinente lorsqu'elle est porteuse d'information.
  • Éviter le plus possibles les images textes

Informations par la forme et la couleur

  • Ne pas donner d'informations uniquement par la couleur.
  • Ne pas donner d'informations uniquement par la forme.
  • Implémenter des alternatives à la couleur et à la forme qui soient pertinentes.

Agrandissement des caractères

  • Ne pas définir des tailles de caractères en pixels.
  • Eviter de fixer des hauteurs de boîte en pixels.
  • Utiliser la propriété overflow:hidden avec précaution.
  • Définir si possible des points de rupture en em.

Multimédia

  • Faire précéder toutes les vidéos d'un titre.
  • Fournir un lien clairement identifié permettant d'accéder à l'alternative accessible des médias non temporels.