Accessibilité des sites Web - Outil d'information pour les sites Web liées au transport

Table des matières

Introduction

De plus en plus de voyageurs utilisent les sites Web de fournisseurs de services de transport pour organiser leur voyage. Pour que les personnes ayant une déficience aient un accès égal à ces sites Web, les fournisseurs de services de transport doivent veiller à ce que leur site soit accessible, et le présent outil d’information les aidera à atteindre cet objectif.

Les personnes ayant une déficience ont droit au même niveau de services de transport que celui offert aux autres voyageurs; il s’agit du droit à l’égalité d’accès.

L’accès en toute autonomie fait partie intégrante de ce droit. Les personnes ayant une déficience veulent mener leur vie de la façon la plus indépendante possible, et leur utilisation des services de transport ne fait pas exception. Elles devraient pouvoir accéder à ces services en étant le plus autonome possible.

Les transporteurs et les exploitants de terminaux ont l'obligation de respecter le droit à l’égalité d’accès en répondant aux besoins des personnes ayant une déficience sans se voir imposer une contrainte excessive.

Cela signifie que les transporteurs et les exploitants de terminaux doivent :

  1. fournir des accommodements à une personne ayant une déficience pour lui permettre un accès égal aux services de transport.

  2. fournir ces accommodements dans la mesure où ils ne deviennent pas déraisonnables, peu pratiques voire, dans certains cas, impossibles; autrement dit, jusqu’au point où les accommodements entraîneraient une contrainte excessive.

  3. si ces accommodements entraînent une contrainte excessive, les fournisseurs de services doivent envisager la meilleure solution de rechange qui n’entraînera pas de contrainte excessive.

Objectif de cet outil d’information

Cet outil d’information décrit divers manquements fréquents à l'accessibilité que peuvent relever les personnes ayant une déficience lorsqu’elles utilisent les sites Web des fournisseurs de services de transport. 

L'outil explique comment régler ou éviter ces manquements à l'accessibilité, de sorte que les personnes ayant une déficience aient un accès égal aux sites Web de services de transport.

Cet outil d’information présente notamment :

  • un aperçu des normes d’accessibilité des contenus Web (WCAG 2.0) du World Wide Web Consortium (W3C) et des exemples de raisons pour lesquelles l’accessibilité du contenu Web est importante;
  • des conseils expliquant aux gestionnaires comment évaluer un site Web et travailler avec les développeurs;
  • des conseils expliquant aux développeurs comment repérer et régler les manquements fréquents à l’accessibilité relevés dans des sites Web de fournisseurs de services de transport.

Remarque : Les conseils destinés aux développeurs ne comprennent pas toutes les exigences d’accessibilité du Web, ni tous les moyens de se conformer aux WCAG 2.0. Ils sont plutôt présentés sous forme de survol pour mieux faire connaître et comprendre l’accessibilité du Web et fournir des conseils généraux sur la façon de la réaliser.
Les WCAG 2.0 en tant que telles demeurent des exigences normatives pour les fournisseurs de services de transport.

Contexte

En 2011, l’Office des transports du Canada a entrepris de vérifier si les sites Web des fournisseurs de services de transport étaient accessibles aux personnes ayant une déficience, selon l’article 1.2 de son Code de communication intitulé Élimination des entraves à la communication avec les voyageurs ayant une déficience.
L’Office a chargé un expert en matière d’accessibilité du Web d’évaluer les sites Web de transporteurs aériens et ferroviaires, ainsi que d’exploitants d’aérogares et de traversiers choisis. Les sites Web ont été choisis parce qu’ils concentrent les plus grands volumes de déplacements :

  • les transporteurs aériens, collectivement, ont transporté environ 73 pour cent des passagers à destination, en partance et à l’intérieur du Canada;
  • les aérogares ont reçu environ 83 pour cent des passagers en déplacement au Canada;
  • le seul transporteur ferroviaire choisi pour l’évaluation a transporté 91 pour cent de tous les voyageurs interurbains au Canada;
  • les exploitants de traversiers choisis pour l’évaluation sont les deux exploitants en importance sur lesquels l’Office a compétence.

Les sites Web ont été évalués afin de déterminer s’ils étaient conformes au niveau AA des WCAG 2.0. L’Office a signalé les résultats aux fournisseurs de services de transport, assortis de conseils pratiques pour corriger les manquements, et les a incités à les corriger d'ici le 1er janvier 2013.

En 2013, l’Office a mené des suivis pour confirmer que les manquements avaient été corrigés. Il a signalé les résultats de ces suivis aux fournisseurs de services de transport, assortis de conseils sur la façon de corriger les manquements à la conformité qui restaient.

L’Office continue de travailler avec les fournisseurs de services de transport à améliorer leur conformité avec le niveau AA des WCAG 2.0.

L’importance de l’accessibilité du Web

Le Web permet aux personnes ayant une déficience un accès sans précédent à l’information. Grâce aux technologies Web, il est maintenant beaucoup plus facile de surmonter les obstacles pour quiconque veut consulter des formats imprimés, audios et vidéos. Par exemple, au temps où la principale façon d’obtenir certains renseignements était d’aller dans une bibliothèque, de nombreuses personnes ayant une déficience faisaient face à des obstacles considérables, comme se rendre à la bibliothèque, se procurer physiquement la ressource, puis la lire.

Lorsque ces mêmes renseignements sont aussi disponibles sur le Web en formats accessibles, il est beaucoup plus facile pour bien des gens d’y avoir accès. Désormais, grâce à des sites Web accessibles, les personnes ayant une déficience profitent d’un accès plus efficace et efficient à l’information qui, auparavant, leur était parfois presque inaccessible.

En prime, si votre site Web est accessible, tout le monde y trouve son compte. Les sites Web accessibles sont plus faciles à utiliser et fonctionnent bien sur les appareils mobiles.

Exemples de problèmes touchant des personnes ayant une déficience

  • Kim est aveugle de naissance. Elle utilise un lecteur d’écran appelé VoiceOver sur un MacBook®. Elle a un niveau de connaissance intermédiaire du lecteur d’écran, et elle s’attend à pouvoir acheter un billet d’avion en ligne, à vérifier l’état de son vol, à profiter des spéciaux, etc. Elle utilise le braille et a un convertisseur en braille sans fil grâce auquel elle peut saisir des données dans l’ordinateur et lire sans utiliser le son, si nécessaire.

  • Jean est daltonien. La personne moyenne qui interagit avec lui ne remarquera même pas sa déficience. Il s’attend à utiliser Internet comme tout le monde, mais il a de la difficulté à repérer les éléments de couleur, comme les hyperliens bleus qui ne sont pas soulignés dans une phrase. Jean a beaucoup de difficulté parfois avec les champs des formulaires où sont indiqués des messages comme « les erreurs sont indiquées en rouge ».

  • Mélanie est sourde. Elle travaille dans une banque et elle lit maintenant très bien sur les lèvres. Toutefois, il lui est presque impossible de comprendre les vidéos sur la sécurité en voyage sur Internet s’ils ne sont pas sous-titrés.

  • Stéphane est fonctionnaire et a la paralysie cérébrale. Il se déplace avec un fauteuil roulant motorisé équipé de systèmes qui convertissent ses mouvements de tête par des mouvements de la souris pour qu’il puisse naviguer sur les sites Web. Il utilise un contacteur au souffle pour cliquer avec la souris, et un clavier à l’écran qui parcourt par cycles les groupes de lettres qu’il peut choisir avec sa souris. Il a de la difficulté à cliquer sur de petites cibles, mais peut souvent choisir des cibles plus grandes.

  • Miriam est une ingénieure de 70 ans à la retraite; elle a la maladie de Parkinson. Le tremblement de ses mains lui rend la tâche difficile si elle doit se servir d’un clavier et d’une souris, mais elle a tout de même réussi à se servir d’un stylet, c’est-à-dire une longue baguette fixée à la tête pour taper sur un clavier. Les interfaces et les menus avec onglets qu’on ne peut activer qu’avec la souris représentent des obstacles importants pour elle.

  • Pierre est dans la mi-quarantaine et est conseiller financier dans une banque. Quand il était dans la vingtaine, il s’est brisé des vertèbres dans le cou en faisant de la gymnastique et est devenu quadriplégique. Il utilise un fauteuil roulant électrique et se sert de son ordinateur au moyen d’un stylet (semblable à un crayon) fixé au bout de son index (dont la mobilité est minimale) qui lui sert de souris, et du logiciel de reconnaissance vocale Dragon NaturallySpeaking® pour taper du texte. Les boutons en forme d’images qui ne sont pas balisés (c.-à-d. programmés) en tant que boutons sont difficiles d’accès.

  • Suzanne est malvoyante. Elle a une vision de 10 pour cent dans un œil, et aucune dans l’autre. Elle utilise le logiciel ZoomText® pour agrandir l’écran et augmenter le contraste des couleurs. S’il y a du texte dans les images, il devient flou et difficile à lire quand il est agrandi.

  • Jérémy a des difficultés d’apprentissage. Si les instructions sont claires et simples, il peut les suivre. Si l’interface d’un site Web est compliquée et que la conception n’est pas intuitive, il a de la difficulté à naviguer sur le site.

  • Joyce a 83 ans. Elle fait de l’arthrite rhumatoïde dans les mains, est malentendante et sa vue s’affaiblit. Elle ne sait pas utiliser la technologie d’assistance, mais elle sait comment agrandir le texte de son fureteur. Elle a de la difficulté à lire le texte s’il ne contraste pas suffisamment avec le fond, par exemple du texte de couleur pastel sur un fond blanc. La combinaison de ses déficiences et sa difficulté à apprendre à se servir des technologies d’assistance rendent sa navigation sur le Web particulièrement ardue.

Taux d’incapacité au Canada

De nombreuses incapacités peuvent affecter la façon dont les gens accèdent à Internet.

Depuis qu’Internet est un outil clé pour avoir accès au réseau de transport fédéral, tout manquement à l’accessibilité du Web peut se traduire par un obstacle pour les personnes ayant une déficience.

Voici les différents taux selon l’Enquête canadienne sur l’incapacité, 2012 de Statistique Canada :

Incapacité Les deux sexes %
Vision 756 320 2,7
Ouïe 874 590 3,2
Mobilité 1 971 750 7,2
Flexibilité 2 077 980 7,6
Dextérité 953 090 3,5
Douleur 2 664 240 9,7
Apprentissage 622 260 2,3
Mémoire 628 180 2,3
Développement 160 530 0,6
Mental/psychologique 1 059 600 3,9
Inconnu 79 540 0,3

Ressources pour les gestionnaires

Normes d’accessibilité des contenus Web : WCAG 2.0

Les WCAG 2.0 sont des normes d’accessibilité adoptées par le W3C, le consortium international responsable de la supervision des normes Web.

Les WCAG 2.0 sont les seules normes sur le contenu Web dans le monde, et les seules qui ont été approuvées par l’Organisation internationale de normalisation (ISO).

Les WCAG 2.0 expliquent comment améliorer l'accessibilité du contenu Web pour les personnes ayant un large éventail de déficiences (p. ex., déficiences visuelles, auditives, physiques, cognitives, langagières et neurologiques, ou troubles d’élocution et d’apprentissage). Les normes contiennent également de l’information sur la façon d'améliorer la convivialité du contenu Web pour les personnes âgées dont les capacités changent en raison du vieillissement. L’adoption des WCAG 2.0 améliorera la convivialité du Web pour la plupart des utilisateurs, peu importent leurs capacités et les appareils qu’ils utilisent.

Les WCAG 2.0 comportent des critères de succès vérifiables et pouvant être évalués selon trois niveaux : A (le minimum), AA et AAA. L’Office s’attend à ce que les fournisseurs de services de transport se conforment au niveau AA. Cette attente est indiquée à la section 1.2 du Code de communication Élimination des entraves à la communication avec les voyageurs ayant une déficience.

Le niveau AA renferme 38 énoncés vérifiables auxquels il faut répondre « vrai » pour qu’un site soit confirmé comme étant conforme à ce niveau d’accessibilité. Ces énoncés vérifiables (critères de succès) sont organisés selon des principes et des lignes directrices. Le niveau AA comprend tous les critères de succès des niveaux A et AA. Une liste complète des principes et des critères de succès des niveaux A et AA se trouve à l’annexe A.

Acceptées sans aucune objection officielle d’intervenants, les WCAG 2.0 ont été adoptées dans de nombreux pays, dont le Canada, les États-Unis, l’Australie, le Japon, l’Union européenne et le Royaume-Uni. Au Canada, les tribunaux ont reconnu les normes des WCAG 2.0 et imposé leur adoption au gouvernement fédéral.

Les normes ont été établies par consensus, ce qui signifie que chaque critère de succès a été soigneusement examiné, négocié et voté par des intervenants, comme des représentants de l’industrie provenant de grandes sociétés, des gouvernements de partout dans le monde, des universités, des organisations représentant des personnes ayant une déficience, ainsi que des professionnels de l’accessibilité du Web. Le processus de conception était ouvert au public.

Il existe un grand nombre de documents de référence sur les WCAG, notamment des tutoriels approuvés selon les WCAG, qui donnent des instructions conviviales sur des éléments comme des formulaires, des tableaux, des images complexes, des structures de page, des diaporamas et bien plus, avec des exemples de code simple; d’autres documents du genre sont à venir.

Évaluer votre site Web

La meilleure façon de tester l’accessibilité de votre site Web est d'y faire participer les utilisateurs, puisque les vérificateurs automatiques ne testent qu’environ 20 pour cent des exigences des WCAG 2.0. Par exemple, un vérificateur automatique peut vérifier si une image comporte une description (un attribut alt), mais ne peut pas déterminer si la description a du sens.

Le W3C a créé une méthodologie d’évaluation pour aider les organisations à tester leur site Web. Il est primordial de faire participer les utilisateurs ayant une déficience. Ils peuvent vérifier les manquements à l'accessibilité au-delà de ce que suggèrent les WCAG 2.0. Les vérifications de conformité devraient être menées par des personnes qui connaissent bien les WCAG 2.0.

L’initiative sur l’accessibilité du Web (WAI) du W3C se veut également une référence rapide personnalisable sur la façon de répondre aux exigences des WCAG 2.0. Elle fournit des renseignements sur les critères de succès et les techniques connexes, et sert de liste de contrôle pour tester la conformité.

Conseils pour collaborer avec des développeurs Web

Si vous ne gérez pas votre site Web ou n’avez pas d’expérience du développement Web, vous devriez embaucher un développeur Web qui a suffisamment d’expérience de la conception de sites Web accessibles.

Voici certaines questions que vous pouvez poser pour déterminer le niveau de connaissance de votre éventuel développeur Web :

  • Connaissez-vous les niveaux A et AA des WCAG 2.0?
  • Avez-vous créé/amélioré un site Web accessible (WCAG 2.0, niveau A ou supérieur)? Avez-vous des liens ou des références pour ces sites?
  • Faites-vous des tests auprès d’utilisateurs pour évaluer l’accessibilité du site Web?
  • Testez-vous l’accessibilité du site Web au moyen d’évaluations automatisées ou manuelles ou de technologies d’assistance?
  • Avez-vous de l’expérience de l’utilisation de la spécification WAI-ARIA?
  • Avez-vous accès à un expert en matière d’accessibilité du Web qui pourrait vous aider à rendre votre site conforme aux WCAG 2.0?
  • Comment comptez-vous intégrer l’accessibilité du Web à chaque phase du cycle de vie du projet?

Vous devriez vous assurer que l’énoncé de travail renferme une exigence de conformité avec les WCAG 2.0, niveau AA. Vous devriez aussi demander un plan de projet pour veiller à ce que le site Web soit conçu conformément à l’énoncé de travail. Votre équipe des services numériques pourrait retenir les services d’un professionnel en matière d’accessibilité pour veiller à ce que votre équipe Web ait accès à une expertise et que les attentes de conformité avec les WCAG 2.0 soient satisfaites.

Ressources pour les développeurs

Cette section explique comment réparer ou éviter les manquements fréquents à l'accessibilité des sites Web des fournisseurs de services de transport.

Processus de réservation

La réservation et l’achat de billet sont, de loin, les éléments les plus compliqués des sites Web de services de transport. 

Pour satisfaire aux exigences de conformité avec les WCAG 2.0, tous les éléments d’un processus doivent être accessibles :

« Quand une page Web fait partie d’un ensemble représentant un processus (comme une succession d’étapes devant être complétées afin d’accomplir une activité), toutes les pages Web du processus sont conformes au moins au niveau spécifié. (La conformité à un certain niveau est impossible s’il existe une page de ce processus qui n’atteint pas au moins ce niveau).

Exemple : une boutique en ligne présente une série de pages permettant de sélectionner et d’acheter des produits. Toutes les pages de la séquence depuis le début jusqu’à la fin (le paiement) sont conformes afin que toute page faisant partie du processus soit conforme. »

Cela signifie que chaque page et élément du processus de réservation doit être conforme. Si l’une des pages ne l’est pas, tout le processus est voué à l’échec, car chaque étape fait partie intégrante du processus de réservation.

Critères de succès liés aux processus de réservation :

Choisir les détails de base d’un voyage au moyen d’un formulaire

Au moment de choisir un voyage, l’utilisateur remplit habituellement un formulaire en ligne dans lequel il doit préciser son point d’origine, sa destination, la date du voyage, le nombre d’enfants, le pays de résidence, etc. Voici des facteurs particulièrement importants à prendre en compte pour que ces formulaires soient accessibles :

  • chaque champ d’un formulaire devrait avoir une étiquette utilisant la construction <label for=”...”> ou une autre solution au moyen de la spécification WAI-ARIA (extensions au format HTML qui rendent les éléments non natifs et les applications complexes accessibles pour les lecteurs d’écran);
  • l’ordre des onglets devrait suivre l’ordre logique des champs du processus (p. ex., le nom devrait être avant l’adresse);
  • le focus devrait toujours être facile à repérer à mesure que l’utilisateur passe d’un champ à l’autre. Les contrôles ne devraient pas avoir de valeur dans les feuilles de style en cascade (CSS) , par exemple : :focus {outline : none}; Note 1;
  • le bouton de recherche devrait être bien étiqueté, préférablement au moyen d’un élément <button> HTML si le site est créé en HTML5;
  • si le bouton soumettre est autre chose qu’un élément <button>, comme une image liée, il doit être balisé de manière à ce qu’il amène au même résultat pour les personnes qui utilisent un lecteur d’écran et celles qui se servent uniquement d’un clavier (c.-à-d. que la touche Retour ou la barre d’espacement peuvent encore être utilisées pour activer le bouton soumettre). Il devrait avoir l'équivalent textuel approprié, et le segment role=”button". Il faudrait donc utiliser des attributs de la spécification WAI-ARIA.

Des tutoriels approuvés sur les WCAG expliquent aussi comment créer des formulaires accessibles :

Voici certains avantages de la conformité, et des conséquences d’une non-conformité :

  • lorsque les champs d’un formulaire sont balisés avec les bonnes étiquettes, un utilisateur aveugle peut entrer dans le champ du formulaire et entendre le nom du champ, par exemple « prénom ». Sinon, il entendra seulement « modifier », ce qui ne lui dit pas ce qu’il doit inscrire dans le champ;
  • si la balise appropriée <label for=”…”> est donnée à un champ, un utilisateur dont les mains tremblent aura une cible beaucoup plus grande dans laquelle cliquer avec la souris, car il pourra cliquer soit sur le champ, soit sur l’étiquette. Les deux façons permettent de placer le focus dans le champ du formulaire;
  • si l’ordre des onglets suit un ordre visuel, l’utilisateur qui peut voir, mais ne peut pas utiliser une souris en raison de microtraumatismes répétés saura où les trouver sur la page Web. Ainsi, l’utilisateur ne va pas se « perdre » facilement pendant sa navigation sur la page;
  • si les boutons sont bien balisés, ou si les bonnes étiquettes <button>; HTML5 sont utilisés, un utilisateur aveugle entendra qu’il s’agit d’un bouton et quelle fonction il a (p. ex. soumettre, continuer, ok, etc.). Si le bouton n’est pas bien balisé, l’utilisateur pourrait entendre quelque chose comme « lien, image 274654.jpg » et ne connaîtra pas sa fonction;
  • de plus, si un bouton n’est pas bien étiqueté, un utilisateur quadriplégique qui se sert d’un logiciel de reconnaissance vocale pourrait ne pas avoir accès à l’information s’il dit : « cliquer sur le bouton soumettre ».

Choisir les voyages de départ et de retour

Pour des réservations de voyage en ligne, l’utilisateur est souvent dirigé vers une page où il peut choisir l’heure du vol à la date de son choix. Habituellement, il y a des onglets sur ces pages pour choisir d’autres dates de voyage possibles. Le nom de l’onglet indique souvent le prix le plus bas pour chaque date. Les interfaces de ce type peuvent devenir compliquées, prêter à confusion et être peu conviviales pour certaines personnes ayant une déficience. Lors de la conception de ces interfaces, il est important de s’assurer que :

  • la personne qui utilise un lecteur d’écran peut discerner quel onglet est celui de la journée qu’elle choisit pour le départ. Il ne suffit pas de simplement le présenter d’une couleur différente;
  • chaque action activée avec la souris peut aussi l’être avec un clavier. Cela inclut les fenêtres contextuelles qui s’ouvrent pour montrer toutes les taxes et tous les frais compris dans le prix, et les fenêtres qui apparaissent lorsque la souris passe sur du contenu en particulier visant à informer l’utilisateur des différentes catégories de prix;
  • les onglets peuvent être choisis au moyen d’un clavier, et toutes les autres exigences visant les onglets sont prises en compte (voir la section ci-après sur les interfaces à onglets);
  • lorsque l’utilisateur appuie sur la touche de tabulation, il se déplace dans le formulaire d’une manière logique, et non n’importe où et n’importe comment (remarque : il est préférable de placer le code dans le bon ordre plutôt que de gérer le focus de l’onglet avec des valeurs tabindex positives, car ces valeurs prêtent habituellement plus à confusion en raison des erreurs qui se glissent lors de leur création et parce qu’elles sont difficiles à maintenir);
  • les titres des tableaux sont correctement identifiés avec la balise d’en-têtes <th>;
  • les boutons radios ont les bonnes étiquettes avec le segment <label for=...>;
  • les boutons continuer sont bien étiquetés pour qu’un utilisateur aveugle sache qu’il s’agit d’un bouton continuer;
  • la personne qui utilise un lecteur d’écran peut entendre ce qui se produit si elle place le focus sur l’interface à onglets. Elle doit toujours savoir le nom, le rôle et la valeur de chaque élément;
  • les sections sur le départ et le retour devraient être clairement indiquées au moyen des en-têtes <h1>-<h6>;
  • des indicateurs de progression sont présentés de manière accessible pour les personnes qui utilisent un lecteur d’écran. Les images CSS ne fonctionneront pas à moins que la spécification WAI-ARIA soit utilisée pour fournir l’information. C’est une bonne idée d’indiquer l’étape dans l’élément du titre de la page, par exemple <title> achat de billet, étape 3 de 6 </title>.

Voici certains avantages de la conformité, et des conséquences d’une non-conformité :

  • les personnes daltoniennes ou ayant une déficience visuelle auront de la difficulté si seulement de la couleur est utilisée pour indiquer que quelque chose a été choisi;
  • les personnes aveugles, celles ayant certaines déficiences cognitives ou dont les mouvements avec les mains sont limités pourraient ne pas être capables d’utiliser une souris. C’est pourquoi chaque tâche doit pouvoir être faite en utilisant seulement un clavier, c’est-à-dire sans la souris;
  • si les onglets suivent un ordre visuel, alors l’utilisateur qui peut voir, mais ne peut pas utiliser une souris, saura où il est rendu sur la page. Ainsi, l’utilisateur ne va pas se « perdre » facilement pendant sa navigation sur la page Web;
  • lorsque les en-têtes sont bien balisés avec <h1>-<h6>, une personne qui utilise un lecteur d’écran peut facilement se déplacer à la section de son choix, et n’aura pas à écouter la description entière de la page;
  • si les boutons sont bien balisés, ou si les bonnes étiquettes <button> HTML5 sont utilisées, un utilisateur aveugle entendra qu’il s’agit d’un bouton et quelle fonction il a (p. ex. soumettre, continuer, ok, etc.). Si le bouton n’est pas bien balisé, l’utilisateur entendra seulement quelque chose comme « lien, image 274654.jpg » et ne connaîtra pas sa fonction;
  • lorsque les champs d’un formulaire sont bien balisés avec les bonnes étiquettes, un utilisateur aveugle peut entrer dans le champ et entendre le nom du champ, par exemple « prénom ». Sinon, il entendra seulement « modifier », ce qui ne lui dit pas ce qu’il doit inscrire dans le champ.

Passer en revue le résumé de l’itinéraire et du billet

Avant de finaliser sa réservation, l’utilisateur est habituellement dirigé vers une page lui permettant de passer en revue les détails de son voyage. Pour que la page soit accessible, il est important de tenir compte des éléments suivants :

  • si le résumé de l’itinéraire et du billet est présenté sous forme de tableaux, ceux-ci doivent être correctement balisés. Il s’agit d’un manquement commun aux WCAG 2.0 d’utiliser des balises de tableau irrégulières, sans considération d’accessibilité lorsque ce type d’information est présenté à l'utilisateur;
  • veiller à ce que les boutons soient correctement étiquetés;
  • les détails du voyage et les politiques devraient avoir les en-têtes et structures de liste appropriés;
  • les liens vers les suppléments et autres devraient être présentés de façon à permettre à l’utilisateur de retourner facilement à la page renfermant les détails.

Choisir un surclassement et d’autres options

Le processus de réservation propose souvent des pages Web pour les surclassements et autres options avant que le client confirme l’achat de son billet.

Ces pages devraient aller droit au but; elles ne devraient pas amener l’utilisateur vers d’autres options qui risqueraient de l’entraîner dans un labyrinthe ou de lui faire choisir une option sans l’avoir voulu. 

Cela signifie que toutes les options devraient être clairement indiquées avec des titres et des boutons de sélection munis d’une étiquette qui distingue les boutons de sélection les uns des autres sur la page. Il est possible de le faire au moyen de l’attribut aria-describedby.

Confirmer l’identité du voyageur

Au cours du processus de réservation, on demande habituellement aux voyageurs de confirmer leur identité soit en ouvrant une session au moyen d’un profil d’utilisateur, soit en remplissant un formulaire. Pour que la page soit accessible aux personnes ayant une déficience, il est important de tenir compte des éléments suivants :

  • tous les champs d’un formulaire et les formulaires devraient être bien balisés, y compris le texte d’aide;
  • en général, il ne faudrait pas utiliser de tableaux pour la présentation. Mais s’il le faut, les tableaux doivent avoir la balise role=”presentation” de manière à ne pas embrouiller la personne qui utilise un lecteur d’écran;
  • chaque section de la page Web devrait avoir les en-têtes et structures de liste appropriés;
  • les messages d’erreur devraient être faciles à lire en format texte et être associés aux champs correspondants du formulaire;
  • les champs obligatoires devraient être clairement indiqués À L’INTÉRIEUR de l’étiquette. De plus, grâce à l’attribut HTML5 required ou aria-required, la personne qui utilise un lecteur d’écran saura quels champs sont obligatoires.

Inscrire les renseignements pour la facturation

Pour la section de la facturation, il faut s’assurer que :

  • toutes les icônes de carte de crédit sont étiquetées avec le bon équivalent textuel;
  • le type de paiement et toutes les caractéristiques de sécurité sont correctement étiquetés, avec des instructions;
  • les groupes de boutons radio sont regroupés avec des éléments « fieldset » et « legend ».

Mieux vaudrait éviter d’utiliser l’outil CAPTCHA dans le processus de réservation. Pour de plus amples renseignements, voir le document intitulé CAPTCHA Alternatives and thoughts qui présente des solutions de rechange et des pistes de réflexion.

Corriger les erreurs

Un manquement fréquent à l’accessibilité, dans bien des formulaires, survient quand l’utilisateur fait des erreurs dans la saisie de données ou la navigation. L’utilisateur doit être capable de revoir et de corriger l’information, mais aussi de détecter une erreur avant de faire une action, par exemple une réservation. Cette consigne est particulièrement importante si l’utilisateur prend des engagements juridiques ou financiers.

Il est essentiel de porter une attention toute particulière à l’endroit où les messages d’erreur seront placés. Mal placés, ces messages risquent de passer inaperçus, et il pourrait ensuite être difficile de corriger les erreurs et de remplir des formulaires en ligne. Il est donc important que, lorsqu’une erreur est provoquée, le focus de l’utilisateur soit amené au message d’erreur pour que l’action appropriée puisse être prise.

Éléments pour connaître le statut d’une demande

De nombreux voyageurs visitent des sites Web de services de transport pour avoir de l’information sur le départ et l’arrivée d’un voyage prévu. Les voyageurs devraient pouvoir avoir facilement accès à cette information.

Voici les critères de succès des éléments pour connaître le statut d’une demande :

Recherche d’arrivées et de départs

Le nom, le rôle et la valeur de chaque élément interactif devraient être annoncés à une personne qui utilise un lecteur d’écran chaque fois que quelque chose change, à mesure qu’elle appuie sur la touche de tabulation pour aller d’un élément à l’autre. Cela signifie que si un contrôle comme un menu déroulant personnalisé est affiché au complet, il doit être clair qu’il est affiché au complet pour les personnes qui utilisent une technologie d’assistance. Si des éléments HTML standards sont utilisés, alors le nom, le rôle et la valeur sont automatiquement indiqués aux lecteurs d’écran. Mais si les étiquettes <div> ou <span> servent d’éléments interactifs, des mesures d’accessibilité supplémentaires doivent être prises, habituellement au moyen de la spécification WAI-ARIA.

À titre d’exemple d’exigences pour un nom, un rôle et une valeur, envisagez d'utiliser un champ avec l’étiquette numéro de vol à côté. Le nom serait numéro de vol, le rôle serait une boîte modifier le texte, et la valeur serait ce que l’utilisateur inscrirait dans la boîte. Si l’un ou l’autre de ces éléments ne peut pas être lu par la technologie d’assistance, l’utilisateur ne pourra pas remplir le formulaire.

Arrivées et départs dans des tableaux

Si l’information est fournie sous forme de tableau, veillez à ce qu’il renferme des éléments HTML natifs. Il devrait y avoir des en-têtes de tableau <th> pour chaque titre de colonne.

Compagnie aérienne Numéro de vol Arrivant de Heure d’arrivée Numéro de porte Statut
Compagnie aérienne XYZ 0045 Halifax 18 h 06 5 En retard
ABC Air 0076 Ottawa 19 h 23 3 À l’heure
123 Air 0031 Toronto 10 h 07 7 À l’heure

Certains transporteurs peuvent décider de ne pas inclure de titres aux colonnes. S’ils procèdent de cette façon à des fins visuelles, alors la ligne des titres peut être cachée : elle reste invisible pour les utilisateurs voyants, mais reste disponible pour ceux qui utilisent un lecteur d’écran. 

Le tutoriel de conception de tableaux fournit plus d’information sur le codage de tableaux accessibles.

Si le tableau n’est pas correctement codé, il sera difficile pour les personnes aveugles qui utilisent un logiciel de lecture d’écran de comprendre l’information. Un tableau correctement balisé permettra à la personne qui utilise un lecteur d’écran d’entendre ce que renferment les en-têtes du tableau à mesure qu’elle se déplace dans les cellules, de sorte qu’elle saura quelle information est présentée dans chaque cellule (p. ex., le numéro de vol).

Arrivées et départs dans des interfaces à onglets

Les arrivées et les départs peuvent aussi être présentés sous forme de listes. Si c’est le cas, veillez à utiliser des éléments de liste natifs <ul>, <li>.

Si les balises <div< ou <span>; sont utilisées et faites pour ressembler à une liste, alors il faudra utiliser la spécification WAI-ARIA. Comme cela peut devenir compliqué, il est préférable d’utiliser des éléments de liste HTML natifs.

Il est important d’utiliser des éléments HTML natifs (ou la spécification WAI-ARIA), car sans eux les personnes qui utilisent des lecteurs d’écran ne pourront pas naviguer facilement et obtenir l’information qu’elles cherchent.

Lorsque les listes sont bien conçues, l'utilisateur est capable de naviguer, puis d’utiliser et de comprendre l’information présentée sur la page Web.

Arrivées et départs sous forme de listes

Parfois, des fournisseurs de services de transport indiquent les arrivées et les départs dans une interface à onglets cliquables. 

Exemple : une interface à onglets cliquables qui indique les arrivées et les départs

Les interfaces à onglets posent un grand problème d’accessibilité et doivent être conçues et instaurées avec soin.

Vous devriez vous assurer que :

  • chaque tâche est exécutable sans la souris (p. ex., au moyen d’un clavier) pour accommoder les personnes aveugles, celles qui ont certaines déficiences cognitives ou dont les mouvements des mains sont limités. Chaque élément « cliquable » avec une souris doit « recevoir le focus » quand il est choisi au moyen d’un clavier. Pour vérifier si cela fonctionnera correctement, tentez de naviguer sur la page Web à l'aide d'un clavier;
  • les onglets de l’interface peuvent être choisis et activés par un clavier (habituellement en utilisant la touche retour ou la barre d’espacement);
  • il est possible d’entrer à l'aide d'un clavier dans le contenu exposé lorsqu’un onglet est sélectionné.

En général, l’utilisateur peut naviguer sur une interface à onglets de deux façons :

  • simplement en appuyant sur la touche de tabulation pour passer d’un onglet à l’autre;
  • lorsque le focus est sur le premier onglet, les touches fléchées permettent d’aller à l’onglet suivant.

Ces deux façons peuvent être créées d’une manière qui respecte les WCAG 2.0, à condition que les principaux problèmes susmentionnés soient corrigés.

Si une personne s’y connaît bien avec les lecteurs d’écran, elle pourra naviguer facilement dans une interface à onglets qui a été bien conçue. Elle sera capable de choisir entre les arrivées et les départs et de trouver sans difficulté toute l’information à leur propos.

Diaporamas

Souvent, les diaporamas ne sont pas conformes aux WCAG 2.0.

Vous devez vous assurer que le diaporama :

  • puisse être activé avec un clavier;
  • dispose de boutons correctement étiquetés qui peuvent recevoir le focus;
  • avoir un bouton pause accessible;
  • avoir un équivalent textuel pour toutes les images du diaporama.

Le tutoriel sur la conception de diaporama donne des instructions sur la création de diaporamas accessibles.

Critères de succès liés à la création ou au choix d’une interface de diaporama :

Mise en page

Les pages doivent comprendre les éléments suivants :

  • des sections de page balisées avec les éléments de section HTML5, comme header, nav, main, aside, et footer. Pour les anciens sites, les pages statiques devraient avoir des rôles de la spécification WAI-ARIA;
  • les bons en-têtes balisés avec des étiquettes H <h1> - <h6>;
  • les listes créées au moyen de balises de liste (<ul> <li>, etc.).

Mises en page adaptées

Pour s’assurer que leurs sites Web fonctionnent sur différents appareils, les développeurs utilisent de plus en plus des mises en page « adaptées », c’est-à-dire qui changent en fonction de la taille de l’écran de l’appareil. Souvent, il y a plusieurs « points d'arrêt » configurés pour permettre de changer la vue et de passer d’un ordinateur à une tablette à un appareil mobile.

La mise en page adaptée est un outil formidable pour construire des sites qui fonctionneront sur tous les appareils. Quand vous construisez un site adapté, vous devriez porter une attention particulière aux éléments qui pourraient ne pas s’afficher correctement sur un appareil mobile ou rendre votre site non accessible.

Par exemple, les grands tableaux et les interfaces à onglets s’affichent souvent mal sur les appareils mobiles, et il faudra peut-être présenter le contenu différemment. 

De façon générale, si vous concevez d’abord votre site pour les appareils mobiles et tenez compte des problèmes rattachés aux appareils mobiles, cela pourrait vous aider à créer une mise en page qui fonctionne sur toutes les interfaces et pour tous les utilisateurs.

Le W3C explique comment les WCAG 2.0 s’appliquent aux appareils mobiles, et s’appliqueraient à un site adapté destiné tant à ceux qui utilisent un ordinateur de bureau qu’à ceux qui utilisent un appareil mobile.

Critères de succès liés à la mise en page :

Choix de contraste de couleur

Pour les personnes dont la vue est relativement faible, il est important que le texte sur les pages Web contraste suffisamment avec le fond.

Vous devriez savoir que :

  • le niveau AA des WCAG 2.0 exige que le texte ait un rapport de contraste d’au moins 4.5:1. Le rapport de contraste doit être d’au moins 3:1 pour du texte de 18 points, ou de 14 points s’il est en caractère gras;
  • les choix de contraste de couleur ne s’appliquent qu’au texte conforme aux WCAG 2.0 et non aux éléments de l’interface utilisateur qui n’ont pas de caractères d’écriture;
  • il existe des outils pour mesurer le contraste de couleur entre le texte et le fond;
  • en général, les couleurs pâles ne contrastent pas suffisamment avec un fond blanc.

Voici les critères de succès liés au contraste de couleur :

Images

Si l’information est présentée en contenu non textuel, il est important que ce contenu ait un équivalent textuel.

Ce que vous devriez savoir :

  • si l’image contient de l’information, elle doit être accompagnée d’un équivalent textuel qui transmet l’objectif de l’image;
  • si l’image est purement décorative, ne véhicule aucune information ou n’a aucune fonction (p. ex., un gradient, une ligne de conception swish, une image d’espacement, etc.), la balise devra être alt=”” pour qu’un lecteur d’écran l’ignore;
  • les cartes d’orientation et les cartes de terminaux devraient être accompagnées de longues descriptions pour s’assurer qu’elles ont un équivalent textuel;
  • si l’image est une carte de directions, les directions devraient être en format texte et indiquer l’emplacement physique de la destination. Ce texte pourrait être fourni dans un fichier distinct muni d’un lien, sous l’image ou à l’intérieur d’un mécanisme afficher/masquer accessible;
  • le texte dans les images devrait fournir le texte équivalent dans l’attribut alt. Toutefois, on aurait intérêt à utiliser du vrai texte plutôt que des images de texte. Les CSS peuvent souvent être utilisées pour styliser le texte afin de répondre aux besoins de la conception graphique.

Les personnes aveugles ou malvoyantes pourront comprendre les images accompagnées de l'équivalent textuel approprié. De plus, les personnes ayant des déficiences cognitives bénéficient parfois d'une explication sur l’intention de l’image.

Si les images n’ont pas d'équivalent textuel, les personnes aveugles ou malvoyantes pourraient être embêtées et se demander ce qui leur a échappé. Un lecteur d’écran pourrait lire le fichier d’une image qui n’a pas d'équivalent textuel comme suit : « 154345.jpg ».

Parfois, des images de texte sont utilisées. Ces images peuvent se séparer en pixel (devenir floues) lorsqu’elles sont agrandies par un logiciel pour les personnes ayant une déficience visuelle.

Voici les critères de succès liés à l'équivalent textuel :

Contenu audio et vidéo

Les contenus audio et vidéo devraient comporter des équivalents textuels.

Vous devriez vous assurer que :

  • les vidéos sont sous-titrées et captent tout le dialogue et tous les sons pertinents. Les personnes sourdes pourront ainsi avoir accès au contenu;
  • tous les multimédias ont un équivalent textuel (habituellement une transcription descriptive) qui inclut les dialogues et les détails importants communiqués par des images et des sons;
  • le lecteur multimédia est entièrement actionnable au moyen d’un clavier, et tous les boutons sont bien étiquetés.

Voici les critères de succès liés à la conception multimédia :

Voici les critères de succès liés au choix ou à la conception d’un lecteur média :

Appareil mobile adapté

De nombreux sites Web commerciaux offrent maintenant de l’aide pour les appareils mobiles, grâce à une mise en page adaptée ou à un site mobile distinct. Selon le W3C, la grande majorité des modèles d’interface utilisateur des systèmes des ordinateurs de bureau ou portatifs s’applique aussi aux appareils mobiles. Par conséquent, il n’est pas surprenant qu’un grand nombre de techniques relatives aux WCAG 2.0 actuelles puissent s’appliquer aux contenus et aux applications mobiles.

Dans sa rubrique expliquant comment les WCAG 2.0 s’appliquent aux appareils mobiles, le W3C met en évidence certains problèmes d’accessibilité directement liés aux appareils mobiles, notamment des problèmes causés par la petite taille de l’écran, le contraste, les éléments tactiles, etc.

Notons qu’il faut s’assurer que les menus fonctionnent pour l’affichage mobile. Le menu mobile devrait permettre le déplacement sur la page avec un clavier, et les liens devraient être correctement étiquetés et recevoir le focus.

En somme, l’expérience utilisateur pourrait être meilleure pour tout le monde si la conception était d’abord faite pour les appareils mobiles.

Le W3C explique comment les WCAG 2.0 s’appliquent aux appareils mobiles.

Documents PDF

Les documents PDF disponibles à une adresse HTTP sont considérés comme étant du contenu Web aux termes des WCAG 2.0. Le W3C fournit des techniques PDF pour les WCAG 2.0 afin de les rendre plus accessibles.

À propos de l’Office

L’Office est un tribunal administratif indépendant et un organisme de réglementation du gouvernement du Canada.

L’Office est responsable de s’assurer que les obstacles abusifs aux possibilités de déplacement des personnes ayant une déficience sont éliminés des services et des installations de transports aérien, ainsi que des services et des installations de transport ferroviaire, par autocar et par traversier de compétence fédérale.

L’Office élimine les obstacles abusifs de trois manières:

  1. en élaborant des règlements, des codes de pratiques et des normes de réglementation et en surveillant la conformité en ce qui concerne le niveau d’accessibilité des modes de transport de compétence fédérale;
  2. en éliminant les problèmes avant qu’ils ne surgissent en répondant aux demandes de renseignements avant les déplacements et en éduquant les personnes ayant une déficience et les fournisseurs de services sur leurs droits et responsabilités; et
  3. en réglant au cas par cas chaque plainte grâce à une démarche qui concorde avec celle qui sert à déterminer les cas de discrimination et à y remédier en vertu de la législation sur les droits de la personne.

La compétence de l’Office s'applique :

  • aux transporteurs aériens qui exploitent des services à l’intérieur, à destination ou en provenance du Canada;
  • aux aéroports situés au Canada;
  • aux transporteurs ferroviaires voyageurs, aux exploitants de traversiers et aux exploitants d’autobus et d'autocars qui assurent des services entre des provinces ou entre le Canada et les États-Unis, de même qu'à leurs gares situés au Canada;
  • aux services qui font partie intégrante des services de transport fournis par un transporteur ou une gare situé au Canada.

Annexe A : Principes, lignes directrices et critères de succès des WCAG

Principe 1 : Perceptible

Ces lignes directrices et ces critères de succès aident à s’assurer que l’utilisateur est capable de recueillir des renseignements dans la page Web ou l’application, même s’il a une ou plusieurs déficiences sensorielles.

1.1 Les équivalents textuels : Proposer des équivalents textuels à tout contenu non textuel

1.2 Média temporel : Proposer des versions de remplacement aux médias temporels.

1.3 Adaptable : Créer un contenu qui puisse être présenté de différentes manières sans perte d’information ni de structure (par exemple avec une mise en page simplifiée)

1.4 Distinguable : Faciliter la perception visuelle et auditive du contenu par l’utilisateur, notamment en séparant le premier plan de l’arrière-plan

Principe 2 : Utilisable

Ces lignes directrices et ces critères de succès aident à s’assurer que l’utilisateur est capable de faire usage des éléments interactifs et des contrôles présents sur la page sans risquer de faire une erreur ou de rendre ces éléments impossibles à utiliser, même s’il a une déficience qui change sa manière d'interagir avec une page Web.

2.1 Accessibilité au clavier : Rendre toutes les fonctionnalités accessibles au clavier

Temps suffisant : Donner aux utilisateurs suffisamment de temps pour consulter et utiliser le contenu

2.3 Crises : Ne pas concevoir de contenu susceptible de provoquer des crises

2.4 Navigable : Fournir à l’utilisateur des éléments d’orientation pour naviguer, trouver le contenu et se situer dans le site

Principe 3 : Compréhensible

Ces lignes directrices et ces critères de succès aident à s’assurer que l’utilisateur peut comprendre clairement l’utilisation de la page.

3.1 Lisible : Rendre le contenu textuel lisible et compréhensible

3.2 Prévisible : Faire en sorte que les pages apparaissent et fonctionnent de manière prévisible

3.3 Assistance à la saisie : Aider l’utilisateur à éviter et à corriger les erreurs de saisie

Principe 4 : Robuste

Ces lignes directrices et ces critères de succès aident à s’assurer que le codage peut être interprété correctement par le logiciel (technologie d’assistance) employé par l’utilisateur, même si les widgets du site sont constitués d’éléments non standards.

4.1 Compatible : Optimiser la compatibilité avec les agents utilisateurs actuels et futurs, y compris les technologies d’assistance

Remarque : La conformité avec le niveau AA requiert la satisfaction de tous les critères de succès des niveaux A et AA.

Information sur la publication

Date de modification :