Propulsé par le RAAMM

Perceptible

Le problème

Les contenus non textuels comme les images ne sont pas perceptibles pour les personnes aveugles, ou difficilement perceptibles pour les personnes malvoyantes. De même, un contenu audio n’est pas perceptible par les personnes sourdes, ou difficilement perceptible par les personnes malentendantes.

Comme il s’agit ici de perception, ce sont les personnes ayant des limitations sensorielles qui vivent des situations de handicap si les contenus non textuels ne sont pas transmis sous forme de texte.

Il en va de même pour un contenu audio. Comme on peut aisément l’imaginer, un contenu jugé purement décoratif n’a pas besoin d’un texte de remplacement. Ce contenu devra donc être intégré de manière à être ignoré par l’utilisateur.

Le texte de remplacement (appelé aussi « équivalent textuel ») d’une image informative doit proposer un contenu équivalent afin de transmettre la même information sous forme de texte. Ce n’est donc pas tant l’apparence de l’image qui importe que sa fonction ou son message.

La solution

Voici quelques consignes à propos des images :

  • Les images informatives doivent être insérées dans le code HTML plutôt que dans la feuille de style, et avoir un texte de remplacement dans l’attribut alt.
  • Le contenu de l’attribut alt doit être court, quelques phrases avec ponctuation, et devrait toujours se terminer par un point final, afin d’obliger la synthèse vocale à marquer une pause avant d’enchaîner avec la lecture de la suite.
  • Tout le texte apparaissant sur une image, qu’elle soit ou non utilisée comme lien, doit être repris dans l’attribut alt, à moins que ce texte soit décoratif (on peut y ajouter au besoin, mais on ne peut rien y retrancher).
  • Une série d’images véhiculant un seul message doit avoir un texte de remplacement sur une seule d’entre elles, qui donne le message du groupe d’images (ex. 5 étoiles distinctes pour évaluer un seul contenu).
  • Les images purement décoratives ont des attributs alt et title vides ou sont traitées par la feuille de style. C’est le cas notamment des puces personnalisées.
  • Les images dont la légende véhicule déjà une information équivalente ont des attributs alt et title vides.
  • Les liens textuels et les liens-images adjacents doivent être combinés en un seul lien : l’image est alors considérée comme décorative.
  • Une banque de photos à affichage aléatoire doit inclure un alt approprié pour chaque photo de la banque.
  • Un carrousel doit comporter un texte de remplacement pour chaque image, annoncer le nombre d’images disponibles et offrir un moyen simple de figer le carrousel et de se déplacer d’une image à l’autre.
  • Les images plus complexes comme les diagrammes, les schémas ou les graphes ne peuvent souvent être décrites en quelques courtes phrases, et exigent souvent une structuration de l’information descriptive avec des en-têtes de section, des listes ou des tableaux. Pour les images de ce type, il faut insérer une description complète sur la même page ou sur une autre page :
    • Si cette description est placée sur une autre page, celle-ci peut être atteinte par un simple lien placé immédiatement avant, après ou sur l’image directement, dans ce dernier cas, le alt de l’image devrait ajouter à la fin la mention suivante : « Ce lien conduit à une description complète qui s’affichera dans une nouvelle fenêtre. »
    • S’il s’agit d’un lien, il est aussi souhaitable qu’il s’ouvre dans une nouvelle fenêtre et doit donc comporter un avertissement à cet effet.
  • Les images à liens multiples sont accessibles seulement « côté client », et chaque zone sensible doit avoir son propre texte de remplacement.
  • Le alt des images utilisées comme icône de navigation ou bouton de formulaire doit décrire la fonction du bouton plutôt que son apparence.
  • Les dessins réalisés à l’aide de caractères doivent être présentés sous forme d’image avec un alt, y compris les émoticônes et le leetspeak.
Exemples d’images intégrées depuis la balise <img> et de leurs équivalents
Rôle de l’image Exemples et contexte Équivalent textuel
Effet décoratif Images utilisées pour améliorer l’esthétique alt=""
Photo de la personne dont on parle Photo du ministre dans un article sur sa nomination. alt="Photo du ministre X."
Photo d’un employé dans le répertoire du personnel alt="" parce qu’on a déjà le nom de l’employé
Photo du récipiendaire d’un prix d’excellence. Utiliser une légende visible pour tous plutôt qu’un alt, car tous les lecteurs veulent savoir le nom du récipiendaire et celui des personnes qui l’entourent
Illustration d’un événement ou d’un enjeu dont on traite dans un article Une photo générique montrant une rue inondée dans un article à propos de la croissance des coûts d’assurance alt=""
Photo d’une rue facilement reconnaissable montrant la hauteur atteinte par l’eau dans un article à propos des inondations récentes Utiliser une légende pour identifier la rue prise en photo.
Illustration d’un produit dans une page le décrivant Photo de la couverture d’un CD dans une page donnant de l’information sur l’artiste, le titre des chansons, le genre de musique, etc. alt=""
Une publicité ou l’annonce d’une événement promotionnel Photo d’un orchestre comprenant un texte annonçant la date et le lieu d’un prochain concert. Cette information n’est pas présentée ailleurs sur la page Inclure dans le alt tout le texte apparaissant dans l’image.
Photo d’un village de vacances sur le bord de la mer montrant le prix de départ. L’information sur les prix est présentée dans le texte d’accompagnement. alt=""
Image agissant comme lien vers une autre page ou ressource Photo miniature, icône, logo d’un programme de commandite ou d’un partenaire Rédiger un alt comme s’il s’agissait d’un lien textuel, en identifiant la cible du lien plutôt que l’apparence de l’image.
Lien-image adjacente à un lien textuel et redondante par rapport à celui-ci L’illustration de couverture d’un livre est utilisée comme lien vers sa description et cette image est adjacente à un lien textuel sur le titre du livre. Fusionner les deux liens et mettre un alt="" pour l’image.
Fournir de l’information de façon visuelle Organigramme, diagramme, graphique de type camembert, carte Utiliser alt="" avec une description complète dans le texte adjacent (ou)
placer l’image dans un lien avec alt="Organigramme de l'organisation. Ce lien conduit à une description complète."
Capture d’écran d’un menu qui est utilisée dans une page d’aide à l’utilisateur. alt="" si toutes les étapes de l’utilisation sont données dans le texte ou
alt="Capture d'écran du menu où le pointeur de la souris est placé sur l'item Imprimer…"
Images multiples pour un message unique Cinq étoiles dont 3 sont colorées pour indiquer l’appréciation moyenne des utilisateurs Utiliser le alt="3 étoiles sur 5." sur l’une des image et un alt="" sur les quatre autres images

Exercice sur les équivalents textuels.

On peut masquer un élément ou un cadre avec l’attribut aria-hidden="true" et donner un contenu équivalent en utilisant du texte hors écran. Pour plus de détails, voir les explications données par WebAim en anglais : Positioning content off-screen. Toutefois, cet élément ne doit pas contenir de lien ou de bouton qui peuvent recevoir le focus qui peuvent être masqués avec cette méthode. Dans certains cas,, on peut offrir un lien pour les contourner en sautant par desssus.

Si le contenu non textuel est un test (comme un test de perception visuelle ou auditive) ou tout autre contenu qui ne peut être rendu sous une forme textuelle (comme une expérience sensorielle spécifique), l’équivalent textuel doit au moins fournir une identification descriptive de ce contenu. Ex. : « Thème de la 6e symphonie de Beethoven. » ou « Animation visuelle non représentative intitulée « Évolution » et créée par x en 2002 à l’occasion de l’exposition Images du futur. »

S’il s’agit d’un CAPTCHA, il faut prévoir plusieurs modalités sensorielles, comme un CAPTCHA visuel, audio ou textuel (question simple). Les boutons permettant d’accéder à ces autres modalités doivent évidemment être eux-mêmes accessibles. Dans le cas d’un CAPTCHA audio, il est important de s’assurer que celui-ci est dans la même langue que la page.

Il est aussi recommandé de prévoir une autre modalité (comme un contact téléphonique sans frais) permettant de franchir cet obstacle pour les utilisateurs qui n’y arriveraient pas de façon autonome. Le texte de remplacement du CAPTCHA visuel pourrait être formulé comme suit : « Image de test dont vous devez recopier les caractères déformés afin de vous identifier comme humain. Ce test vise à rejeter les demandes faites par des robots informatiques. Une alternative audio de ce test est aussi offerte. »

S’il s’agit d’un document téléchargeable, ce document est soumis aux mêmes règles pour l’accessibilité qu’un contenu HTML et CSS, il doit donc être directement accessible ou être accompagné d’une version de remplacement entièrement accessible.

Les règles qui s’appliquent aux contenus non textuels

1.1.1 Contenu non textuel (niveau A) : tout contenu non textuel présenté à l’utilisateur a un équivalent textuel qui remplit une fonction équivalente sauf dans les situations énumérées ci-dessous.

  • Composant d’interface ou de saisie : si le contenu non textuel est un composant d’interface ou s’il permet la saisie d’informations par l’utilisateur, alors il a un nom qui décrit sa fonction. (Se référer à la Règle 4.1 pour des exigences supplémentaires à propos des composants d’interfaces utilisateur ou des contenus qui permettent la saisie d’informations par l’utilisateur).
  • Media temporel : si le contenu non textuel est un média temporel, alors l’équivalent textuel fournit au moins une identification descriptive du contenu non textuel. (Se référer à la Règle 1.2 pour des exigences supplémentaires concernant les médias temporels).
  • Test : si le contenu non textuel est un test ou un exercice qui serait invalide s’il était présenté en texte, alors l’équivalent textuel fournit au moins une identification descriptive du contenu non textuel.
  • Contenu sensoriel : si le contenu non textuel vise d’abord à créer une expérience sensorielle spécifique, l’équivalent textuel fournit au moins une identification descriptive de ce contenu non textuel.
  • CAPTCHA : si ce contenu non textuel vise à confirmer que le contenu est consulté par une personne plutôt que par un ordinateur, alors un équivalent textuel est fourni pour identifier et décrire la fonction du contenu non textuel, et des formes alternatives du CAPTCHA sont proposées pour différents types de perception sensorielle, afin d’accommoder différents types de limitations fonctionnelles.
  • Décoration, formatage, invisibilité : si le contenu non textuel est purement décoratif, s’il est utilisé seulement pour un formatage visuel ou s’il n’est pas présenté à l’utilisateur, alors il est implémenté de manière à être ignoré par les technologies d’assistance.

Voir aussi :

Le problème

Les personnes ayant des limitations visuelles peuvent avoir de la difficulté à percevoir l’information d’une vidéo qui est transmise seulement par la piste visuelle. La trame sonore qui leur est accessible ne transmet pas toujours, à elle seule, toute l’information disponible.

De même, les personnes ayant à la fois des limitations visuelles et auditives ne peuvent percevoir une vidéo présentant simultanément une piste visuelle et une piste sonore.

La solution

Deux moyens doivent être mis en œuvre pour rendre les médias temporels perceptibles à cette clientèle : (1) une version de remplacement pour un média temporel,  et (2) une audiodescription.

La version de remplacement pour un média temporel est aussi appelée « transcription textuelle ». Il s’agit d’un document présentant, dans un ordre correct, une description des contenus visuels et sonores d’un média temporel, et offrant une façon équivalente d’interagir avec ce contenu.

Cette transcription est un texte qui accompagne la vidéo, et qui peut la remplacer entièrement, en donnant aussi bien l’information visuelle que sonore. C’est notamment le seul moyen d’accéder à ce type de contenu pour une personne sourde-aveugle.

Un lien doit être placé immédiatement avant ou après le média temporel, afin de faciliter l’accès à la version de remplacement.

Quant à l’audiodescription, il s’agit d’une narration ajoutée à une piste sonore pour décrire les détails visuels importants qui ne peuvent être compris à partir de la piste sonore principale seulement.

L’audiodescription peut être normale ou étendue :

  • L’audiodesription normale utilise les blancs du dialogue pour insérer ces informations.
  • L’audiodescription étendue fige la vidéo lorsque ces blancs n’offrent pas le temps nécessaire à l’insertion des descriptions. La vidéo reprend son cours dès que l’audiodescription a donné l’information pertinente.

L’audiodescription se présente habituellement sous la forme d’une piste audio additionnelle que l’utilisateur peut choisir d’activer ou non.

AMI-télé utilise aussi de l’audiodescription intégrée pour les contenus qu’elle produit. L’audiodescription est alors directement intégrée à la piste sonore originale. Par exemple, pour une émission de cuisine, les cuisiniers vont décrire au fur et à mesure toutes les opérations effectuées.

Ces moyens ne concernent que des médias préenregistrés et sont gradués selon le niveau de priorité :

  • Au niveau A :
    • Une version de remplacement pour un média temporel seulement vidéo, qui peut prendre la forme d’un texte ou d’une piste audio ajoutée à la vidéo;
    • Une audiodescription OU une version de remplacement pour un média temporel audio-vidéo.
  • Au niveau AA :
    • Une audiodescription.
  • Au niveau AAA :
    • Une audiodescription étendue;
    • Une version de remplacement pour un média temporel.

La transcription textuelle est facile à réaliser une fois que la vidéo est déjà sous-titrée (voir la section sur les médias temporels pour les personnes ayant des limitations auditives). Il suffit :

  • d’exporter les sous-titres de la vidéo en format SBV (c’est le plus facile à nettoyer);
  • d’enlever les lignes de marqueurs temporels;
  • de regrouper le contenu par courts paragraphes;
  • et d’insérer les informations qui ne sont perceptibles qu’à partir de la piste visuelle, dont voici quelques exemples ci-dessous. Ce type d’information est normalement déjà donné dans le scénario, mais celui-ci doit être révisé suite à la réalisation de la vidéo afin de s’assurer que ces indications sont bien à jour :
    • affichage de texte (par exemple, le générique);
    • changements de lieu (scène de jour vs de nuit, intérieur ou extérieur…);
    • actions et expressions (arme au poing, sourire…);
    • identification des personnages (lorsqu’il y a ambiguïté à partir du dialogue);
    • provenance des sons (naturels et artificiels), etc.

Voici quelques exemples de transcriptions textuelles. Les vidéos sont diffusées au bas de la page des services de l’Institut Nazareth et Louis-Braille.

Le site YouTube permet non seulement d’ajouter des sous-titres, mais aussi une description. Tout bon lecteur vidéo doit d’ailleurs prévoir ces deux fonctions, bien que la description puisse aussi être affichée sous le lecteur vidéo ou via un lien immédiatement à la suite du lecteur vidéo.

L’ajout d’une audiodescription est un travail qui devrait être confié à un professionnel de la vidéo, car il requiert la réalisation d’une piste audio supplémentaire qui doit être synchronisée avec la vidéo. On peut offrir le choix entre une audiodescription standard où l’on n’utilise que les plages libres de dialogue ou l’audiodescription étendue qui gèlera la vidéo le temps nécessaire pour entrer chaque passage narratif de l’audiodescription. L’audiodescription standard oblige à faire des choix souvent difficiles parmi les informations à transmettre, ce qui n’est pas le cas de l’audiodescription étendue.

Vous pouvez aussi consulter le guide VD du canal AMI-Télé. Notez bien que certains intervenants préfèrent le terme vidéodescription.

Les règles qui s’appliquent aux limitations visuelles

1.2.1 Contenu seulement audio ou vidéo (préenregistré) (niveau A) : pour des médias préenregistrés seulement audio et préenregistrés seulement vidéo, sauf si l’audio ou la vidéo sont un média de remplacement pour un texte et qu’ils sont clairement identifiés comme tels :

  • Contenu préenregistré seulement vidéo : fournir, soit une version de remplacement pour un média temporel, soit une piste audio (présentant une information équivalente) pour un contenu préenregistré seulement vidéo.

1.2.3 Audiodescription ou version de remplacement pour un média temporel (préenregistré) (niveau A) : fournir une version de remplacement pour un média temporel ou une audiodescription du contenu vidéo préenregistré pour un média synchronisé, excepté quand le média est un média de remplacement pour un texte et qu’il est clairement identifié comme tel.

1.2.5 Audiodescription (préenregistrée) (niveau AA) : fournir une audiodescription pour tout contenu vidéo préenregistré, sous forme de média synchronisé.

1.2.7 Audiodescription étendue (préenregistrée) (niveau AAA) : lorsque les blancs présents dans le fond sonore ne sont pas suffisants pour permettre à l’audiodescription de transmettre le sens de la vidéo, fournir une audiodescription étendue pour tout contenu vidéo préenregistré sous la forme de média synchronisé.

1.2.8 Version de remplacement pour un média temporel (préenregistrée) (niveau AAA) : fournir une version de remplacement pour un média temporel, pour tout contenu de type média synchronisé préenregistré et pour tout média préenregistré seulement vidéo.

Voir aussi :

Le problème

Les personnes ayant des limitations auditives éprouvent de la difficulté à percevoir l’information d’une vidéo qui est transmise seulement par la piste audio. La piste vidéo doit donc incorporer une version texte de l’information sonore significative (parole et bruits significatifs), nécessaire à la compréhension de la vidéo, sous la forme de sous-titres.

La solution

Deux moyens peuvent être mis en œuvre pour rendre les médias temporels perceptibles à cette clientèle :

  1. des sous-titres, qui vont reprendre le contenu des dialogues en identifiant l’interlocuteur et les bruits significatifs (ex. claquement de porte, rires hors champ, etc.).
  2. un médaillon en langue des signes.

WCAG 2.0 introduit l’idée d’un médaillon en langue des signes. Il faut cependant noter que la langue des signes varie selon la langue parlée correspondante, mais aussi selon le pays. Par exemple, la langue des signes française est différente de la langue des signes québécoise. Il est donc impossible de produire un médaillon universel, ou même un médaillon aussi bien compris par les Québécois francophones que par les francophones d’outre-Atlantique. Il est donc important de pouvoir cibler précisément le public visé, mais aussi d’offrir des sous-titres.

Ces moyens sont gradués selon le niveau de priorité, en tenant compte du fait que le média temporel est pré-enregistré ou en direct :

  1. Au niveau A :
    • Une version de remplacement pour un média temporel seulement audio.
    • Des sous-titres pour une vidéo pré-enregistrée.
  2. Au niveau AA :
    • Des sous-titres pour une vidéo en direct.
  3. Au niveau AAA :
    • Une interprétation en langue des signes pour une vidéo pré-enregistrée.
    • Une version de remplacement textuelle pour un contenu seulement audio en direct.

Différents outils gratuits permettent de sous-titrer une vidéo en ligne, notamment :

Il faut compter de 10 à 15 minutes de travail par minute de vidéo.

Voici quelques conseils pratiques :

  • Les sous-titres doivent être correctement orthographiés et ponctués.
  • Ne pas aller au-delà de 180 mots à la minute (environ trois mots à la seconde). Si le dialogue est plus rapide, il faut simplifier le contenu en éliminant des mots qui ne sont pas essentiels et des répétitions ou en simplifiant le vocabulaire.
  • Le saut de ligne (Maj+Retour), dans un sous-titre qui se présente sur deux lignes, doit tenir compte de la ponctuation ou des pauses naturelles pour en faciliter la lisibilité. Ne pas oublier qu’un nombre significatif d’utilisateurs ne seront pas à l’aise avec le français écrit et qu’il faut donc rendre le texte des sous-titres le plus « lisible » possible.
  • Les sous-titres doivent être présentés au bas de l’écran en utilisant une police sans empattements (sans sérif) et avec un contraste fort d’au moins 7 pour 1, afin de s’adapter à différents contextes d’éclairage ambiant.
  • Certains auteurs recommandent d’éviter le contraste maximal (blanc sur noir) qui ne facilite pas la lisibilité pour certains utilisateurs. Si possible, il est préférable d’afficher les sous-titres sous la vidéo plutôt que superposés à celle-ci.
  • L’alternance entre les interlocuteurs peut être marquée par des tirets ou par une identification (si possible abrégée) de la personne qui parle.
  • Les voix hors champ doivent aussi être identifiées lorsque possible. S’il s’agit d’un narrateur anonyme, l’identifier simplement comme narrateur.
  • Les effets sonores doivent être présentés de façon identique, entre crochets, par exemple.

Voici quelques exemples de vidéos dont les sous-titres sont activables à la demande, depuis l’option prévue à cet effet dans la console vidéo :

  • Vidéos sous-titrées dans la page des services de l’INLB (Institut Nazareth et Louis-Braille).
  • Certaines vidéos du site de l’ONF (Office national du film du Canada). Pour accéder aux vidéos sous-titrés du catalogue, il faut saisir un terme dans l’outil de recherche, puis activer la case à cocher « CC » dans les options de filtres. Notez que l’ONF utilise l’expression « sous-titrage pour malentendants ».

Enfin, la réalisation d’un médaillon en langue des signes nécessite l’intervention d’un interprète qualifié et d’un professionnel de la vidéo. Vous pourrez réduire le temps de tournage en donnant le scénario complet à l’interprète gestuel qui pourra le traduire en ce qu’il convient d’appeler du « français sourd », une reformulation qui respecte la construction de phrase et le vocabulaire qui caractérisent le langage gestuel.

Une fois réalisé, le médaillon peut être incrusté dans la vidéo ou, préférablement, présenté dans une zone distincte accolée à la vidéo. Comme pour les sous-titres, cela permettra de l’afficher seulement sur demande et d’éviter de masquer une partie du contenu visuel.

Pour en savoir plus sur l’offre d’un médaillon en langue des signes, vous pouvez consulter la technique suivante : G81: Providing a synchronized video of the sign language interpreter that can be displayed in a different viewport or overlaid on the image by the player.

Les règles qui s’appliquent aux limitations auditives

1.2.1 Contenu seulement audio ou vidéo (pré-enregistré) (niveau A) : pour des médias pré-enregistrés seulement audio et pré-enregistrés seulement vidéo, sauf si l’audio ou la vidéo sont un média de remplacement pour un texte et qu’ils sont clairement identifiés comme tels :

  • Contenu pré-enregistré seulement audio : fournir une version de remplacement pour un média temporel, présentant une information équivalente au contenu seulement audio.

1.2.2 Sous-titres (pré-enregistrés) (niveau A) : fournir des sous-titres pour tout contenu audio pré-enregistré dans un média synchronisé, excepté lorsque le média est un média de remplacement pour un texte et qu’il est clairement identifié comme tel.

1.2.4 Sous-titres (en direct) (niveau AA) : fournir des sous-titres pour tout contenu audio en direct, sous forme de média synchronisé.

1.2.6 Langue des signes (pré-enregistrée) (niveau AAA) : fournir une interprétation en langue des signes pour tout contenu audio pré-enregistré, sous forme de média synchronisé.

1.2.9 Seulement audio (en direct) (niveau AAA) : fournir une version de remplacement pour un média temporel, donnant une information équivalente pour un contenu seulement audio en direct.

Voir aussi :

Le problème

Un contenu web ou électronique est généralement subdivisé en sections, coiffées par un titre (ou en-tête de section), lui-même mis en évidence par différents effets de présentation (gras, gros caractères, couleur, etc.). Ces repères sont importants pour comprendre la structure du document et pour trouver plus rapidement le contenu qui intéresse le lecteur. Si ces indices visuels ne sont pas codés correctement, ils ne seront pas reconnus par les outils d’adaptation comme les lecteurs d’écran.

Lorsque les en-têtes de section sont bien codés :

  • Une personne ayant des limitations visuelles pourra les utiliser pour se déplacer rapidement au contenu qui l’intéresse. Elle ne sera donc pas obligée de lire toute la page pour trouver la section recherchée.
  • Une personne ayant des limitations motrices, qui l’obligent à naviguer sans l’aide de la souris, en bénéficiera également, les en-têtes devenant des « cibles » qu’un navigateur comme Opera ou un module complémentaire peuvent utiliser pour se déplacer directement à un contenu donné.
  • Une personne ayant des limitations cognitives, qui lit une page simultanément de façon visuelle et auditive (en synthèse vocale), utilisera les repères visuels qui sont également donnés de façon vocale.

Les listes et les citations sont des informations de structure importantes. Pour les personnes aveugles, ces informations sont données par un lecteur d’écran. À l’entrée dans une liste, le lecteur d’écran indique à l’utilisateur le nombre d’items inclus dans la liste, et si cette liste comprend des sous-listes imbriquées. Si, au contraire, une liste est simplement présentée comme une suite de lignes ou, pire, comme un tableau avec une colonne pour les puces et une autre pour les contenus, l’utilisateur aveugle perd cette information précieuse, qu’une personne sans limitations fonctionnelles peut constater d’un seul coup d’œil.

De même, il ne faut pas abuser des items de liste et des blocs de citation pour créer un effet visuel de retrait, car l’information transmise par le lecteur d’écran sera faussée et induira l’utilisateur en erreur.

La solution

En-têtes

Les en-têtes de section <h1> à <h6> constituent des points de repère extrêmement importants pour les personnes qui ne peuvent compter sur une vision globale de la page, afin de se faire une idée de son organisation ou pour naviguer dans le contenu sans souris.

Les personnes aveugles ou malvoyantes ainsi que les personnes ayant des limitations motrices ou cognitives pourront donc parcourir les en-têtes de section, qui constitueront, pour ainsi dire, une table des matières de la page.

Les en-têtes doivent constituer une structure logique avec au moins un <h1>, des <h2> pour marquer le début des grandes sections et des <h3> pour le début des sous-sections, etc.

Exemple de code pour les en-têtes
<h1>Les règles à suivre</h1> ...
  <h2>Références</h2> ...
  <h2>Deux thèmes majeurs</h2> ...
    <h3>Assurer une transformation élégante</h3> ...
    <h3>Rendre le contenu compréhensible et navigable</h3> ...
      <h4>Le système de navigation</h4> ...
  <h2>Les règles</h2>

Repères ou régions

Les repères (en anglais, landmarks) font partie des rôles de la spécification WAI-ARIA (en anglais). Ils permettent d’indiquer les grandes sections de la page. Ces rôles sont aussi reconnus par l’entremise de balises de la spécification HTML5. Il convient d’employer soit le rôle de région, soit la balise HTML5 correspondante, mais pas les deux en même temps. En effet, la recommandation ARIA in HTML mentionne d’éviter l’application redondante d’un rôle ARIA sur une balise HTML qui porte déjà ce rôle nativement.

Voici la liste des différents repères WAI-ARIA :

  • application :
    rôle qui désigne une région d’interaction directe avec le contenu et qui impose au lecteur d’écran de désactiver le mode navigation et de fonctionner uniquement en mode formulaire ou interactif, comme dans une boîte de dialogue modale du système d’exploitation. C’est à utiliser avec prudence. Voir aussi : Using ARIA role=application.
  • banner :
    rôle qui désigne une région contenant une bannière.
  • complementary :
    rôle qui désigne une région présentant un contenu complémentaire (par exemple, des informations placées dans une colonne à droite du contenu principal.
  • contentinfo :
    rôle qui désigne une région présentant les informations que l’on retrouve généralement en pied de page comme le copyright.
  • form :
    rôle qui désigne une région ne contenant qu’un formulaire. À ne pas confondre avec le rôle « search » utilisé pour un champ de recherche.
  • main :
    rôle qui désigne la région englobant le contenu principal de la page.
  • navigation :
    rôle qui désigne la région englobant un ou plusieurs menus de navigation.
  • region :
    rôle qui désigne une section importante du contenu qui doit être nommée avec l’attribut approprié. Il s’agit d’un rôle supplémentaire qui doit être utilisé seulement si les rôles ci-dessus ne sont pas plus pertinents.
  • search :
    rôle qui désigne la région englobant le formulaire de recherche.

Tableau de correspondances entre HTML5 et WAI-ARIA

Rôles ARIA Balises HTML5
role="banner" <header>
role="navigation" <nav>
role="main" <main>
role="contentinfo" <footer>
role="complementary" <aside>
role="region" <section>
Sans correspondance <article>
role="search" Pas de balise correspondante, mais il est possible d’employer un attribut type="search" pour un champ d’édition de recherche.
role="form" <form>

Il est conseillé de ne pas multiplier les régions de même nature.

Il vaut mieux aussi éviter de les imbriquer. Dans le cas contraire, il faut procéder à des tests avec un large éventail de lecteurs d’écran.

Il y aurait beaucoup à dire sur chacun de ces rôles, mais les plus utiles pour structurer le contenu d’une page sont : navigation, main, complementary et contentinfo.

L’utilisation des repères n’est encore exigée par aucun standard. Il s’agit donc d’une pratique facultative qui peut renforcer la compréhension de l’organisation du contenu par l’utilisateur. Les lecteurs d’écran permettent également de naviguer d’une région à l’autre à l’aide d’un raccourci clavier.

Exemple de code pour les régions
<div role="navigation"><ul>
<li><a href="index.html">Page d'accueil</a></li>
...
</ul>
</div>

Listes

Les énumérations présentées sous forme de listes doivent être codées comme des listes. De même, les balises de liste doivent être utilisées seulement dans un contexte de liste et non pour créer un effet de retrait.

Les menus doivent être codés sous forme de listes, afin que l’utilisateur sache dès l’entrée s’il s’agit d’un court menu ou d’un menu plus long. S’il y a des sous-menus, ils doivent être codés comme des listes imbriquées.

Ne pas abuser de listes imbriquées, qui sont beaucoup plus difficiles à comprendre pour les personnes qui n’en ont pas une vision globale : se limiter à un maximum de 3 niveaux et utiliser le plus souvent possible des listes à un seul niveau.

Sauf dans un menu, on peut remplacer un niveau de liste par des en-têtes de section.

Citations

Les citations d’un ou de plusieurs paragraphes doivent être codées comme telles à l’aide de la balise <blockquote>. La balise <blockquote> ne doit pas être utilisée pour créer un effet de retrait s’il ne s’agit pas d’une citation, car cela donnerait de fausses indications à l’utilisateur d’un lecteur d’écran. Cet effet visuel doit être géré par la feuille de style CSS.

Lorsque les variations dans la présentation du texte jouent un rôle important, le texte mis en évidence par divers procédés (gras, italique, plus gros caractères, police particulière, etc.) doit être balisé sémantiquement pour donner la même information à l’utilisateur d’un lecteur d’écran. Si cela n’est pas possible, l’information véhiculée par les changements dans la présentation du texte doit être redonnée en texte (visible ou non).

Le balisage doit être utilisé de façon sémantique, chaque type de balises jouant le rôle pour lequel elle a été conçue. Selon ce même principe, on ne peut inclure du contenu informatif en utilisant les pseudo-éléments:before et :after dans la feuille de style CSS, parce que ce contenu sera invisible pour les utilisateurs qui désactivent les styles CSS pour une meilleure lisibilité (taille des caractères, contrastes, etc).

De même, tout balisage de présentation doit être exclu, car la présentation doit être gérée entièrement par la feuille de style CSS.

Remarque : De nos jours, les combinaisons de lecteurs d’écran et de navigateurs modernes reconnaissent assez bien les contenus textuels transmis par les pseudo-éléments CSS :before et :after. Il convient malgré tout d’éviter l’emploi de ces éléments pour du contenu informatif, car il sera perdu lors d’une désactivation de la feuille de style.

Exemple de code pour les citations
<blockquote>
<p lang="en">Mark up quotations. Do not use quotation markup for formatting effects such as as indentation.</p>
<p><cite>WCAG 1.0, point de contrôle 3.7 </cite></p>
</blockquote>

Les règles qui s’appliquent à la perception de la structure

1.3.1 Information et relations (niveau A) : l’information, la structure et les relations véhiculées par la présentation peuvent être déterminées par un programme informatique ou sont disponibles sous forme de texte.

Voir aussi :

Le problème

Note : D’autres aspects de l’accessibilité des formulaires sont notamment traités dans les principes Utilisable (règle 2.4 Navigable) et Compréhensible (règle 3.3 Assistance à la saisie).

Pour être utilisable par une personne aveugle, un formulaire doit associer correctement les étiquettes et les champs de formulaire, afin qu’un lecteur d’écran puisse indiquer l’étiquette qui correspond au champ à remplir. Une association visuelle ne suffit pas : il faut que cette association soit créée dans le code de la page pour qu’un lecteur d’écran puisse l’interpréter correctement, sans avoir à jouer aux devinettes, avec la marge d’erreur que cela suppose.

Les personnes ayant des limitations motrices auront de la difficulté à sélectionner un bouton radio ou une case à cocher qui occupent une très petite surface à l’écran. Toutefois, lorsque l’étiquette et le champ sont correctement associés, l’utilisateur pourra cliquer n’importe où dans l’étiquette pour cocher ce type de champ.

La solution

Étiquettes

Vous devez associer explicitement les étiquettes et les champs correspondants avec l’attribut for, qui reprend le id du champ auquel il est associé :

  • Donner un attribut id unique à chaque champ de formulaire.
  • Donner à chaque balise <label> un attribut for, qui reprend exactement le contenu de l’attribut id du champ correspondant (attention à la casse).

À moins que vous disposiez d’un outil spécialisé, cette association doit généralement être faite manuellement dans le code.

Dans certains exemples documentés par le W3C (en anglais), il n’est pas possible de procéder à une association explicite de l’étiquette et du champ. On peut alors effectuer une association dite implicite, en encadrant le libellé de l’étiquette et son champ à l’intérieur de la balise <label>. Cette technique est toutefois jugée moins optimale par le W3C, qui recommande de priviégier chaque fois que possible une association explicite.

Notez que les boutons de type submit et reset, les boutons-images et les champs cachés n’ont pas besoin d’étiquettes, car c’est la valeur qui en tient lieu.

Enfin, certains formulaires font usage de champs de saisie multiples (ex. : numéro de téléphone en plusieurs parties). Une erreur fréquente consiste à présenter ces champs d’une manière qui les rend uniquement identifiables par leur disposition visuelle. S’il n’est pas possible de fournir une étiquette <label> visible pour chaque champ, l’emploi d’une <legend> de <fieldset> est une bonne pratique, à condition d’utiliser un attribut title ou aria-label explicite pour chaque champ. Une autre option possible serait d’opter pour un seul champ d’édition de numéro de téléphone, à condition d’indiquer clairement le format attendu dans l’étiquette du champ, ou d’accepter tous les formats en filtrant les caractères inutiles.

Exemple de code pour l’association d’une étiquette à un champ
<form method="post" action="unepage.html">
<p> <label for="pnom">Prénom</label>
<input id="pnom" name="pnom" type="text" /></p>

<p> <label for="nomf">Nom de famille</label>
input id="nomf" name="nomf" type="text" /> </p>

</form>

Attribut title

Si on souhaite présenter un champ sans étiquette visible, il importe de donner à ce champ un nom accessible décrivant la saisie attendue, par exemple, au moyen d’un attribut title. C’est l’une des rares situations où les lecteurs d’écran liront le contenu de l’attribut title automatiquement. D’autres techniques sont aussi proposées dans le tutoriel Labelling Controls du W3C. On peut notamment se servir d’un attribut aria-label. Ou encore, employer une étiquette <label> positionnée hors écran, ce qui la rendra non visible tout en demeurant perceptible pour les lecteurs d’écran.

Il ne faut pas oublier, cependant, que l’étiquette joue un rôle explicatif pour tous vos visiteurs. Il est donc préférable que cette étiquette demeure visible et perceptible pour tout le monde, et ce, pour tout champ dont la fonction pourrait être ambiguë.

Par ailleurs, il faut éviter d’utiliser l’attribut placeholder pour remplacer une étiquette <label> ou un attribut title. L’emploi de l’attribut placeholder pose plusieurs problèmes. Pour les personnes malvoyantes, le contraste offert par défaut est trop faible et si on veut le renforcer, cela créera de la confusion avec le contenu réel d’un champ. Pour les personnes aveugles, le contenu de cet attribut n’est pas toujours lu par le lecteur d’écran à cause de sa disparition automatique au moment où on entre dans le champ. Pour les personnes qui ont des limitations cognitives ou qui ont des difficultés de concentration ou de mémorisation, la disparition du contenu affiché par cet attribut nuira à leur capacité de se souvenir de l’information demandée ou du format indiqué.

Exemple de code pour l’utilisation de l’attribut title
<form method="post" action="unepage.html">
<p> <input id="recherche" title="Recherche" name="rech" type="text" /> </p>
</form>

Balises fieldset et legend

Les balises <fieldset> et <legend> sont appropriées pour regrouper un petit nombre de champs de même nature comme un numéro de téléphone ou un groupe de cases à cocher qui répondent à une même question. Il faut cependant éviter d’en abuser en les utilisant pour subdiviser les différentes sections d’un formulaire. Pour ce faire, il vaut mieux utiliser des en-têtes de section, car les lecteurs d’écran permettent de se déplacer facilement d’une section à l’autre, mais ne comportent pas de commandes pour aller d’un <fieldset> à l’autre.

Groupes d’options

Lorsque c’est pertinent, les groupes d’options dans un champ de liste doivent être identifiés à l’aide de la balise <optgroup> et de l’attribut label. Cette identification est visuelle et peut donc aider à la compréhension, mais n’est pas lue par un lecteur d’écran.

Exemple de code pour les groupes d’options
<form action="https://example.com/prog/someprog" method="post">
<label for="food">Quel est votre aliment préféré?</label>
<select id="food" name="food">
<optgroup label="Fruits">
<option value="1">Pommes</option>
<option value="3">Bananes</option>
<option value="4">Pêches</option>
<option value="5">...</option> </optgroup>

<optgroup label="Légumes">
<option value="2">Carottes</option>
<option value="6">Concombres</option>
<option value="7">...</option> </optgroup>

<optgroup label="Aliments cuits">
<option value="8">Tarte aux pommes</option>
<option value="9">Gâteau au chocolat</option>
<option value="10">...</option>
</optgroup>

</select>
</form>

Les règles qui s’appliquent aux formulaires

1.3.1 Information et relations (niveau A) : l’information, la structure et les relations véhiculées par la présentation peuvent être déterminées par un programme informatique ou sont disponibles sous forme de texte.

Voir aussi :

Le problème

Les tableaux de données constituent un environnement complexe pour les utilisateurs aveugles ou malvoyants, parce qu’ils ne peuvent en avoir une vision globale qui leur permettrait d’en comprendre facilement l’organisation.

Pour qu’un lecteur d’écran soit en mesure de percevoir les relations entre les données et les en-têtes qui leur donnent un sens, les cellules d’en-tête doivent être distinguées des cellules de données, et les relations entre les cellules doivent être explicitées lorsqu’il s’agit de tableaux complexes.

La solution

Titre du tableau

Si un titre de tableau est utilisé, il ne doit pas être inclus dans le tableau (par exemple dans une cellule fusionnée occupant toute la première rangée), mais présenté avec la balise <caption> ou être coiffé par un titre de niveau approprié

Tableaux simples

Pour un tableau simple, le code est « simple ». Il suffit d’identifier les cellules d’en-tête de ligne et de colonne <th> (voir la technique H43 citée plus bas). Les lecteurs d’écran pourront ainsi indiquer à l’utilisateur le titre de la colonne ou de la ligne où il se trouve.

Il faut faire ici une distinction entre tableau simple et tableau régulier. Un tableau simple peut très bien être irrégulier, c’est-à-dire qu’il peut comporter un nombre variable de rangées et de colonnes à cause de la présence de cellules fusionnées horizontalement ou verticalement.

Toutefois, un tableau régulier qui comporte un nombre constant de rangées et de colonnes est toujours moins déroutant et donc plus facile à comprendre qu’un tableau irrégulier.

Exemple de code pour les cellules d’en-tête et les cellules de données dans un tableau simple
<table>
<tr>
<th>Date</th>
<th>Sujets</th>
</tr>
<tr>
<th>Jeudi 26 juin 2008</th>
<td>Module 3</td>
</tr>
<tr>
<th>Vendredi, 27 juin 2008</th>
<td>Module 4</td>
</tr>
</table>
Date Sujets
Jeudi 26 juin 2008 Module 3
Vendredi, 27 juin 2008 Module 4

Tableaux complexes

Un tableau complexe de données se distingue par le fait qu’il comporte plus d’une rangée d’en-têtes ou plus d’une colonne d’en-têtes ou par le fait qu’au moins une cellule de donnée réfère à plus de deux cellules d’en-têtes.

Un tableau complexe de données peut être régulier ou non, c’est-à-dire qu’il peut comporter ou non un nombre constant de rangées et de colonnes. Le fait qu’un tableau soit irrégulier ne suffit pas à le classer parmi les tableaux complexes, mais cette irrégularité ajoute certainement un niveau de difficulté supplémentaire pour l’utilisateur et devrait être évitée lorsque c’est possible. Notons d’ailleurs que les lecteurs d’écran ont de la difficulté avec les cellules fusionnées dans les tableaux complexes. JAWS est le meilleur dans ce domaine mais a de la difficulté à gérer les cellules fusionnées verticalement.

Il est donc important, chaque fois que possible, de concevoir des tableaux qui soient à la fois simples et réguliers. Le secrétariat du Conseil du Trésor a publié un Guide pour simplifier un tableau complexe de données (PDF). Ce guide suggère des avenues pour éviter de produire, en totalité ou en partie, des tableaux complexes de données afin de rendre le contenu plus facile à consulter pour toute personne, handicapée ou non.

Notons aussi qu’il est possible d’offrir une version de rechange où l’on résume l’ensemble des titres en une seule rangée et en une seule colonne et où l’on éclatera toutes les cellules fusionnées en répétant leur contenu autant de fois que nécessaire. Si l’on choisit cette approche, il faut offrir un lien vers cette version simplifiée immédiatement avant l’entrée dans le tableau de données complexe. Ce lien devrait conduire à une autre page qui devrait comporter quant à elle un lien pour revenir à la page originale, mais à la fin du tableau cette fois.

Exemple de simplification d’un tableau complexe

Version complexe :

Produits importés

Produits locaux

Fraises

Cerises

Fraises

Cerises

Catégorie A

Catégorie B

Catégorie A

Catégorie B
Gatineau En gros 1,00 $ 3,00 $ 2,00 $ 1,20 $ 3,00 $ 2,00 $
Au détail 2,00 $ 4,00 $ 3,00 $ 2,40 $ 4,00 $ 3,00 $
Gaspé En gros 1,50 $ S/O 3,00 $ 2,00 $ 4,00 $ 3,00 $
Au détail 2,50 $ S/O 4,00 $ 2,60 $ 5,00 $ 4,00 $

Version simplifiée :

Produits importés, Fraises Produits importés, Cerises, Catégorie A Produits importés, Cerises, Catégorie B Produits locaux, Fraises Produits locaux, Cerises, Catégorie A Produits locaux, Cerises, Catégorie B
Gatineau, En gros 1,00 $ 3,00 $ 2,00 $ 1,20 $ 3,00 $ 2,00 $
Gatineau, Au détail 2,00 $ 4,00 $ 3,00 $ 2,40 $ 4,00 $ 3,00 $
Gaspé, En gros 1,50 $ S/O 3,00 $ 2,00 $ 4,00 $ 3,00 $
Gaspé, Au détail 2,50 $ S/O 4,00 $ 2,60 $ 5,00 $ 4,00 $

Pour les tableaux complexes de données, vous devez associer explicitement toutes les cellules (sauf celles de la première ligne et de la première colonne) avec toutes les cellules d’en-têtes correspondantes.

Il faut donc d’abord assigner un attribut id unique (pour l’ensemble de la page) à chaque cellule d’en-tête.

Par la suite, il faut incorporer un attribut headers à chaque cellule de données. Cet attribut placera entre guillemets, séparés par un espace, tous les id des cellules de titre qui s’appliquent à la cellule courante. Les id doivent être placés dans leur ordre logique de lecture.

Ce travail doit habituellement être réalisé à la main directement dans le code, car la plupart des logiciels auteurs n’ont pas prévu d’interface pour le faire. Il existe toutefois un outil développé par Vision Australia (en anglais seulement) qui permet, non seulement d’évaluer un tableau complexe, mais aussi de le coder manuellement ou automatiquement avec les attributs id et headers. Vous trouverez l’outil par ce lien : Complex Data Table Markup Toolbar.

Pour plus de détails et des exemples, consultez la technique : H43: Using id and headers attributes to associate data cells with header cells in data tables.

Exemple de code pour l’utilisation de id et headers
<tr>
<th id="l1c1">Destination</th>
<th id="l1c2">Dates du déplacement</th>
<th id="l1c3">Repas</th>
<th id="l1c4">Hôtel</th>
<th id="l1c5">Transport</th>
<th id="l1c6">Total</th>
</tr>
<tr>
<th id="l2c1" headers="l1c1" rowspan="3">Gaspé</th>
<th id="l2c2" headers="l1c2 l2c1">25 août</th>
<td headers="l1c3 l2c1 l2c2">37</td>
<td headers="l1c4 l2c1 l2c2">112</td>
<td headers="l1c5 l2c1 l2c2">45</td>
<td headers="l1c6 l2c1 l2c2"> </td>
</tr>
<tr>
<th id="l3c2" headers="l1c2 l2c1">26 août</th>
<td headers="l1c3 l2c1 l3c2">27</td>
<td headers="l1c4 l2c1 l3c2">112</td>
<td headers="l1c5 l2c1 l3c2">45</td>
<td headers="l1c6 l2c1 l3c2"> </td>
</tr>
...
Rapport des frais de voyage
Destination Dates du déplacement Repas Hôtel Transport Total
Gaspé 25 août 37 112 45
26 août 27 112 45

Sommaire et légende

Les tableaux de données complexes d’un site Web public ont besoin d’un sommaire, et peuvent également bénéficier d’une légende.

Le sommaire peut compenser le manque de vision globale de l’utilisateur non-voyant en donnant une brève description de l’organisation du tableau. Il est inscrit dans l’attribut summary et peut être aussi long que nécessaire.

Un bon sommaire doit décrire les grandes catégories d’informations présentées par colonne et par ligne, et signaler les irrégularités éventuelles correspondant aux cellules fusionnées.

L’effet recherché ici est une vue d’ensemble, c’est pourquoi il n’est pas utile de reprendre dans le sommaire tous les titres de colonne et de ligne, mais plutôt d’en décrire les grandes catégories.

La légende, quant à elle, est une information complémentaire qui vient chapeauter un tableau à la façon d’un titre. Cette légende doit être enchassée dans une balise <caption>, qui doit être placée immédiatement sous la balise <table>.

Attention :

  1. Vous ne devez pas inscrire un sommaire vide (summary="") pour les tableaux de présentation, parce que c’est un des critères utilisés par les lecteurs d’écran pour distinguer entre les tableaux de présentation et les tableaux de données. De même, les tableaux de mise en page doivent être exempts de légende <caption> et de cellules d’en-tête <th>. Il est aussi de mise de donner un attribut ARIA  role="presentation" à la balise <table> d’un tableau de présention. Pour plus de détails sur ce dernier aspect, consulter la section de cette formation dédiée à WAI-ARIA et HTML5.
  2. Des données tabulaires ne doivent pas être formatées avec des espaces pour simuler un balisage correct, car l’utilisateur ne pourrait naviguer de cellule en cellule dans un tel tableau avec un lecteur d’écran.
Exemple de code pour l’utilisation d’un sommaire et d’une légende
<table summary="Ce tableau présente les frais de voyage. Par lignes, vous trouverez les destinations et les dates ainsi qu'un grand total. Par colonnes, sont présentées les catégories de dépenses ainsi qu'un total. Notez que la première colonne comporte des cellules fusionnées.>
<caption>Rapport des frais de voyage</caption>
</table> ...

Abréviations

Quand les titres des colonnes ou des lignes sont longs, et qu’il serait fastidieux pour l’utilisateur d’entendre répéter cette information à plusieurs reprises, il est préférable d’utiliser des abréviations. Par exemple, « Estimation des dépenses pour les soins de santé par les agences du Gouvernement durant la prochaine décennie » pourrait être abrégé par : « Estimation des dépenses ».

De même, si un tableau comporte déjà des abréviations dans les cellules d’en-tête, on peut utiliser cette même technique pour en donner une interprétation plus compréhensible. Par exemple, un calendrier dont les jours de la semaine sont identifiés par deux lettres seulement (lu, ma, me, etc.) et qui serait donc peu compréhensible en synthèse vocale.

Attention : Les abréviations utilisées dans les cellules d’en-têtes ne sont reconnues par JAWS que dans les tableaux codés avec les attributs id et headers, même s’il s’agit de tableaux simples.

Exemples de code pour l’utilisation d’abréviations dans un tableau complexe codé avec les attributs id et headers
<th abbr="Estimation des dépenses de santé"> Estimation des dépenses pour les soins de santé par les agences du Gouvernement durant la prochaine décennie</th>
(ou)
<th abbr="lundi">lu</th>

Dans un tableau de données simple, il vaut donc mieux utiliser la balise <abbr> plutôt que l’attribut du même nom.

Exemples de code pour l’utilisation d’abréviations dans un tableau simple
<th><abbr title="Estimation des dépenses de santé"> Estimation des dépenses pour les soins de santé par les agences du Gouvernement durant la prochaine décennie</abbr></th>

Les règles qui s’appliquent aux tableaux de données

1.3.1 Information et relations (niveau A) : l’information, la structure et les relations véhiculées par la présentation peuvent être déterminées par un programme informatique ou sont disponibles sous forme de texte.

Voir aussi :

Le problème

L’ordre de parcours du contenu est un élément important pour faciliter la compréhension de ce contenu. En HTML, l’ordre de lecture correspond à l’ordre du contenu dans le code source de la page, alors qu’en format PDF, il reflète l’ordre des balises. C’est dans cet ordre que le contenu sera lu par la synthèse vocale d’une personne ayant des limitations visuelles ou cognitives.

Cet ordre sera aussi celui dans lequel le contenu pourra être parcouru au clavier, avec la touche tabulation, par une personne dont les limitations motrices ne lui permettent pas d’utiliser une souris.

Il peut y avoir plus d’un ordre logique pour un parcours visuel de la page, mais un seul ordre peut être déterminé pour l’accessibilité.

La solution

Pour corriger ce type de problème, il suffit de modifier l’ordre de présentation du contenu dans le code source (ex. l’ordre des <div>).

Si la page n’utilise pas de tableaux de présentation, cet ordre peut être vérifié en désactivant la feuille de style.

Bien que les règles d’accessibilité recommandent l’utilisation des feuilles de style CSS pour contrôler la mise en page et la présentation, vous devez vous assurer que vos pages demeurent lisibles sans elles.

Le but recherché est la compatibilité avec les synthèses vocales et certains appareils mobiles et la possibilité de désactiver ou de remplacer la feuille de style du concepteur par celle de l’utilisateur, pour obtenir un environnement visuel mieux adapté à certains types de limitations en contrôlant la taille des caractères et les contrastes, par exemple.

Si la page utilise un ou plusieurs tableaux de présentation, vous devrez les linéariser pour vérifier que l’ordre de lecture est correct. Attention : il va sans dire qu’un tableau de données ne doit pas être linéarisé, et que dans une page linéarisée, il faudra donc faire abstraction du contenu des tableaux de données.

L’espacement entre les caractères d’un mot ne doit pas être contrôlé par l’insertion d’espaces, mais par la feuille de style (letter-spacing).

Si des changements de direction doivent être indiqués pour un texte qui se lirait de droite à gauche, il faut le faire avec l’attribut dir.

Exemple de code fautif pour l’ordre de lecture

<table>
<caption>Liste d'universités</caption>
<tr>
<td><strong>Université Bishop's</strong></td>
<td><strong>Université Concordia</strong></td>
</tr>
<tr>
<td>Sherbrooke : 819 822-9600</td>
<td>Montréal : 514 848-2424</td>
</tr>
<tr>
<td><strong>Université Laval</strong></td>
<td><strong>Université McGill</strong></td>
</tr>
<tr>
<td>Québec : 418 656-3333</td>
<td>Montréal : 514 398-4455</td>
</tr>
<tr>
<td><strong>Université de Montréal</strong></td>
<td><strong>HEC Montréal</strong></td>
</tr>
<tr>
<td>Montréal : 514 343-6111</td>
<td>Montréal : 514 340-6000</td>
</tr>
</table>

Illustration du résultat

Liste d’universités
Université Bishop’s Université Concordia
Sherbrooke : 819 822-9600 Montréal : 514 848-2424
Université Laval Université McGill
Québec : 418 656-3333 Montréal : 514 398-4455
Université de Montréal HEC Montréal
Montréal : 514 343-6111 Montréal : 514 340-6000

Présentation linéarisée :

Liste des universités
Université Bishop’s
Université Concordia
Sherbrooke : 819 822-9600
Montréal : 514 848-2424
Université Laval
Université McGill
Québec : 418 656-3333
Montréal : 514 398-4455
Université de Montréal
École des HÉC de Montréal
Montréal : 514 343-6111
Montréal : 514 340-6000
…

Exemple de code correct pour l’ordre de lecture

<table>
<caption >Liste des universités</caption>
<tr>
<td><strong>Université Bishop's</strong><br>
Sherbrooke : 819 822-9600</td>
<td><strong>Université Concordia</strong><br>
Montréal : 514 848-2424</td>
</tr>
<tr>
<td><strong>Université Laval</strong><br>
Québec : 418 656-3333</td>
<td><strong>Université McGill</strong><br>
Montréal : 514 398-4455</td>
</tr>
<tr>
<td><strong>Université de Montréal</strong><br>
Montréal : 514 343-6111
</td>
...

Les règles qui s’appliquent à l’ordre de lecture

1.3.2 Ordre séquentiel logique (niveau A) : lorsque l’ordre de présentation du contenu affecte sa signification, un ordre de lecture correct peut être déterminé par un programme informatique.

Voir aussi :

Le problème

Des indices visuels, comme l’indentation, sont utilisés pour communiquer de l’information, qui doit aussi être donnée en texte pour qu’une personne aveugle puisse les percevoir (ex. l’indentation d’un message dans un forum de discussion).

De même, on ne peut se fier seulement sur le positionnement d’un élément pour en comprendre la nature ou la fonction (ex. un champ de recherche sans étiquette placé en haut à droite de la page).

Parmi les caractéristiques sensorielles qui peuvent être porteuses d’information, on peut aussi considérer la forme, l’orientation ou le son.

Ce type de situation fait appel à la créativité pour trouver les meilleurs moyens de transmettre une information équivalente.

La solution

Il n’y a pas de solution « toute faite » à ce genre de problème, l’essentiel étant d’abord de réaliser qu’il y a un problème, puis de faire preuve de créativité.

Pour un champ de recherche, on peut remplacer une étiquette manquante par un attribut title qui jouera le même rôle.

Dans d’autres situations, l’information textuelle équivalente peut être transmise de façon invisible en utilisant, par exemple, un positionnement CSS hors écran. Pour plus de détails, voir les explications données par WebAim en anglais : Positioning content off-screen.

Il faut cependant éviter d’utiliser les propriétés CSS visibility:hidden ou display:none, qui sont toutes deux reconnues et appliquées par les lecteurs d’écran. La logique étant que si cette information doit être cachée à un utilisateur voyant, elle doit aussi être cachée à un utilisateur aveugle. Le positionnement hors écran demeure donc la meilleure solution.

Certains symboles sont utilisés pour communiquer une information (ex. un crochet, une flèche, un caractère représentant une émoticône ou binette, etc.). Plusieurs de ces symboles ne sont pas reconnus par les lecteurs d’écran, en synthèse vocale ou en braille, et il faut donc utiliser des images (icônes) dont un attribut alt pourra donner la signification.

Enfin, mentionnons que WCAG 2.1 introduit un nouveau critère de succès à propos de l’orientation de l’écran. Le principe est de permettre aussi bien l’affichage en mode portrait qu’en mode paysage afin de permettre à un utilisateur ayant une sévère limitation motrice et dont l’écran est fixé au bras de son fauteuil de pouvoir utiliser le contenu quelle que soit la position choisie pour son écran. Le basculement en mode portrait ou paysage peut aussi apporter des bénéfices pour les personnes malvoyantes.

Les règles qui s’appliquent aux caractéristiques sensorielles

1.3.3 Caractéristiques sensorielles (niveau A) : les instructions données pour la compréhension et l’utilisation du contenu ne doivent pas reposer uniquement sur les caractéristiques sensorielles des éléments comme la forme, la taille, l’emplacement visuel, l’orientation ou le son.

NOTE : Pour les exigences liées à la couleur, se référer à la Règle 1.4.

1.3.4 Orientation (niveau AA) : La consultation et le fonctionnement du contenu ne sont pas limités à une seule orientation de l’affichage, comme le portrait ou le paysage, à moins qu’une orientation spécifique de l’affichage ne soit essentielle.

NOTE : Un chèque de banque, une application de piano, des diapositives pour un projecteur ou une télévision, ou un contenu de réalité virtuelle où l’orientation binaire de l’affichage n’est pas applicable sont autant d’exemples où une orientation spécifique de l’affichage peut être essentielle.

Voir aussi :

Le problème

Pour les personnes ayant des limitations cognitives, les formulaires Web et les interfaces peuvent être difficiles à comprendre et à utiliser. Les WCAG 2.1 introduisent donc deux nouveaux critères de succès.

La fonction conventionnelle des champs de formulaires, des boutons ou autres éléments d’interface et de certains types de liens doit pouvoir être identifiée facilement. Si les champs de formulaire « conventionnels » étaient toujours identifiés de la même façon, cela rendrait les formulaires plus faciles à utiliser pour ces personnes.

Pour une personne ayant une incapacité visuelle qui ne lui donne qu’une perception partielle et généralement séquentielle du contenu de la page, il n’est pas toujours facile de percevoir le rôle des objets ou des composants interactifs, leur position dans un processus ainsi que leur relation avec d’autres objets ou d’autres processus. Pensons par exemple aux étapes d’un processus de commerce électronique, à la relation entre menus et sous-menus ou à celle qui relie des panneaux à onglets.

Certaines interfaces d’applications Web ou mobiles cachent leur complexité sous une apparence intuitive qui semble aller de soi pour l’utilisateur qui la perçoit dans son ensemble, mais qui a besoin d’être explicitée pour les utilisateurs qui l’explorent de façon partielle ou séquentielle.

Bien que le critère de succès sur l’information contextuelle se situe au niveau AAA, il est d’une grande importance pour allier accessibilité et utilisabilité, surtout lors d’une première visite ou d’une première utilisation.

La solution

Pour les personnes ayant des limitations cognitives : Fournir une infrastructure pour prendre en charge les préférences de l’utilisateur. Par exemple, avoir des termes et des symboles familiers est la clé pour pouvoir utiliser le Web. Cependant, ce qui est familier pour un utilisateur peut être nouveau pour un autre, les obligeant à apprendre de nouveaux symboles. Les futurs outils de personnalisation pourraient inclure la possibilité pour un utilisateur de charger un ensemble de symboles qui lui convient, garantissant ainsi que tous les utilisateurs trouvent les commandes simples et familières. Suivez le lien offerts dans le texte du critère de succès pour voir une liste d’exemples illustrant ce que l’on entend par des champs « conventionnel ».

L’utilisation des rôles définis par WAI-ARIA peut suffire pour certains objets ou composants d’interface.

Pour les personnes ayant des limitations cognitives et visuelles : L’information contextuelle peut jouer un rôle très important pour les personnes qui doivent interagir avec des composants d’interface auxquels elles sont peu habituées.

Dans d’autres situations, il faudra ajouter des informations d’orientation en utilisant divers attributs WAI-ARIA comme aria-label ou aria-describedby, par exemple, qui ne peuvent s’appliquer qu’à des éléments pouvant recevoir le focus.

Enfin, la bonne vieille technique de l’ajout de texte hors écran peut aussi être utilisée. L’information textuelle équivalente peut alors être transmise de façon invisible en utilisant un positionnement CSS hors écran. Pour plus de détails, voir les explications données par WebAim en anglais : Positioning content off-screen.

Les règles qui s’appliquent à la perception des interfaces

1.3.5 Identifier la finalité de la saisie (niveau AA) : La finalité de chaque champ de saisie recueillant des informations sur l’utilisateur peut être déterminée par un programme informatique lorsque :

1.3.6 Identifier la fonction (niveau AAA) : Dans un contenu implémenté via un langage de balisage, la fonction des composants d’interface utilisateur, des icônes et des régions peut être déterminée par un programme informatique.

Voir aussi :

Le problème

La couleur est parfois utilisée pour communiquer de l’information qui ne sera pas perceptible pour un bon nombre de personnes ayant une incapacité visuelle ou un problème de perception des couleurs. Les personnes aveugles n’en auront évidemment pas connaissance, mais beaucoup de personnes malvoyantes ont un problème de perception des couleurs. Il y a aussi les daltoniens qui représentent 8,5 % de la population masculine.

Il existe plusieurs formes de daltonisme partiel (dyschromatopsie), la plus fréquente étant la confusion du vert et du rouge. Les autres formes de daltonisme sont nettement plus rares (comme la confusion du bleu et du jaune), la plus rare de toutes étant la déficience totale de la perception des couleurs (achromatopsie), où le sujet ne perçoit que des nuances de gris.

Toute information transmise par la couleur doit donc aussi être transmise sous forme de texte.

La solution

Dans les consignes données, ou dans les mécanismes de navigation, vous ne devez pas vous en remettre seulement aux couleurs, car une personne qui ne perçoit pas les couleurs doit pouvoir se fier à des indices textuels redondants, la couleur étant un indice supplémentaire pour ceux qui la perçoivent. Par exemple, il ne suffit pas de mettre les champs obligatoires d’un formulaire en rouge, car ceux-ci doivent aussi être indiqués, soit par une icône comportant un alt explicite, soit par un texte visible pour tous. Pour plus de détails et des exemples, consultez la technique : G182: Ensuring that additional visual cues are available when text color differences are used to convey information

Si des différences de couleurs ont une signification dans une image, ces informations doivent être données dans le texte de remplacement de l’image.

Il est important que les éléments de navigation soient facilement identifiables par un autre moyen que la couleur. Ceci s’applique non seulement aux menus, mais aussi aux liens que l’on trouve à l’intérieur du texte. Un contraste de 3 pour 1 est aussi exigé entre la couleur du texte environnant et la couleur du lien.

La meilleure pratique pour l’identification des liens est le soulignement, au moins au survol de la souris et au focus.

Les règles qui s’appliquent à l’utilisation de la couleur

1.4.1 Utilisation de la couleur (niveau A) : la couleur n’est pas utilisée 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 visuel.

NOTE : Ce critère de succès traite spécifiquement de la perception des couleurs. Les autres formes de perception sont traitées à la règle 1.3, comme l’accès à la couleur par programme informatique, et les autres formes de codage de la présentation visuelle.

Voir aussi :

Le problème

Le contraste visuel est un élément très important de la lisibilité, aussi bien pour les couleurs de texte et de fond de la page, que pour celles des images contenant du texte.

Les personnes malvoyantes et la population vieillissante (de 40 ans et plus) sont particulièrement sensibles au niveau de contraste. Pour les personnes malvoyantes, cela va un peu de soi, mais pour la population vieillissante, il est intéressant de noter que dans le processus normal de vieillissement de l’œil, même d’un œil en bonne santé, une personne de 65 ans a besoin d’un niveau de luminosité 4 fois supérieur à celui nécessaire à une personne de 20 ans. À 80 ans, ce n’est plus 4 fois, mais 10 fois plus de lumière qui est nécessaire.

Il est également important de noter que des caractères gras ou plus gros peuvent compenser un contraste plus faible.

D’autre part, dans un clip audio préenregistré, les personnes ayant des limitations auditives peuvent avoir de la difficulté à percevoir la parole lorsqu’un fond sonore trop présent n’offre pas de contraste sonore suffisant avec la parole au premier plan.

Notons également que pour les personnes ayant des limitations visuelles ou cognitives, un fond sonore (ou vidéo avec fond sonore) démarrant automatiquement sur une page Web vient en concurrence avec la synthèse vocale, et nuit à la compréhension de celle-ci. Le problème n’est donc pas de rendre ce son perceptible, mais de s’assurer que la synthèse vocale sera perceptible malgré ce fond sonore.

La solution

Contraste visuel

Pour améliorer le contraste visuel, il faut agir sur l’une des deux couleurs, ou sur les deux pour les rendre plus foncées ou plus pâles. Chaque fois que possible, il faut privilégier un contraste plus fort (de niveau AAA).

Deux couleurs de texte sont cependant à éviter :

  1. Le gris, même foncé dont les utilisateurs vieillissants se plaignent souvent;
  2. Le rouge qui diminue nettement la lisibilité pour les personnes daltoniennes. Pour attirer l’attention, il vaut mieux utiliser un encadré rouge plutôt que du texte en rouge ou utiliser du texte blanc sur un fond rouge foncé.

Si une page ne peut offrir un contraste visuel suffisant, un bouton devrait être offert pour basculer vers une feuille de style offrant un contraste suffisant. Il est même souhaitable d’offrir alors 2 feuilles de styles alternatives, l’une en contraste positif et l’autre en contraste négatif.

Si du texte réel est superposé à une image d’arrière-plan, vous devez vous assurer que le contraste est suffisant.

WCAG 2.1 vient ajouter deux critères de succès à propos du contraste des icônes et des graphes ainsi que des éléments d’interface comme les bordures de champs de formulaires, les indicateurs de focus et de sélection.

Heureusement, nous disposons d’outils qui permettent de mesurer le rapport de contraste visuel, et qui nous permettent donc de nous baser sur des données objectives :

  • Logiciel Colour Contrast Analyzer (Windows, Mac) : Pour mesurer le contraste des éléments textuels et non textuels selon les WCAG 2.1.
  • WAVE : Offert comme application Web ou comme extension de navigateur pour Chrome, Edge et Firefox. Effectue une analyse automatique du contraste des éléments textuels.
  • Contrast Finder : Une application Web outil pour vous aider à trouver des couleurs contrastantes.

Pour conclure, voici un article intéressant (en anglais) sur les problèmes de perception des couleurs et la représentation des données : https://venngage.com/blog/color-blind-friendly-palette/.

Contraste sonore

Dans un clip audio pré-enregistré, le fond sonore doit être éliminé. On doit donner la possibilité de le désactiver, ou il doit être minimisé en assurant un contraste d’au moins 20 dB, soit un fond sonore 4 fois plus faible que la parole au premier plan. Pour plus de détails et des exemples, consultez la technique G56: Mixing audio files so that non-speech sounds are at least 20 decibels lower than the speech audio content.

Contrôle du son : Il faut minimiser l’impact d’un fond sonore qui démarre automatiquement, en limitant celui-ci à 3 secondes, ou en permettant à l’utilisateur de l’arrêter facilement (en plaçant un bouton permettant d’arrêter le son au début de la page).

Les règles qui s’appliquent aux contrastes visuels et sonores

1.4.2 Contrôle du son (niveau A) : si du son sur une page Web est audible automatiquement pendant plus de 3 secondes, un mécanisme est disponible pour le mettre en pause, l’arrêter ou pour en contrôler le volume de façon indépendante du niveau de volume du système général.

NOTE : Puisque tout contenu ne satisfaisant pas à ce critère de succès peut interférer avec la capacité de l’utilisateur à exploiter la page entière, tout le contenu présent dans la page Web (qu’il soit utilisé pour satisfaire à d’autres critères de succès ou non) doit satisfaire à ce critère de succès. Voir l’exigence de conformité 5 : Non-interférence.

1.4.3 Contraste (minimum) (niveau AA) : la présentation visuelle du texte et du texte sous forme d’image a un rapport de contraste d’au moins 4,5:1, sauf dans les cas suivants :

  • Texte agrandi : le texte agrandi et le texte agrandi sous forme d’image ont un rapport de contraste d’au moins 3:1;
  • Texte décoratif : aucune exigence de contraste pour le texte ou le texte sous forme d’image qui fait partie d’un composant d’interface utilisateur inactif, qui est purement décoratif, qui est invisible pour tous ou qui est une partie d’une image contenant un autre contenu significatif.
  • Logotypes : aucune exigence de contraste pour le texte faisant partie d’un logo ou d’un nom de marque.

1.4.6 Contraste (amélioré) (niveau AAA) : la présentation visuelle du texte et du texte sous forme d’image a un rapport de contraste d’au moins 7:1, sauf dans les cas suivants :

  • Texte agrandi : le texte agrandi et le texte agrandi sous forme d’image ont un rapport de contraste d’au moins 4,5:1;
  • Texte décoratif : aucune exigence de contraste pour le texte ou le texte sous forme d’image qui fait partie d’un composant d’interface utilisateur inactif, qui est purement décoratif, qui est invisible pour tous ou qui est une partie d’une image contenant un autre contenu significatif.
  • Logotypes : aucune exigence de contraste pour le texte faisant partie d’un logo ou d’un nom de marque.

1.4.7 Arrière-plan sonore de faible volume ou absent (Niveau AAA) : pour un contenu seulement audio pré-enregistré qui (1) contient principalement de la parole au premier plan, (2) n’est pas un CAPTCHA ou un logo sonore et (3) qui n’est pas une vocalisation dont l’intention est principalement d’être musicale comme une chanson ou un rap, au moins l’une des conditions suivantes est vraie :

  • Sans arrière-plan : le contenu audio ne contient pas d’arrière-plan sonore.
  • Désactivation : l’arrière-plan sonore peut être désactivé.
  • 20 dB : l’arrière-plan sonore est au moins 20 décibels plus faible que le contenu parlé au premier plan sauf pour certains effets sonores occasionnels durant seulement une ou deux secondes. NOTE : Par la définition du « décibel », le volume de l’arrière-plan sonore correspondant à cette exigence est approximativement quatre fois plus faible que le contenu parlé au premier plan.

1.4.11 Contraste du contenu non textuel (niveau AA) : La présentation visuelle des éléments suivants a un rapport de contraste d’au moins 3:1 avec la ou les couleurs adjacentes :

  • Composants d’interface utilisateur : informations visuelles nécessaires à l’identification des composants et des états de l’interface utilisateur, à l’exception des composants inactifs ou lorsque l’apparence du composant est déterminée par l’agent utilisateur et non modifiée par l’auteur ;
  • Objets graphiques : parties d’éléments graphiques nécessaires à la compréhension du contenu, sauf si une présentation spécifique de ces éléments est essentielle à l’information transmise.

Voir aussi :

Le problème

Un texte présenté sous forme d’image devient flou lorsqu’il est agrandi 4 fois, 8 fois ou 12 fois à l’aide d’un logiciel de grossissement utilisé par les personnes malvoyantes. C’est pourquoi il faut en limiter l’usage.

Dans tous les navigateurs récents, l’utilisateur dispose d’une fonction zoom intégrée au navigateur lui-même. L’utilisation de cette fonction peut cependant poser des problèmes de chevauchement de texte sur certaines pages Web, lorsqu’on agrandit la page jusqu’à 200 %. C’est pourquoi il faut vérifier cette fonctionnalité et faire les ajustements nécessaires à la feuille de styles. Une autre option consiste à offrir un mécanisme de zoom intégré à la page elle-même et permettant par exemple d’alterner entre la feuille de styles originale d’une taille de 100 % et deux autres feuilles spécifiquement configurées pour un affichage à 150 % et 200 %.

De plus, certaines personnes doivent pouvoir modifier les couleurs pour obtenir une présentation plus facile à lire.

Pour améliorer la lisibilité d’une page pour les personnes ayant des limitations cognitives, il faut aussi considérer d’autres aspects, comme la longueur des lignes de texte (des colonnes plus étroites sont plus faciles à lire), la justification (alignement à droite et à gauche) qui fait varier l’espacement entre les mots et rend la lecture plus difficile, ainsi que l’espacement entre les mots, les lignes et les paragraphes, qui facilite aussi la lecture.

Une proportion significative de personnes malvoyantes a besoin de plus de 200 % d’augmentation de la taille du contenu. La nécessité de faire défiler le texte horizontalement peut augmenter de 40 à 100 fois l’effort requis pour lire. Il faut donc éviter ce défilement horizontal.

Pour les personnes malvoyantes, le contenu contextuel qui apparaît uniquement au focus du clavier ou au survol de la souris comme les menus déroulants ou les infobulles peut présenter de nombreux défis pour les utilisateurs malvoyants utilisant un logiciel de grossissement et ceux qui ont de la difficulté à contrôler la souris.

La solution

À l’exclusion d’un logo ou d’une image de marque, il faut éviter autant que possible d’utiliser du texte sous forme d’image : Les WCAG demandent que du texte soit utilisé chaque fois qu’une présentation visuelle similaire peut être réalisée avec du texte et une feuille de style CSS.

Dans plusieurs cas, du véritable texte pourrait être superposé à une image de fond, ou alors, le texte pourrait simplement être présenté immédiatement avant (au-dessus) ou immédiatement après (au-dessous) l’image où il était inscrit.

Pour la présentation visuelle du texte :

  • Il est préférable d’utiliser des mesures de taille de polices en pourcentages, en « em », ou les tailles prédéfinies comme medium, large, etc.
  • Vous devez vous assurer qu’aucun contenu ne se chevauchera, ne sera masqué ou tronqué, lorsque l’on grossira le texte avec un facteur de zoom de 200 %. Cela doit aussi s’appliquer à la taille des champs textuels d’un formulaire. Il est évidemment souhaitable que le texte grossi à 200 % se redistribue harmonieusement en évitant tout défilement horizontal. Si on se fie seulement sur le zoom du navigateur, il faut que chaque bloc de texte n’excède pas 50 % de la largeur de la page, si l’on veut éviter le défilement horizontal.
  • Vous pouvez offrir des boutons permettant d’agrandir la taille de la police jusqu’à 200 %. Vous devrez alors vérifier qu’aucun contenu ne se chevauchera, ni ne sera masqué ou tronqué. Cela doit aussi s’appliquer à la taille des champs textuels d’un formulaire. Cela est particulièrement utile sur une version mobile.
  • Les WCAG 2.1 (niveau AA) précisent que l’utilisateur doit pouvoir zoomer jusqu’à 400 % par rapport à la version pour ordinateur. Cela implique que le site soit conçu en mode « ­responsive design »,

Pour permettre le changement des couleurs, vous devez gérer celles-ci via la feuille de styles CSS, en prenant soin de toujours définir une couleur d’arrière-plan chaque fois que vous définissez une couleur de texte. Cela peut se faire en tenant compte des couleurs héritées par l’effet de cascade.

Pour gérer la longueur des lignes de texte, il suffit d’offrir un mécanisme qui permet d’obtenir cette présentation. Ce peut être simplement l’une des deux options suivantes :

  • Une feuille de style alternative.
  • Une conception fluide qui permet à l’utilisateur d’ajuster la largeur des colonnes en modifiant la taille de la fenêtre de son navigateur (« ­responsive design »).

Pour l’interlignage et l’alignement à droite ou à gauche, vous pouvez adopter ce style dans tout le site Web, ou proposer une feuille de style alternative.

WCAG 2.1 ajoute que, dans le cas où le navigateur permet de contrôler l’espacement des lignes, des paragraphes, des caractères ou des mots, les changements effectués par l’utilisateur ne doivent pas causer de pertes de contenu ou de fonctionnalité.

WCAG 2.1 demande aussi que le contenu qui s’affiche au survol de la souris ou au focus du clavier demeure affiché pour qu’un utilisateur d’un logiciel de grossissement puisse le parcourir avec sa souris afin d’y déplacer sa zone de visualisation sans que ce contenu disparaisse; que ce contenu ne vienne pas masquer une partie essentielle de l’élément qui l’a déclenché et que l’élément ainsi affiché demeure affiché tant que le focus du clavier n’est pas déplacé ou que l’utilisateur n’intervient pas pour le faire disparaître.

Dans tous les cas, vous devriez vérifier que votre page demeure lisible sans la feuille de style, sans perte de contenu informatif ni dérangement de l’ordre de lecture logique. En effet, un utilisateur peut vouloir désactiver votre feuille de style, ou la remplacer, pour obtenir une présentation qui réponde mieux à ses besoins.

Les règles qui s’appliquent à la présentation visuelle du texte

1.4.4 Redimensionnement du texte (niveau AA) : à l’exception des sous-titres et du texte sous forme d’image, le texte peut être redimensionné jusqu’à 200 pour cent sans l’aide d’une technologie d’assistance et sans perte de contenu ou de fonctionnalité. (Niveau AA)

1.4.5 Texte sous forme d’image : si les technologies utilisées peuvent réaliser la présentation visuelle, du texte est utilisé pour véhiculer l’information plutôt que du texte sous forme d’image sauf dans les cas suivants :

  • Personnalisable : le texte sous forme d’image peut être personnalisé visuellement selon les exigences de l’utilisateur;
  • Essentielle : une présentation spécifique du texte est essentielle à l’information véhiculée.

NOTE : Les logotypes sont considérés comme essentiels (le texte qui fait partie d’un logo ou d’un nom de marque).

1.4.8 Présentation visuelle (niveau AAA) : pour la présentation visuelle des blocs de texte, un mécanisme est disponible permettant de réaliser ce qui suit :

  • Les couleurs de premier plan et d’arrière-plan peuvent être choisies par l’utilisateur.
  • La largeur n’excède pas 80 caractères ou glyphes (40 si CJK).
  • Le texte n’est pas justifié (aligné simultanément à droite et à gauche).
  • L’espacement entre les lignes (interlignage) est d’une valeur d’au moins 1,5 dans les paragraphes et l’espacement entre les paragraphes est au moins 1,5 fois plus grand que la valeur de l’interligne.
  • La taille du texte peut être redimensionnée jusqu’à 200 pour cent sans l’aide d’une technologie d’assistance et sans que l’utilisateur soit obligé de faire défiler le texte horizontalement pour lire une ligne complète dans une fenêtre plein écran.

1.4.9 Texte sous forme d’image (sans exception) (niveau AAA) : le texte sous forme d’image est utilisé seulement pour du texte purement décoratif ou lorsqu’une présentation spécifique du texte est essentielle à l’information véhiculée.

NOTE : Les logotypes (le texte qui fait partie d’un logo ou d’un nom de marque) sont considérés comme essentiels.

1.4.10 Redistribution (niveau AA) : Le contenu peut être présenté sans perte d’information ou de fonctionnalité et sans nécessité de défilement dans les deux dimensions pour :

  • un contenu à défilement vertical avec une largeur équivalente à 320 pixels CSS;
  • un contenu à défilement horizontal avec une hauteur équivalente à 256 pixels CSS.

Sauf pour les parties du contenu dont l’utilisation ou la compréhension nécessite une mise en page en deux dimensions.

NOTE : 320 pixels CSS équivaut à une largeur d’affichage initiale de 1280 pixels CSS avec un zoom de 400 %. Pour les contenus Web conçus pour défiler horizontalement (par exemple, avec du texte vertical), la valeur de 256 pixels CSS équivaut à une hauteur d’affichage initiale de 1024 pixels avec un zoom de 400 %.

NOTE : Les images, les cartes, les diagrammes, les vidéos, les jeux, les présentations, les tableaux de données, et les interfaces où il est nécessaire de garder les barres d’outils visibles pendant la manipulation du contenu, sont des exemples de contenu nécessitant une mise en page en deux dimensions.

1.4.12 Espacement du texte (niveau AA) : Dans un contenu implémenté via un langage de balisage qui prend en charge les propriétés de style de texte suivantes, il n’y a aucune perte de contenu ou de fonctionnalité lorsqu’on applique toutes les valeurs ci-dessous sans modifier aucune autre propriété de style :

  • La hauteur de ligne (interlignage) définie à au moins 1,5 fois la taille de la police;
  • L’espacement entre les paragraphes consécutifs défini à au moins 2 fois la taille de la police;
  • L’espacement des lettres (interlettrage) défini à au moins 0,12 fois la taille de la police;
  • L’espacement entre les mots défini à au moins 0,16 fois la taille de la police.

Exception : les langues et systèmes d’écritures qui n’utilisent pas une ou plusieurs de ces propriétés de style de texte pour le texte écrit peuvent être conformes en utilisant uniquement les propriétés qui existent pour cette combinaison de langue et de système d’écriture.

1.4.13 Contenu au survol ou au focus (Niveau AA) : Lorsque la réception puis le retrait du survol du pointeur ou du focus du clavier déclenche l’affichage puis le masquage d’un contenu additionnel, les éléments suivants sont vrais :

  • Masquer : il existe un mécanisme permettant de masquer le contenu additionnel sans déplacer le pointeur ou le focus du clavier, à moins que le contenu additionnel ne communique une erreur de saisie ou ne masque ni ne remplace un autre contenu;
  • Survoler : si le survol du pointeur peut déclencher le contenu additionnel, alors le pointeur peut être déplacé sur le contenu additionnel sans que celui-ci disparaisse ;
  • Persister : le contenu additionnel reste visible jusqu’à ce que le survol ou le focus soit retiré, que l’utilisateur le masque ou que ses informations ne soient plus valables.
Exception : la présentation visuelle du contenu additionnel est contrôlée par l’agent utilisateur et n’est pas modifiée par l’auteur.

NOTE : Parmi les exemples de contenu additionnel contrôlé par l’agent utilisateur figurent les infobulles du navigateur créées à l’aide de l’attribut HTML title.

NOTE : Les infobulles personnalisées, les sous-menus et autres fenêtres non modales qui s’affichent au survol et à la prise de focus sont des exemples de contenu additionnel couvert par ce critère.

Voir aussi :

À propos

Organisé par le Regroupement des aveugles et amblyopes du Montréal métropolitain (RAAMM), ce projet veut promouvoir l’accès universel à l’information sous toutes ses formes.

Courriel : [email protected]

Téléphone : 514 277-4401, poste 122

RAAMM: Regroupement des aveugles et amblyopes du Montréal métropolitain.

www.raamm.org

Courriel : [email protected]

5225, rue Berri, bureau 101
Montréal (Québec) H2J 2S4