Critères incontournables pour la conception

1. Donner un titre aux pages

Cible : tout le monde et en particulier les personnes déficientes visuelles.
Quand : dès la conception et pendant le développement.

Description :
Donner à chaque page un titre qui lui est spécifique et qui reflète son contenu ou sa fonction (balise <title>).
Le titre de la page est le premier élément lu par la synthèse vocale, il doit permettre d’identifier formellement la page sur laquelle on se trouve.

À vérifier :

  • Bien qu’il n’y ait pas de règle, en général (ouverture de nombreux onglets de multiples applications), on va de l’information la plus spécifique vers la moins spécifique (ex : nom de la page courante - nom du site). Pour le fenêtrage d’une multitude d’applications, le contexte d’utilisation est différent ; dans ce cas, on préférera aller de l’information la moins spécifique vers la plus spécifique.
  • Lorsque le contenu de la page est modifié dynamiquement (affichage du résultat d’une recherche, erreurs dans un formulaire, action utilisateur ajoutant du contenu…), le titre de la page doit refléter cette modification du contenu.

Exemple valide :
Accueil - Espace client Orange

Exemple non-valide :
Accueil

2. Donner des titres aux rubriques

Cible : tout le monde et en particulier les personnes déficientes cognitives, ayant des difficultés pour lire ou déficientes visuelles.
Quand : dès la conception, à la rédaction du contenu et pendant le développement.

Description :
Identifier les balises de titres à utiliser (balises HTML h1 jusqu’à h6) pour structurer le contenu des pages. Les personnes malvoyantes naviguant à l’aide d’un lecteur d’écran peuvent accéder à la liste des titres de la page pour naviguer rapidement. Tout comme dans un fichier Word, il est possible d’utiliser la table des matières si des titres ont correctement été positionnés à l’intérieur du document.

À vérifier :

  • Les titres doivent être pertinents, refléter la structure de l’information contenue dans la page.
  • Il ne doit pas exister de saut dans la hiérarchie des titres (on ne passe pas directement d’un titre h2 à un titre h4).
  • On peut mettre plusieurs h1 par page (se limiter tout de même à deux dans la majorité des cas).

Exemple valide :

Un titrage de page cohérent et pertinent :

(Titre 1) Accueil - Orange
    (Titre 2) Les actualités
    (Titre 2) La fibre arrive&nbsp;!
        (Titre 3) Êtes-vous éligible&nbsp;?

3. Assurer un contraste suffisant entre texte et fond

Cible : tout le monde, en particulier les utilisateurs sur mobile et tablette, les personnes malvoyantes, éprouvant des difficultés de lecture ou avec un déficit d’attention et les seniors.
Quand : dès la phase de conception et lors du développement.

Description :
Le niveau de contraste entre le texte et l’arrière-plan doit être suffisamment élevé. Un niveau de contraste insuffisant sera préjudiciable pour les utilisateurs ayant des difficultés visuelles ainsi que pour les utilisateurs de mobiles et tablettes se trouvant dans un environnement très lumineux.

Exemple non-valide :
Le texte « film | 20h40… » ne présente pas un contraste suffisant. Celui-ci ne sera pas lisible par tous les utilisateurs.

capture d’écran présentant du texte dont le contraste n’est pas suffisant

Les icônes ci-après sont porteuses d’information pour les utilisateurs. Elles devront alors avoir un contraste de couleur de 3:1.

capture d’écran présentant des icônes et des graphiques dont le contraste n'est suffisant

À vérifier :

  • Le contraste entre la couleur du fond et celle du texte doit être 4.5:1 minimum, et ceci également pour du texte sous forme d’image porteuse d’information.
  • Les composants graphiques d’interface utilisateur doivent avoir un contraste de 3:1. Sont concernés, entre autres : les boutons, les boutons radios les cases à cocher, les listes de sélection, les menus et volets de navigation, les barres d’outils, les onglets, les carrousels, les curseurs, les barres de progression, les bulles d’aides, les barres de progression, les graphiques… Il n’est pas tenu d’appliquer ce critère, si :
    • le composant graphique est un logo
    • si un texte comme un label apporte la même information que l’icône
    • si la modification du taux de contraste de l’image nuit au réalisme de celle-ci
  • Pour des applications principalement utilisées en web mobile ou en mobilité, le niveau de contraste des principaux éléments doit être de 7:1 afin d’assurer une bonne lisibilité pour tous.
  • Les liens doivent être facilement identifiables par rapport au reste du texte.

Outil :
L’application Colour Contrast Analyser permet de mesurer rapidement des niveaux de contraste de couleurs (gratuit pour Mac et Windows).

4. Ne pas utiliser la couleur ou l’information sensorielle comme seule source d’information

Cible : tout le monde, en particulier les daltoniens et plus généralement les personnes malvoyantes ou ayant une déficience cognitive, auditive et les seniors.
Quand : dès la phase de conception et lors du développement.

Description :
Ne pas utiliser la couleur ou une information sensorielle (forme, taille, son, orientation, localisation visuelle…) comme la seule façon de véhiculer de l’information, d’indiquer une action, de solliciter une réponse ou de distinguer un élément. L’information fournie par un changement de couleur ou une information sensorielle doit être complétée par une information textuelle (alternative) ou/et structuration sémantique.

Exemple valide :

illustration utilisant des icônes de couleurs avec des formes différenciées pour transmettre l’information

Exemple non-valide :

illustration utilisant des icônes de couleurs avec des formes identiques pour transmettre l’information

Cet exemple n’est pas valide, car l’information est transmise uniquement par la couleur.

À vérifier :

  • Faire une capture d’écran et la passer en noir et blanc. La perte des couleurs ne doit pas entraîner de difficulté dans la navigation, ni provoquer de perte d’information.
  • Couper le son, le niveau d’information doit rester identique.

5. Définir des équivalents textuels

Cible : les personnes déficientes visuelles, les personnes malentendantes ou déficientes cognitives et les moteurs de recherche.
Quand : dès la conception et pendant le développement.

Description :
Mettre en place des alternatives textuelles pour tous les éléments informatifs non-textuels (alternatives aux images, icônes). De même, prévoir des scripts ou des sous-titres pour les contenus audio ou vidéo.

Exemple :
Dans la capture ci-dessous, il faudrait par exemple prévoir dès la conception les textes alternatifs pour chaque bouton :

  • « menu »,
  • « réglages »,
  • « chaîne précédente »
  • « couper le son »

capture d’écran d’un lecteur vidéo contenant plusieurs boutons

6. Assurer la visibilité du focus

Cible : tout le monde et en particulier les personnes déficientes visuelles, motrices, cognitives et en mobilité.
Quand : lors de la conception graphique et lors du développement.

Description :
La position du focus clavier doit être visible par tous les utilisateurs. Par défaut, le navigateur entoure l’élément avec des pointillés ou un cadre de couleur. Ce comportement peut être remplacé pour être rendu plus visible mais ne doit pas être supprimé. Veiller à fournir un niveau de contraste suffisant (cf. mesurer le niveau de contraste des couleurs). Les utilisateurs qui naviguent à l’aide du clavier (touche TAB) ont besoin de connaître la position du focus à tout moment.

L’effet visible à la prise du focus doit être étudié dès la conception graphique au même titre que l’effet visible au survol du pointeur de la souris.

Exemples valides :
Dans les captures d’écran suivantes, le focus est positionné sur le lien « 209 SMS/mois ».
La première capture présente le comportement par défaut (focus représenté par des pointillés). Dans la seconde capture, les pointillés ont été supprimés, mais un encadré permet d’indiquer de manière explicite l’emplacement du focus.
capture d’écran présentant l’affichage du focus par défaut capture d’écran présentant un comportement personnalisé pour l’affichage du focus

7. Agrandissement de texte et adaptation à la taille d'affichage

Cible : tout le monde et en particulier les personnes déficientes visuelles, en mobilité et seniors.
Quand : lors de la conception graphique et principalement lors du développement.

Description :
La taille du texte doit pouvoir être multipliée par 2 (zoom du texte à 200% depuis les réglages du navigateur). À ce niveau de zoom, la présentation de la page peut être altérée, mais l’information doit rester lisible (pas de texte tronqué, ni superposé).

De plus, il faut s'assurer de faire du contenu web adaptatif (responsive web design) donc prévoir les différents affichages selon des largeurs type d'écran (points de rupture) en amont du développement.

Par ailleurs, certains choix de design peuvent ou non faciliter la mise en place de ce critère lors du développement, il est donc important d’y réfléchir dès le départ.

Exemple :
La capture ci-dessous montre une page avec un zoom à 100%.
capture d’écran avec zoom à 100%

Exemple valide :
Avec zoom du texte à 200%.
capture d’écran avec zoom à 200% et texte lisible

Exemple non-valide :
Avec zoom du texte à 200%. Ici la hauteur de l’élément contenant le texte n’a pas été rendue variable en fonction de la taille des caractères.
capture d’écran avec zoom à 200% et texte tronqué

8. Permettre d'aérer le texte

Cible : tout le monde, et en particulier les personnes déficientes visuelles et dyslexiques.
Quand : lors de la conception et du développement.

Même si c'est pendant la phase de développement que l'on va s'assurer de la validité de ce critère, il est intéressant dès la phase de conception de réfléchir à la hauteur des lignes et à l'espacement des paragraphes et du texte. Il est couramment admis qu'une hauteur de ligne (line-height) de 1.5 permet d'obtenir une bonne lisibilité du texte, exemple article en anglais intitulé : Why you shoud go big with line spacing.

Description :
Si l'utilisateur applique les réglages suivants, le texte doit rester lisible (pas de contenu tronqué, superposé):

  • La hauteur des lignes doit pouvoir être ajustée à 1.5 fois minimum la taille de la police de caractères.
  • L'espace situé entre deux paragraphes doit pouvoir être ajusté à 2 fois minimum la taille de la police de caractères.
  • L'espacement entre les lettres doit pouvoir être ajusté à 0.12 fois minimum la taille de la police de caractères.
  • L'espacement entre les mots doit pouvoir être ajusté à 0.16 fois minimum la taille de la police de caractères.

Pour info les critères cités précédemment reviennent à appliquer les styles CSS suivants au niveau de code :


  * {
      line-height: 1.5!important;
      letter-spacing:.12em!important;
      word-spacing: .16em !important;
  }

  p {
      margin-bottom: 2em!important;
  }

Pour faciliter le test, vous pouvez utiliser le bookmarklet suivant qui appliquera ces styles à la page courante de votre navigateur (bookmarklet à glisser dans votre barre de favoris) : Espacement du texte

9. Permettre le contrôle des animations

Cible : les personnes malvoyantes, les personnes éprouvant des difficultés de lecture, d’attention ou de compréhension, les personnes épileptiques.
Quand : lors de la conception du service et lors de la conception graphique.

Description :
Tout contenu en mouvement, mis à jour automatiquement, clignotant ou en défilement doit pouvoir être stoppé, caché ou mis en pause par l’utilisateur si cette animation dure plus de 5 secondes. Par ailleurs, éviter autant que possible les flashs lumineux et les changements brusques de luminosité (cf. Le logo des JO provoque des crises d’épilepsie).

Exemple :
capture d’écran d’un carrousel disposant d’un bouton pour mettre en pause l’animation

Un carrousel qui défile automatiquement doit se mettre en pause au survol de la souris ou lorsqu’il reçoit le focus.
Il est également possible d’ajouter un bouton « pause » directement dans l’interface.

10. Libellé des liens et des boutons

Cible : tout le monde et en particulier les personnes déficientes visuelles, cognitives ou ayant un déficit d’attention.
Quand : lors de la conception du service et lors de la conception graphique.

Description :
Les libellés des liens et des boutons doivent être suffisamment explicites. Dans les cas exceptionnels où ce n’est techniquement pas possible, prévoir quand même un libellé explicite qui sera utilisé par la synthèse vocale (et les autres technologies d'assistance).

Exemple valide :
« découvrez nos offres »

Exemples non-valides :
« cliquez ici »
« en savoir plus »

11. Permettre la navigation au clavier

Cible : tout le monde, en particulier les personnes souffrant de handicap moteur ou visuel et en mobilité.
Quand : lors de la conception du service et lors du développement.

Description :
Toutes les fonctionnalités doivent être utilisables à l’aide du clavier uniquement. Le focus doit pouvoir être déplacé sur tous les éléments cliquables (à l’aide de la touche Tab).
Par ailleurs si des fonctionnalités sont spécifiques pour la souris (glisser-déposer, menu apparaissant au clic droit…), faire en sorte que celles-ci soient également disponibles via un autre moyen ailleurs dans l’interface (bouton, icône, menu…).

Voir la façon de naviguer au clavier dans un navigateur web.

Exemple :
Dans un webmail, si un clic droit sur le dossier « Corbeille » permet d’accéder à un menu pour vider la corbeille, cette option doit être également disponible via un bouton « Vider la corbeille » ailleurs dans l’interface ou depuis un menu déroulant accessible au clavier.

12. Rendre utilisables les formulaires

Cible : tout le monde et en particulier les personnes déficientes visuelles, dyslexiques et les déficients cognitifs.
Quand : lors de la conception et lors du développement.

Description :
Chaque champ de formulaire doit être accompagné d’un libellé (ou d'instructions) permettant d’identifier le rôle du champ, le type de donnée et le format attendu. Ce libellé doit être proche visuellement du champ afin que l'utilisateur fasse facilement le lien entre eux (notamment pour les utilisateurs de zoom, de loupe logicielle, voire sur mobile).

Les champs en erreur doivent pouvoir être identifiés et, si besoin, suggérer une correction. Ceci s’applique aux champs de saisie, mais également aux autres types de champs (liste déroulante, bouton radio, case à cocher…). Au niveau du développement, ce libellé sera associé au champ de formulaire pour faciliter la navigation à l’aide d’un lecteur d’écran.

Exemple valide :
capture d’écran d’un formulaire valide

Exemple non-valide :
capture d’écran d’un formulaire auquel il manque un label

Dans certains cas, il semble inutile d’accompagner le champ de formulaire d’un libellé (champ de recherche accompagné d’un bouton en forme de loupe par exemple). Dans ce cas prévoir tout de même un libellé. Celui-ci ne sera pas affiché à l’écran mais sera tout de même associé au champ de formulaire lors du développement pour faciliter la navigation à l’aide d’un lecteur d’écran.

Enfin les libellés des messages d’erreur doivent être explicites.

Exemple valide :
capture d’écran d’un formulaire affichant des messages d’erreur à la saisie valides

Exemple non-valide :
capture d’écran d’un formulaire affichant des messages d’erreur à la saisie non-valides

13. Éviter les boites de dialogues et l’ouverture de nouvelles fenêtres

Cible : les seniors, les personnes déficientes cognitives, malvoyantes ou en mobilité.
Quand : lors de la conception et lors du développement.

Description :
Éviter autant que possible les actions qui ouvrent une nouvelle fenêtre (ou un nouvel onglet) du navigateur. Si un lien déclenche l’ouverture d’une nouvelle fenêtre, il faudra lors du développement faire en sorte que le texte « nouvelle fenêtre » soit vocalisé par les lecteurs d’écran, afin que les personnes malvoyantes sachent qu’une nouvelle fenêtre s’ouvre.

De même, éviter le recours systématique aux boîtes de dialogue pour présenter des informations dans les pages (présentation du service …). Elles doivent être réservées à une information importante qui requiert une attention immédiate et rester de taille réduite.

Ces fenêtres modales ou pop-in posent souvent des problèmes d’accessibilité pour les personnes qui naviguent au clavier ou au lecteur d’écran, problèmes qui nécessiteront une attention particulière lors de la phase de développement.

Exemple non-valide :
Dans l’exemple ci-dessous le recours à une boîte de dialogue n’est pas justifié. L’utilisation d’une page web standard permettrait :

  • de laisser plus d’espace au contenu (en supprimant les marges autour de la boite de dialogue),
  • de pouvoir utiliser le bouton « Précédent » du navigateur pour revenir en arrière lors de la navigation entre les différentes pages de la boite de dialogue,
  • de faciliter l’affichage sur les petits écrans,
  • d’éviter des problèmes d’accessibilité pour les personnes qui naviguent à l’aide du clavier ou à l’aide d’un lecteur d’écran,
  • d’alléger le poids de la page et le temps de chargement, car dans cet exemple la page derrière la boite de dialogue doit être chargée.

Capture d’écran d’une boîte de dialogue beaucoup trop volumineuse

14. Fournir des liens d’évitement

Cible : utile pour les utilisateurs de mobile et tablette, les personnes déficientes visuelles et les personnes souffrant de handicap moteur ou en mobilité.

Quand : dès la phase de conception et lors du développement.

Description :
Fournir des liens d’évitement du type « Aller au contenu » sur chaque page. Ceux-ci facilitent la navigation pour les personnes utilisant le clavier, en mobilité ou navigant à l’aide d’un lecteur d’écran. En cas de fortes contraintes, les liens peuvent être masqués à l’écran et apparaître uniquement lors de la navigation au clavier.

Exemple :
Des liens d’évitement (« Aller à la navigation », « Aller au contenu ») sont disponibles sur ce site. Pour les faire apparaître, placer le focus en haut de la page en cliquant sur la barre d’adresse de votre navigateur par exemple, puis appuyer plusieurs fois sur la touche Tab.

capture d’écran du site orange.com

15. Identifier et conserver la cohérence des regroupements et des différentes régions de la page

Cible : tout le monde et en particulier les personnes déficientes visuelles, cognitives ou ayant des troubles de l’attention.

Quand : lors de la conception.

Description :
Fournir des moyens d’identifier et de distinguer visuellement les différentes parties de la page et assurer la cohérence de ces régions ou regroupements dans toutes les pages.

À vérifier :

  • S’assurer que les mécanismes de navigation sont toujours situés au même endroit dans un ensemble de page.
  • S’assurer que les composants et les regroupements qui ont la même fonction, sont identifiés (visuellement) de la même façon et, dans la mesure du possible, respecter l’apparence classique de ces éléments pour ne pas perturber l’utilisateur habitué à un aspect spécifique de ceux-ci (par exemple, les liens sont généralement soulignés…).
  • S’assurer que les zones de la page sont clairement délimitées (bordures, filets, contraste suffisant…) ou qu’il y a un moyen de distinguer visuellement les groupes (sous-menu, liste déroulante…) ainsi que les différentes régions de la page.

Exemple valide :

capture d’écran du site 100% pratique

Ici, l’info bulle (tooltip) est délimitée par une bordure bien visible et suffisamment contrastée, permettant de bien identifier son contenu.

Exemple non-valide :

capture d’écran du site fnac.com

Il est très difficile d’associer les thèmes (« par région », « par genre »…) et les sous-thèmes en colonnes, d’autant plus que les filets horizontaux sont trop peu contrastés.

16. Situer explicitement la page dans le site et fournir plusieurs moyens d'y accéder

Cible : tout le monde et en particulier les personnes déficientes visuelles ou cognitives.

Quand : lors de la conception.

Description : Donner à l’utilisateur plusieurs moyens de situer et accéder à un contenu spécifique, localiser la page Web en cours de consultation dans un ensemble de pages. Lorsque la page est une étape dans un processus où les pages s’enchaînent les unes après les autres, ce critère peut être ignoré.

À vérifier : S’assurer que plusieurs systèmes permettent de situer et accéder à une page ou un contenu dans le site : un outil de recherche sur l’ensemble du site, un plan du site, un menu de navigation global, un fil d’Ariane…

Exemple valide : Le site propose, à la fois, une navigation principale complète et précise et un fil d’Ariane.

Exemple invalide : Une application offre un menu de navigation parcellaire et aucun autre moyen pour l’utilisateur de s’orienter dans les pages ou de repérer où se situe la page courante dans l’arborescence.

17. Éviter les captcha

Cible : tous le monde en particulier, les personnes déficientes visuelles.
Quand : lors de la conception et lors du développement.

Description :
Les captcha sont souvent la source de difficultés pour les utilisateurs. Si la mise en place d’un système anti-spam ne peut être évitée, il est souhaitable de s’orienter vers une solution plus souple pour l’utilisateur :

  • Double authentification ;
  • Champ de formulaire caché à laisser vide (technique du honeypot), non-visibles pour l’utilisateur ;
  • Mise à disposition d'un support téléphonique afin de s'assurer que le client est une vraie personne ;
  • Un contrôle permettant de s'assurer qu'une même combinaison IP/User agent (navigateur) ne tente pas de soumettre le formulaire plus de N fois par seconde.

Si aucune autre alternative n’est possible, il est indispensable de prévoir une alternative pour les captcha uniquement visuels ou sonores en proposant une combinaison de captcha :

  • un captcha audio + visuel,
  • des tests logiques (question dont la réponse est évidente, test mathématique simple…) + captcha visuel classique

18. Définir des zones sensibles de taille suffisante

Cible : tous le monde en particulier, les personnes souffrant de handicap moteur ou visuel et en mobilité.
Quand : lors de la conception et lors du développement.

Description :
Chaque zone sensible doit avoir une taille suffisante (9mm minimum de largeur et de hauteur). Par ailleurs les zones sensibles doivent être suffisamment espacées les unes des autres (environ 2mm minimum).

21. Proposer une alternative aux gestuelles complexes

Cible : tous le monde en particulier, les personnes souffrant de handicap moteur ou visuel et en mobilité.
Quand : lors de la conception et lors du développement.

Description :
Pour chaque interaction gestuelle complexe, une alternative doit être disponible (par exemple une alternative non gestuelle ou simplifiée). De même pour les interactions nécessitant un changement d'orientation de l'écran (basculement, rotation, secouement...).

22. Donner accès au contenu quelle que soit l'orientation de l'écran

Cible : tous le monde en particulier, les personnes souffrant de handicap moteur ou visuel et en mobilité.
Quand : lors de la conception et lors du développement.

Description :
L'accès au contenu ne doit pas dépendre de l'orientation de l'écran (portrait et paysage).

23. Rendre accessible les pistes audio ou vidéo

Cible : tout le monde, et en particulier les personnes déficientes visuelles, cognitives et auditives et celles qui maîtrisent mal le français.
Quand : lors de la conception et lors du développement.

Description :

Pour être accessibles, les contenus multimédias doivent :

  1. proposer une transcription intégrale
  2. proposer des sous-titres (vidéo uniquement)
  3. proposer une audiodescription (vidéo uniquement)
  4. choisir un lecteur média accessible
  5. proscrire le démarrage automatique de la vidéo au chargement de la page
  6. proscrire les vidéos qui présentent plus de 3 flashs à la seconde
  7. par ailleurs, pour tout son émis de plus de 3 secondes, l'utilisateur doit avoir la possibilité soit de l'arrêter ou de le mettre en pause soit d'en contrôler son volume indépendamment du volume général du système.

Pour plus d'infos consulter les recommandations accessibilité pour les contenus vidéos, animations et audios Orange.

Objectif utilisateur :

Fournir un moyen d’accès à l’information visuelle et auditive pour des personnes ne pouvant pas en bénéficier : malvoyants, aveugles, sourds, déficients cognitifs, ordinateur sans haut-parleurs, en environnement lumineux ou bruyant.

Objectif technique :

Permet le référencement de tout contenu audio et vidéo.