Boîte à outils de l’accessibilité numérique d’eCampusOntario

Boîte à outils de l’accessibilité numérique d’eCampusOntario

Cara Wilkie; John McNabb; Natalie Rose; Oskar Westin; Pierre Duez; et Pia Dimayuga

eCampusOntario

Symbole de Licence Creative Commons Attribution 4.0 International

Boîte à outils de l’accessibilité numérique d’eCampusOntario Droit d'auteur © par Cara Wilkie; John McNabb; Natalie Rose; Oskar Westin; Pierre Duez; et Pia Dimayuga est sous licence Licence Creative Commons Attribution 4.0 International, sauf indication contraire.

Ce projet est rendu possible grâce au financement du gouvernement de l’Ontario et au soutien apporté par eCampusOntario à la Stratégie d’apprentissage virtuel. Pour en savoir plus sur la Stratégie d’apprentissage virtuel, consultez https://vls.ecampusontario.ca/fr.

Table des matières

1

Bienvenue dans la boîte à outils

Au sujet d’eCampusOntario

eCampusOntario, un organisme sans but lucratif financé par la province de l’Ontario, est à la tête d’un consortium de collèges, universités et établissements autochtones publics. Nous mettons au point des plateformes, des outils et menons des recherches afin d’encourager l’utilisation des technologies éducatives et des environnements d’apprentissage en ligne à l’appui de l’apprentissage continu.

Technologie éducative accessible

L’utilisation de la technologie a permis d’élargir l’accès à l’éducation et de donner aux éducatrices et éducateurs accès à de nouvelles méthodes et de nouveaux outils d’enseignement. Toutefois, l’utilisation croissante de la technologie peut poser des obstacles pour les personnes en situation de handicap. Il est essentiel de s’assurer que les technologies utilisées à des fins éducatives sont accessibles à toutes les personnes qui les utilisent, y compris les personnes atteintes d’un handicap.

Repérer et éliminer de façon proactive les obstacles et offrir des pratiques d’enseignement et d’apprentissage équitables permet de s’assurer que les personnes ayant diverses capacités et divers handicaps peuvent profiter des technologies sans faire l’objet de jugement. Il convient de suivre ces pratiques. Les éducatrices et éducateurs et les établissements postsecondaires ont également des obligations juridiques à l’égard de l’accessibilité en vertu du Code des droits de la personne de l’Ontario et de la Loi sur l’accessibilité pour les personnes handicapées de l’Ontario.

La mise au point de cette boîte à outils pour les technologies éducatives accessibles par eCampusOntario se veut une première étape en vue d’aider le secteur à mettre en valeur l’accessibilité des technologies éducatives.

Un aperçu général de cette boîte à outils se trouve dans l’outil Application des connaissances

La boîte à outils traite des thèmes suivants :

I

Définitions

Les étudiant.es et les éducatrices et éducateurs de l’Ontario interagissent avec la technologie de différentes façons. Étant donné que la technologie peut engendrer des obstacles pour certaines personnes atteintes d’un handicap, il est important de s’assurer qu’elle est accessible à tous les utilisateurs et utilisatrices, y compris ceux et celles en situation de handicap. Par conséquent, il convient de s’assurer de repérer et d’éliminer de façon proactive les obstacles pour aider ces personnes et de rendre accessibles et équitables les pratiques d’enseignement et d’apprentissage dans l’intérêt des personnes ayant diverses capacités et divers handicaps. 

La présente section traite des thèmes suivants :

1

Introduction aux handicaps

Souvent, les gens pensent que les handicaps font référence à une personne et à ses difficultés particulières. Cependant, le modèle social du handicap nous aide à comprendre que les obstacles auxquels font face les gens avec un handicap viennent plutôt de la société et des environnements inaccessibles qu’elle crée. L’obstacle n’est pas le fait qu’une personne utilise un fauteuil roulant, mais plutôt l’absence d’une rampe d’accès pour accéder à un édifice. L’obstacle n’est pas le fait qu’une personne n’entende pas les renseignements communiqués verbalement, mais plutôt que ces renseignements ne sont communiqués que verbalement. Grâce au modèle social du handicap, nous comprenons que la responsabilité d’éliminer les obstacles pour les personnes vivant avec un handicap revient à la société, et que chaque personne ne devrait pas avoir à s’adapter individuellement aux environnements inaccessibles.

Qui rencontre des obstacles en matière de technologie?

Beaucoup de gens, avec ou sans handicap, rencontrent des obstacles en matière d’utilisation de la technologie. Ces obstacles sont parfois d’ordre financier, comme lorsqu’un étudiant ne peut pas acheter un logiciel en particulier. Ils peuvent aussi reposer sur un manque de connaissances, comme un étudiant plus âgé qui n’aurait pas eu accès à un ordinateur dans sa jeunesse.

Pour les personnes vivant avec un handicap, les obstacles viennent souvent de la technologie elle-même, car elle est rarement conçue pour répondre aux besoins d’un vaste éventail d’utilisateurs. La plupart des concepteurs créent des produits en fonction d’un utilisateur « type » ou « moyen ». Cette approche de la conception ne tient pas compte de la diversité des personnes qui pourraient utiliser la technologie différemment. Par exemple, une technologie pourrait ne pas tenir compte des personnes qui utilisent un logiciel de lecture à l’écran pour accéder à l’information sur le Web. De plus, les obstacles rencontrés en matière d’accès à la technologie varient en fonction du handicap.

Handicap physique ou problème de dextérité : Les gens qui vivent avec un handicap physique qui limite la dextérité et la motricité fine peuvent vivre des obstacles dans l’utilisation d’une souris, d’un clavier ou d’un écran tactile de la manière conventionnelle. Par exemple, des boutons trop petits sur les pages Web peuvent présenter un obstacle pour les personnes ayant un handicap limitant leur dextérité.

Handicap touchant la vision : Les personnes avec une déficience visuelle peuvent avoir du mal à voir l’équipement qu’elles utilisent (comme un clavier) et éprouver de la difficulté à voir l’information affichée à l’écran. Beaucoup de personnes avec un handicap visuel ont un certain niveau de vision, alors elles peuvent rencontrer des obstacles lorsque le texte est petit, que les graphiques sont collés ou que les contrastes sont faibles. Par exemple, les pages Web dont les en-têtes, les titres de colonnes et de lignes ou les liens ne sont pas correctement codés auront pour effet de créer des obstacles pour les personnes qui utilisent un logiciel de lecture à l’écran.

Handicap touchant l’audition : Les personnes ayant une déficience auditive font face à des obstacles chaque fois que l’information est présentée sous forme sonore.  Par exemple, les vidéos, les enregistrements audio et les effets sonores qui n’ont pas été créés ou conçus de manière accessible peuvent présenter des obstacles pour les personnes ayant une déficience auditive.

Handicap touchant la compréhension : Les personnes vivant avec un handicap touchant la compréhension peuvent vivre des obstacles dans la compréhension des renseignements ou dans la navigation sur les sites Web ou les applications. Ces obstacles peuvent être la façon dont l’information est présentée visuellement, le type de langage utilisé ou un manque de convivialité d’une application ou d’un site Web. Par exemple, les sites Web dont la navigation est difficile à comprendre peuvent créer des obstacles pour les personnes ayant un trouble cognitif ou d’apprentissage.

D’autres handicaps peuvent avoir une incidence sur la fonction exécutive ou les interactions sociales. Chaque situation est unique. Les personnes ayant le même type de handicap ne vivront pas toujours les obstacles de la même façon, et certaines personnes peuvent avoir plus d’un handicap. Il est donc important de tenir compte d’un vaste éventail d’utilisateurs et d’éliminer un maximum d’obstacles afin de rendre la technologie accessible.

2

Handicap et technologie

Lorsque qu’on parle de handicap, vous pensez peut-être que l’on fait référence à une personne et à ses difficultés particulières. Cependant, le modèle social du handicap nous aide à comprendre que les obstacles auxquels font face les gens avec un handicap viennent plutôt de la société et des environnements inaccessibles qu’elle crée. Nous avons la responsabilité de retirer les obstacles pour les personnes vivant avec un handicap. Notre objectif est de repérer et d’éliminer ou de réduire les obstacles pour ces personnes, et ce, de manière proactive.

Accessibilité et technologie

On peut considérer qu’une chose est accessible lorsqu’elle offre un accès équitable aux personnes vivant avec un handicap et qu’elle leur permet de réaliser leurs tâches et de faire des choix sans jugement, tout en maintenant leur autonomie. L’accessibilité numérique, parfois appelée a11y (où « 11 » fait référence au nombre de lettres omises dans le mot « accessibility »), offre un accès équitable aux personnes qui utilisent la technologie d’assistance ou des mesures d’adaptation personnelles pour réaliser certaines tâches numériques. Parmi les mesures d’adaptation possibles, on retrouve notamment la modification du contenu numérique, par exemple le réglage de la luminosité ou de la taille de la police. La technologie d’assistance comprend du matériel et des logiciels spécialisés qui peuvent aider les personnes avec un handicap à percevoir le contenu numérique et à interagir avec celui-ci. Des exemples sont présentés ci-dessous.

API d’accessibilité et technologie d’assistance

Les appareils numériques comme les ordinateurs portables, les ordinateurs de bureau, les tablettes électroniques et d’autres appareils mobiles sont dotés d’une interface de programmation d’applications (API) d’accessibilité intégrée. Les API servent de traducteur ou de guide entre les divers composants logiciels. Les applications logicielles utilisent les règles établies dans l’API d’accessibilité pour communiquer avec les technologies d’assistance et assurer que celles-ci peuvent interpréter l’information du logiciel d’une manière compréhensible pour l’utilisateur.

L’interaction peut se diviser comme suit :

  1. Les navigateurs convertissent les applications Web en une arborescence de l’accessibilité, qui communique avec l’API d’accessibilité.
  2. La technologie d’assistance reçoit les données et les traduit dans une autre interface utilisateur.
  3. Les actions de l’utilisateur de la technologie d’assistance sont ensuite reconverties au moyen de l’API d’accessibilité afin de réaliser les tâches souhaitées.

Exemples de technologies et de fonctionnalités accessibles

Logiciels de lecture à l’écran : Les logiciels de lecture à l’écran, ou lecteurs d’écran, permettent aux personnes qui éprouvent des difficultés à voir ou à lire d’accéder à l’information. Ces outils repèrent le texte sur un site Web, dans une application ou un document et le lit à haute voix au moyen d’un synthétiseur vocal. Les lecteurs d’écran sont alimentés par l’intelligence artificielle (IA), alors ils ne comprennent pas intuitivement l’ordre dans lequel le texte doit être lu. Ainsi, ils se fient aux éléments comme les en-têtes et d’autres indices intégrés aux documents, aux sites Web et aux applications en guise de contexte.

Commutateurs : Un commutateur est un dispositif mécanique qui permet aux personnes vivant avec un handicap physique d’accéder aux fonctionnalités d’un clavier ou d’une souris d’une façon différente. Il existe plusieurs types de commutateurs, comme des boutons tactiles, des pédales, des leviers ou même des tubes activés par la respiration. Les contrôles de commutateurs réalisent une seule action, comme un clic de souris. Lorsqu’un utilisateur a accès à un seul commutateur, le logiciel bascule entre chaque option d’un site Web, d’une application ou d’un clavier virtuel, ce qui lui permet d’activer les fonctionnalités désirées.

Technologie de transcription automatique de la parole : La technologie de transcription automatique de la parole permet aux utilisateurs de dicter du texte plutôt que d’utiliser un clavier. L’ordinateur ou l’appareil reconnaît les paroles et transcrit les mots en commandes ou en texte (p. ex., on pourrait dire « double-clic sur… » pour activer cette commande). Les applications de transcription automatique de la parole peuvent être utiles à un grand nombre de personnes ayant un handicap, y compris des handicaps physiques, visuels ou cognitifs. Cette technologie pratique est aussi de plus en plus populaire auprès des personnes qui n’ont aucun handicap, car elle permet de gagner du temps. Beaucoup d’appareils, d’ordinateurs et d’applications sont dotés d’une telle technologie.

3

Intégration de l’accessibilité numérique

Toute technologie numérique avec laquelle les gens interagissent génère un besoin d’accessibilité numérique, y compris les sites Web, les applications mobiles, les logiciels, les fichiers audio et vidéo, les documents et les outils d’édition. S’ils ne sont pas accessibles, le contenu et le mécanisme de présentation de ces actifs peuvent créer des obstacles pour les personnes ayant un handicap.

Créer un produit accessible vise à offrir une expérience utilisateur équivalente pour tous. Le principe sous-jacent de la conception inclusive est qu’en offrant du contenu accessible aux personnes qui rencontrent des obstacles, on crée aussi une meilleure expérience pour tout le monde. Autrement dit, des solutions accessibles sont essentielles pour certains, mais peuvent être bénéfiques pour beaucoup. Pour améliorer l’accessibilité, il faut d’abord repérer les obstacles qui empêchent les personnes ayant un handicap d’accéder au contenu et aux services. Améliorer l’accessibilité numérique réduit les obstacles et fournit un accès équitable au contenu numérique pour les personnes vivant avec un handicap et les utilisateurs de la technologie d’assistance.

Planification de l’accessibilité numérique

Il est essentiel de penser à l’accessibilité avant même de créer du nouveau contenu ou d’acquérir une nouvelle technologie. Une bonne accessibilité ne survient pas par accident. Prendre des décisions intentionnelles et inclusives aux étapes de planification sera bénéfique pour les utilisateurs finaux, en plus de réduire les efforts, les coûts à long terme et les risques de litiges.

Acquisition de technologies numériques accessibles

Les logiciels de tiers, les solutions numériques et le développement peuvent créer des obstacles lorsqu’ils ne sont pas accessibles. Inclure des exigences claires et uniformes en matière d’accessibilité dans le processus d’approvisionnement réduira votre niveau de risque et éliminera les obstacles pour vos utilisateurs finaux. Consultez la section sur l’approvisionnement pour plus d’information.

Développement de logiciels et de sites Web

L’accessibilité est essentielle tout au long du processus de développement, tant au niveau de chaque composant que de la conception globale du système. Planifier l’accessibilité assurera l’uniformité au niveau du système, sur chaque page et entre les pages. Utiliser les repères appropriés et une navigation uniforme dès le début facilitera la conception et le développement d’une application accessible.

L’accessibilité numérique ne s’arrête pas à l’étape de la planification, contrairement à d’autres critères de conception. Faites des tests avant le lancement afin de confirmer que vous avez bien atteint vos cibles. Consultez la section Mise à l’essai pour en savoir plus.

 

Ressources :

Les liens suivants vous fourniront de plus amples renseignements ainsi que des ressources sur l’accessibilité numérique :

Consultez aussi notre liste complète de ressources.

4

Utilisation de personas

Une façon plus générale d’améliorer l’accessibilité et l’expérience des utilisateurs finaux consiste à élaborer des personas. Les personas sont des utilisateurs types fictifs créés pour représenter de vraies personnes qui pourraient utiliser votre service, votre produit ou votre site. Créer plusieurs personas diversifiés permet de reconnaître plus facilement les divers besoins et les attentes des éventuels utilisateurs.

Dans le contexte particulier d’amélioration de l’accessibilité, vous pouvez choisir de créer deux types de personas : des personas qui représentent des personnes vivant avec des handicaps et des personas sans handicaps qui pourraient avoir besoin (ou simplement bénéficier) d’expériences plus accessibles. Prendre en compte les handicaps est une excellente façon de créer des produits inclusifs et accessibles.

 

Exemples de personas représentant des personnes vivant avec un handicap

Voici quelques exemples de personas que vous pourriez utiliser :

  • Une étudiante aveugle qui souhaite accéder au matériel d’une formation en ligne. Elle utilise un clavier et un logiciel de lecture à l’écran pour consulter le contenu et réaliser ses tâches.
  • Un étudiant avec une déficience visuelle qui consulte un diaporama. Il utilise le zoom et a besoin de contrastes élevés pour percevoir le contenu.
  • Un étudiant avec un trouble d’apprentissage qui a besoin d’aides visuelles, de texte simplifié et de la synthèse vocale de texte pour comprendre le contenu en ligne.
  • Une étudiante avec des troubles de motricité qui doit répondre à un mini-test en ligne. Elle doit utiliser son clavier ou un logiciel de transcription automatique de la parole pour répondre aux questions.

 

Personas et expériences accessibles

Vous pouvez aussi ajouter des expériences accessibles à des personas existants. Par exemple, en modifiant un persona pour inclure une situation de handicap temporaire, comme un bras cassé, vous aiderez vos concepteurs à réfléchir à des façons de naviguer dans un logiciel sans souris. Faire en sorte que votre persona doive faire un devoir à l’extérieur crée un besoin de contraste accru. Si votre persona habite dans un foyer bruyant, des sous-titres pourraient rendre le contenu de cours préenregistré plus facile à suivre.

Considérations d’accessibilité

La liste ci-dessous présente des exemples de solutions qui pourront vous aider à penser à des façons d’éliminer les obstacles auxquels vos personas pourraient être confrontés. Le Gouvernement du Canada propose également des personas détaillés qui pourront vous être utiles.

Handicap sensoriel (visuel)

  • Contraste élevé
  • Choix des couleurs
  • Taille de police lisible
  • Logiciels et matériel dotés de paramètres d’affichage réglables (p. ex. grossissement)
  • Documents électroniques dotés de fonctionnalités d’accessibilité
  • Application qui prend en charge les fonctionnalités d’accessibilité de tous les navigateurs et systèmes d’exploitation
  • Options avec mouvements réduits
  • Médias temporels (audio/vidéo) accessibles en format texte
  • Possibilité de contrôler les médias temporels (p. ex. pause, vitesse de lecture)

Handicap sensoriel (auditif)

  • Indices visuels accompagnant les signaux audio
  • Matériel et logiciels dotés de paramètres audio réglables
  • Matériel compatible avec les appareils auditifs
  • Médias audio et vidéo dotés de sous-titres et accompagnés d’une transcription

Handicap physique

  • Options de contrôle différentes pour les interactions complexes qui requièrent deux mains
  • Compatibilité avec les claviers et les commutateurs
  • Solution de remplacement pour les actions complexes comme glisser-déposer (« click and drag »)
  • Zone cible élargie pour les éléments fonctionnels (c.-à-d. qui ne requiert pas de contrôle moteur fin ou d’actions précises)

Trouble cognitif ou d’apprentissage ou obstacles linguistiques

  • Langage simple
  • Police lisible
  • Absence d’animations superflues ou répétitives ou de texte clignotant
  • Absence d’effets sonores persistants
  • Utilisation de motifs de conception reconnaissables et d’icônes aux étiquettes de texte visibles

Ressources :

Le ministère britannique de l’Intérieur a une série d’affiches d’information qui résument les principes de conception accessible. Ce contenu est également accessible au format HTML :

  • Créer du contenu pour les utilisateurs malvoyants : (image) (html)
  • Créer du contenu pour les utilisateurs qui utilisent un lecteur d’écran : (image) (html)
  • Créer du contenu pour les utilisateurs sourds ou malentendants : (image) (html)
  • Créer du contenu pour les utilisateurs souffrant d’un handicap physique ou moteur : (image) (html)
  • Créer du contenu pour les utilisateurs atteints de dyslexie : (image) (html)
  • Créer du contenu pour les utilisateurs avec un trouble du spectre de l’autisme : (image) (html)

II

Normes

Les collèges et les universités sont déterminés à favoriser l’accessibilité de leurs apprenant.es et de leur personnel. Ils doivent également satisfaire à des exigences juridiques en matière d’accessibilité en ce qui a trait aux sites Web, au matériel d’apprentissage et aux procédures d’achat conformément à la Loi sur l’accessibilité pour les personnes handicapées de l’Ontario et au Code des droits de la personne de l’Ontario. Les normes d’accessibilité numérique contribuent à orienter l’élaboration de sites Web et de technologies accessibles et sont toutes fondées sur des principes directeurs similaires. La norme Web Content Accessibility Guidelines (WCAG), une norme internationale d’accessibilité des sites Web, est la plus répandue. En outre, les États-Unis et l’Union européenne ont élaboré des normes d’accessibilité qui sont utiles et fiables pour les Canadiens et Canadiennes. Les exigences de l’Ontario pourraient changer à la suite des recommandations de deux comités d’élaboration de normes et afin de suivre l’évolution des autres normes internationales.

 

La présente section traite des thèmes suivants :

5

Exigences juridiques pour l’Ontario

La Convention relative aux droits des personnes handicapées des Nations Unies reconnaît l’accessibilité des technologies de l’information et des communications en tant que droits de la personne. Il existe principalement deux lois en Ontario qui régissent l’accessibilité : le Code des droits de la personne de l’Ontario et la Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario.

Ce code et cette loi opèrent en tandem. La Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario établit des exigences spécifiques en matière d’accessibilité. Le Code des droits de la personne de l’Ontario exige également que les organisations répondent aux demandes des personnes sans discrimination. Gardez en tête ces deux textes, car s’il existe un conflit entre les deux, c’est celui qui établit le plus haut degré d’accessibilité qui prévaut (Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario, article 38).

Normes d’accessibilité intégrées et Loi de 2005 pour l’accessibilité des personnes handicapées de l’Ontario

En Ontario, les normes d’accessibilité intégrées de la Loi de 2005 pour l’accessibilité des personnes handicapées de l’Ontario établissent les exigences juridiques pour les organisations dans le « secteur parapublic » et les « établissements d’enseignement ou de formation ».

Les exigences suivantes font référence à la technologie dans les collèges et les universités :

  • Les établissements doivent réfléchir à l’accessibilité lorsqu’ils achètent des biens ou des services. L’article 5 de la Loi de 2005 pour l’accessibilité des personnes handicapées de l’Ontario stipule que les organisations doivent « [prendre] en compte la conception axée sur l’accessibilité et les critères et options d’accessibilité lors de l’obtention ou de l’acquisition de biens, de services ou d’installations, sauf si cela n’est pas matériellement possible. »
  • Les sites Web auxquels le public peut accéder doivent satisfaire au niveau AA des règles pour l’accessibilité des contenus Web (WCAG 2.0). Cela est interprété comme incluant les applications et les comptes de médias sociaux.
  • Lorsque quelqu’un en fait la demande, les organisations doivent fournir des ressources ou du matériel d’enseignement ou de formation dans un format accessible qui répond aux besoins de la personne ayant un handicap. Cela doit être fait en obtenant un format électronique prêt à être converti ou en fournissant des ressources comparables dans un format accessible. L’expression « prêt à être converti » signifie qu’un format électronique peut être facilement converti en un format accessible (p. ex. fichiers HTML et Word structurés).
  • Les organisations qui produisent des manuels d’enseignement ou de formation doivent rendre disponibles des versions accessibles ou prêtes à être converties.
  • Les bibliothèques d’établissements d’enseignement doivent fournir des formats prêts à être convertis sur demande.
  • Les organisations doivent déposer un rapport sur la façon dont elles appliquent les exigences de la Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario au plus tard le 31 décembre 2021.

Au sens de la loi, l’expression « prêt à être converti » désigne un format électronique ou numérique qui facilite la conversion dans un format accessible. Par exemple, un document prêt à être converti peut être au format Microsoft Word ou HTML.

Certaines exceptions s’appliquent à ces obligations générales, par exemple :

  • lorsqu’il n’est pas possible d’incorporer les critères d’accessibilité dans le processus d’approvisionnement;
  • lorsqu’il s’agit d’information dont l’établissement n’est pas directement ou indirectement responsable;
  • dans le cas de collections spéciales et de livres rares.

Code des droits de la personne de l’Ontario

Le Code des droits de la personne de l’Ontario et les codes des droits de la personne des autres provinces établissent des obligations complémentaires. Les collèges et les universités doivent faire une adaptation raisonnable pour répondre aux besoins des personnes ayant un handicap, sauf si cela aurait pour effet de produire un « préjudice injustifié » pour le collège ou l’université. On fait souvent appel au Code des droits de la personne de l’Ontario lorsqu’une personne fait une demande d’adaptation (p. ex. une étudiante demande une ressource d’apprentissage dans un format accessible). Le collège ou l’université doit considérer la demande et accorder l’adaptation si celle-ci est raisonnable.

Au sens juridique, le Code des droits de la personne de l’Ontario est également interprété comme exigeant des organisations qu’elles réfléchissent à l’avance aux besoins en matière d’accessibilité. Par exemple, dans l’arrêt Lepofsky c. Toronto Transit Commission, le tribunal des droits de la personne de l’Ontario a déterminé que la Toronto Transit Commission avait enfreint le Code des droits de la personne de l’Ontario en omettant de mettre en œuvre l’annonce sonore des arrêts.

Interpréter le Code des droits de la personne de l’Ontario présente un défi, car il ne stipule pas le niveau exact d’accessibilité requis. L’analyse des limites exactes des obligations du Code des droits de la personne nécessiterait des conseils juridiques indépendants. Cependant, les obligations du Code des droits de la personne vont plus loin que celles énoncées dans la Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario.

Obligations juridiques futures

À la fin de 2019, le Comité d’élaboration des normes d’information et de communications a publié des recommandations intérimaires comprenant des recommandations pour deux phases de révision des normes d’accessibilité intégrées. Le Comité d’élaboration des normes d’éducation postsecondaires a publié des recommandations initiales en juin 2021 en vue d’obtenir la rétroaction du public. Aucune de ces recommandations n’a encore été acceptée ou intégrée dans la réglementation.

Voici certaines des modifications recommandées concernant la technologie dans les collèges et les universités :

  • Élargir la définition de « site Web » pour inclure « les applications mobiles qui fonctionnent à partir d’un site Web ou même celles qui fonctionnent comme un appareil autonome, mais qui nécessitent une connexion Internet pour fonctionner »;
  • Fournir plus de détails sur les façons de prendre en compte la conception axée sur l’accessibilité et les critères et options d’accessibilité dans l’approvisionnement. Cependant, cette recommandation ne précise pas ce à quoi ressemble la conception axée sur l’accessibilité;
  • Exiger que tout le matériel, les évaluations et le matériel multimédia créés ou acquis par le personnel enseignant soient disponibles en plusieurs formats accessibles;
  • La technologie utilisée pour l’apprentissage numérique doit être accessible, ou une option fonctionnellement utilisable doit être fournie;
  • Mettre au point un plan d’évaluation de la technologie pour intégrer l’accessibilité dans l’apprentissage numérique, puis consulter les parties prenantes à propos du plan;
  • Définir à l’avance et communiquer aux étudiants les options d’accessibilité aux technologies numériques et les composants d’apprentissage requis pour chaque cours;
  • Se doter d’un plan d’accessibilité aux technologies numériques;
  • Nommer un membre du personnel des échelons supérieurs à titre de responsable de la technologie d’accessibilité numérique.

Ressources :

6

Normes internationales

Il existe quelques normes internationales qui traitent de l’accessibilité des technologies. Les principales normes sont les règles pour l’accessibilité des contenus Web (WCAG), Section 508 et la norme ETSI 301 549, et celles-ci fonctionnent bien les unes avec les autres.

Les règles pour l’accessibilité des contenus Web (WCAG)

Le World Wide Web Consortium (W3C) et l’Initiative d’Accès au Web (WAI) sont chargés de la création, de l’entretien et des mises à jour des WCAG. Les WCAG fournissent des recommandations et énoncent les critères de réussite pour aider à créer un Internet plus inclusif et accessible. La Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario s’appuie actuellement sur le niveau de conformité AA des WCAG 2.0 en ce qui a trait aux sites Web accessibles au public.  La version active des WCAG est la version 2.1 (publiée en 2018). La version 2.2 était en cours d’élaboration au moment de la rédaction du présent document. La plupart des organismes de législation s’appuient sur le niveau de conformité AA des WCAG 2.0 comme exigence actuelle pour tous les contenus des sites Web.

Les WCAG sont à titre informatif. Cependant, la création et la fourniture de contenu accessible ne se limitent pas à respecter les critères des WCAG. Puisque les WCAG et la technologie évoluent continuellement, le simple fait de respecter les critères aujourd’hui pourrait ne pas satisfaire aux recommandations futures en matière d’accessibilité. Il vaut mieux considérer les WCAG comme une ressource pratique, et non comme une liste de vérification obligatoire.

Les WCAG peuvent aussi être appliquées aux technologies de l’information et des communications en dehors du Web (consultez le document Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies [en anglais seulement] à titre d’exemple).

Autres normes internationales

D’autres normes internationales ont été élaborées pour l’approvisionnement public ou l’approvisionnement financé par le secteur public.

La norme ETSI (European Telecommunications Standards Institute) EN 301 549 publiée par la Commission européenne définit les exigences en matière d’accessibilité fonctionnelle qui peuvent s’appliquer aux divers produits et services de technologie de l’information et des communications (TIC). Elle définit les besoins en matière d’accessibilité pour les personnes ayant diverses déficiences et inclut les exigences des WCAG. Le Gouvernement du Canada a mis au point des outils pour appuyer la définition des spécifications de l’approvisionnement des TIC qui suivent la norme ETSI EN 301 549 (pour voir un exemple, consultez l’assistant des exigences en matière d’accessibilité aux TIC).

De la même façon, la Section 508 établit les normes juridiques (de la US Rehabilitation Act) utilisées par les acheteurs aux États-Unis. Ces normes sont requises pour l’approvisionnement financé par le secteur public aux États-Unis. Ces normes sont généralement harmonisées avec les autres normes, y compris la norme ETSI EN 301 549 et les WCAG.

Principes

Toutes les normes internationales sur l’accessibilité sont axées sur l’augmentation de l’accessibilité dans des contextes généraux et spécifiques. Ainsi, il n’est pas surprenant que même s’il existe des différences entre les diverses normes, elles partagent toutes des principes semblables. Par exemple, les règles pour l’accessibilité des contenus Web (WCAG) s’appuient sur quatre principes fondamentaux.

Principes des WCAG

Le sigle des quatre principes des WCAG est PURC :

  • Perceptible : L’information et les composants de l’interface utilisateur doivent être présentés à l’utilisateur de façon à ce qu’il puisse les percevoir. La perception, dans ce contexte, va au-delà de la vision et comprend les autres façons dont les personnes peuvent reconnaître et utiliser votre contenu (p. ex. signaux audio).
  • Utilisable : Les composants de l’interface utilisateur et de navigation doivent être utilisables pour un large public. Tout le monde ne peut pas utiliser un clavier et une souris, et beaucoup de dispositifs requièrent la technologie tactile. Les technologies d’assistance comme les lecteurs d’écran permettent aux utilisateurs d’interagir avec votre contenu d’une façon qui leur convient.
  • Compréhensible : Tous les aspects de votre contenu, de l’information elle-même à l’utilisation de l’interface utilisateur, doivent être faciles à comprendre. Des étiquettes claires et des motifs de conception reconnaissables réduisent l’effort nécessaire pour apprendre comment utiliser votre contenu et interagir avec lui.
  • Robuste : Le contenu doit être suffisamment établi et fiable pour être interprété uniformément par un maximum de navigateurs et de technologies d’assistance. Une application robuste est stable et prend l’avenir en considération.

D’autres normes internationales (comme la norme ETSI 301 549) incorporent les WCAG et y ajoutent divers principes et considérations qui s’appliquent aux logiciels, au matériel informatique et à d’autres technologies de l’information et des communications.

Versions et niveaux des WCAG

Les critères de réussite sont établis sur trois niveaux, soit les niveaux A, AA et AAA :

  • Le niveau A est le plus bas niveau requis pour satisfaire aux critères de réussite. Les applications qui respectent uniquement le niveau de conformité A ne sont pas accessibles. Cependant, ce niveau comprend les critères de réussite les plus importants.
  • Le niveau AA comprend les critères du niveau A. Pour respecter le niveau de conformité AA, il faut excéder le niveau A et respecter les techniques du niveau AA. Il s’agit de critères importants.
  • Le niveau AAA représente le plus haut degré d’utilisation des critères de réussite des WCAG. Répondre aux critères du niveau AAA peut être difficile, voire impossible pour certaines technologies.

 

Il est commun de viser le niveau de conformité AA, parce qu’il offre un bon degré d’accessibilité et qu’il est normalement atteignable pour la plupart des contenus. Il reflète également les normes de la Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario pour les sites Web.

Rappelez-vous, satisfaire aux critères de réussite des WCAG ne suffit pas nécessairement pour rendre votre produit accessible.

Au-delà des sites Web

Sites Web et applications bureautiques

Bien que les règles pour l’accessibilité des contenus Web (WCAG) aient avant tout été élaborées pour les sites Web, leurs principes peuvent aussi être appliqués aux applications bureautiques. Par exemple, la norme ETSI 301 549 (les normes d’accessibilité européennes) s’appuient sur les WCAG. Les principes fondamentaux sont semblables, et certaines techniques énoncées dans les WCAG peuvent être appliquées aux applications logicielles. (Consultez le document Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies [en anglais seulement].)

Une importante différence est que les tests automatisés sont limités pour l’accessibilité des applications bureautiques. Veuillez vous reporter aux sections Mise à l’essai et Accessibility Insights pour Windows.

Exigences fonctionnelles en matière d’accessibilité (EFA)

Les EFA font partie de la norme ETSI 301 549. Le Comité d’élaboration des normes d’information et de communications du Gouvernement de l’Ontario a recommandé l’adoption d’un ensemble d’EFA dans son examen des normes d’information et de communications. Ces recommandations n’ont pas été adoptées dans la loi.

Les EFA décrivent la fonctionnalité qui doit être disponible pour assurer que l’accessibilité accrue de l’information et des communications pour les personnes ayant un handicap. Elles ne définissent pas une méthode exacte pour atteindre cette fonctionnalité.

Par exemple, lorsque de l’information visuelle est fournie, les EFA énoncent les conditions suivantes :

  • Au moins une configuration qui ne requiert pas la vision doit être fournie;
  • La présentation visuelle doit être ajustable en vue de soutenir la vision limitée et/ou la perception ou le traitement visuel (le grossissement, le contraste, l’espacement, la mise en relief, la disposition);
  • Au moins une configuration doit transmettre l’information sans dépendre de la distinction des couleurs;
  • Il faut éviter les présentations visuelles qui peuvent déclencher des crises de photosensibilité;
  • Il faut pouvoir transformer la présentation en formats de rechange, y compris en formats tactiles.

 

Des EFA semblables ont été rédigées pour d’autres handicaps, y compris des exigences « lorsque la parole est requise pour le fonctionnement » et « lorsqu’une opération est limitée par le temps ».

La liste complète des EFA est accessible dans le Rapport 2020 sur les recommandations finales du Comité d’élaboration des normes d’information et de communications.

7

Lorsque les normes ne peuvent être atteintes

Dans certains cas, il peut être difficile, voire impossible, de satisfaire aux normes et réglementations en matière d’accessibilité. Par exemple, les logiciels tiers ou les logiciels hérités n’ont pas toujours la fonctionnalité robuste nécessaire à la création d’expériences inclusives.  En comprenant les écarts d’accessibilité et en assumant la responsabilité de fournir un avenir plus inclusif, vous pouvez réduire les risques à votre réputation et limiter les risques de litiges.

La première étape à suivre dans cette situation est de communiquer avec vos développeurs internes, vos partenaires ou vos fournisseurs. Vous pouvez déterminer les limites de l’accessibilité et demander une solution. Parfois, il existe une solution facile à mettre en œuvre. Parfois, aucune solution immédiate n’est possible. Cependant, une solution pourrait être prévue dans la feuille de route du produit, avec une estimation de la date à laquelle le produit sera plus accessible.

Si les écarts d’accessibilité ne peuvent être évités, pensez à documenter ces écarts de manière officielle, en précisant :

  • Les écarts et les obstacles précis en matière d’accessibilité;
  • Pourquoi il n’est pas possible d’incorporer la conception axée sur l’accessibilité et les critères et options d’accessibilité dans le processus d’approvisionnement;
  • Votre plan pour réduire ou éliminer ces obstacles.

 

Les normes d’accessibilité intégrées de la Loi de 2005 pour l’accessibilité des personnes handicapées de l’Ontario exige des organisations qu’elles fournissent, sur demande, une explication indiquant pourquoi les critères d’accessibilité ne faisaient pas partie du processus d’approvisionnement. Ce document vous aidera à répondre à une telle demande.

N’oubliez pas de prendre en compte l’expérience des utilisateurs finaux avant toute autre décision, même si votre code ne peut pas satisfaire à toutes les spécifications d’accessibilité. Garder votre public à l’esprit vous aidera à lui offrir la meilleure expérience possible.

III

Développement et approvisionnement

Les technologies éducatives sont soit développées, soit achetées. La présente section présente des recommandations sur la façon de mettre en place les normes d’accessibilité de votre établissement et d’intégrer l’accessibilité à vos processus de développement et d’approvisionnement.

La présente section traite des thèmes suivants :

8

Établir des normes d’accessibilité

Chaque établissement postsecondaire établit ses propres normes d’accessibilité numérique. Vous pouvez viser la conformité juridique (niveau AA des WCAG 2.0 pour les sites Web publics) ou choisir d’adopter une norme d’accessibilité plus élevée. Peu importe la norme d’accessibilité que vous choisissez, communiquez votre décision à l’interne. Il existe plusieurs ressources et lignes directrices sur l’accessibilité numérique, mais n’oubliez pas qu’un produit accessible est un produit que votre personnel et vos étudiants peuvent utiliser.

Ressources à considérer dans le choix des spécifications

Établir des spécifications en matière d’accessibilité numérique peut sembler une tâche colossale, mais rassurez-vous. Posez-vous les deux questions suivantes : Quels sont vos critères en matière d’accessibilité? À quelles technologies ces critères s’appliquent-ils (p. ex. sites Web, applications bureautiques, matériel informatique)?

Voici quelques éléments à considérer lorsque vous établissez vos spécifications :

  • Il est essentiel de comprendre les exigences juridiques qui régissent l’établissement des normes de votre établissement. Le niveau AA des règles pour l’accessibilité des contenus Web (WCAG) 2.0 est la norme minimale requise en Ontario. Cette exigence s’applique uniquement aux sites Web accessibles au public, mais les établissements peuvent choisir d’adopter des normes d’accessibilité plus élevées ou d’appliquer cette norme à d’autres technologies.
  • Les exigences juridiques pourraient être appelées à changer. Un comité d’élaboration des normes a recommandé l’adoption d’un ensemble d’exigences fonctionnelles en matière d’accessibilité (EFA) en tant que norme d’accessibilité en vertu des lois de l’Ontario. Ces recommandations s’appliqueraient à l’ensemble des technologies qui utilisent l’Internet pour fonctionner. Consultez la page sur les exigences juridiques pour en savoir plus.
  • Affin d’assurer des expériences inclusives, les spécifications pour les solutions Web s’appuient généralement sur les WCAG et sur une bonne compréhension des principes de conception inclusive, des obstacles à la technologie et des personas fréquemment utilisés dans la création d’expériences accessibles. Réfléchissez au niveau de conformité des WCAG que vous souhaitez atteindre. Voir la page Normes internationales pour obtenir davantage d’information.
  • Pour les contenus et la technologie en dehors du Web, vous pouvez utiliser les principes des WCAG ou la norme ETSI (European Telecommunications Standards Institute) EN 301 549.

Ressources :

9

Développement accessible

Comment intégrer l’accessibilité dans le processus de développement

Comme n’importe quelle autre contrainte fondamentale en matière de conception, il vaut mieux inclure (et tester) l’accessibilité à chaque étape du développement. Une bonne accessibilité ne survient pas par accident. S’appuyer sur une base solide en matière d’accessibilité aidera à prendre des décisions de conception tout au long du processus de développement, ce qui influencera les présentations visuelles (p. ex. les contrastes et la disposition) ainsi que le fonctionnement et la navigation en général.

Normes d’accessibilité

Il est essentiel de comprendre les normes d’accessibilité numérique et la façon dont elles s’appliquent à votre travail (p. ex. création d’un site Web, mises à jour ou développement d’application). En plus de comprendre les principes d’accessibilité numérique en général, assurez-vous de bien connaître les normes d’accessibilité de votre établissement. Cela vous permettra de les intégrer dans vos lignes directrices et votre processus global de développement.

Les normes des établissements correspondent souvent au plus bas niveau d’accessibilité requis et sont parfois basées sur les exigences juridiques. L’accessibilité numérique et les lignes directrices qui s’y rapportent (comme les WCAG) sont continuellement mises à jour et s’inscrivent dans un processus continu visant à améliorer l’accessibilité et à suivre les avancées dans le domaine des technologies et de la création de contenus Web. Ainsi, vous pourriez trouver utile de viser un niveau d’accessibilité supérieur aux normes établies par votre établissement, de sorte que votre contenu demeurera conforme en cas d’éventuelles modifications des exigences en matière d’accessibilité. Dans tous les cas, il est essentiel d’établir des critères de réussite précis pour assurer une conception accessible dès les premières étapes de développement.

Intégrer l’accessibilité tout au long du développement

L’idéal est de planifier, de mettre en œuvre et de tester votre produit à chaque niveau de conception. Nous avons adopté un modèle de conception à trois niveaux : les composants, l’intégration (ou les sous-systèmes) et le système. Les distinctions entre ces trois niveaux pourraient être floues dans le cas de systèmes simples, alors que les projets plus ambitieux pourraient comporter des niveaux hiérarchiques supplémentaires. Les principes et concepts énoncés dans la présente section peuvent s’appliquer aux projets simples ou complexes.

En général, le développement comporte trois niveaux :

  • Le niveau des composants concerne les widgets, les contrôles et les divers composants d’une même page Web.
  • Le niveau de l’intégration est un niveau d’agrégation intermédiaire qui concerne l’ensemble d’une page Web ou d’un écran dans une application.
  • Le niveau du système concerne le système en entier, soit le site Web ou l’application.

Niveau des composants

Au niveau des composants, tous les contrôles présentés à l’utilisateur doivent être accessibles au moyen de plusieurs formes d’accès. Par exemple, l’utilisateur doit pouvoir utiliser son clavier pour parcourir et utiliser les différents contrôles, à moins d’une raison justifiée d’empêcher ce genre d’accès (p. ex. une ressource servant à tester la précision d’un curseur). La plupart des bibliothèques d’interfaces utilisateur standards permettent la navigation à l’aide du clavier, par exemple l’utilisation de la touche de tabulation pour parcourir les champs, boutons, etc., ou l’utilisation du clavier pour sélectionner des options, saisir du texte, etc. Si votre application requiert un nouveau type de contrôle, pensez à intégrer l’accès clavier pour demeurer accessible.

Les WCAG fournissent plusieurs conseils quant à l’accessibilité des contrôles, tant au niveau de leur lecture que des interactions des utilisateurs. La lecture du contenu inclut également la lecture de la valeur d’une barre de réglage numérique et des descriptions textuelles des images et des contenus vidéo ou audio. La plupart des normes d’accessibilité décrivent également des critères importants pour l’interaction avec les contrôles (boutons, graphiques interactifs, boutons à bascule, etc.), y compris le comportement uniforme des claviers.

Niveau de l’intégration ou des sous-systèmes

Au niveau de l’intégration (ou des sous-systèmes, ou de la page Web), la planification d’une conception accessible comprend le l’ordre dans lequel l’utilisateur est guidé à travers les divers éléments de la page, y compris l’ordre des onglets et le parcours logique entre les contrôles ou les blocs de texte.

  • Ordre logique : Gardez en tête la façon dont les lecteurs d’écran interpréteront l’ordre de la page. Les lecteurs d’écran font ce qu’ils peuvent pour interpréter logiquement le contenu affiché, mais ils ne sont pas sans faille. Ainsi, faites des tests pour vous assurer que l’ordre de lecture des éléments (y compris le texte de remplacement) correspond à vos objectifs de conception.
  • Ordre des contrôles : Pensez aussi à tester l’ordre des contrôles et des actions sur une même page ou un même sous-système. Assurez-vous de mettre en évidence les actions irréversibles (p. ex. le paiement de facture dans une application de gestion bancaire). Si possible, présentez à l’utilisateur un résumé final de la transaction et donnez-lui la possibilité d’accepter, de modifier ou d’annuler l’action.

À cette étape du développement, considérez la navigation et les points de cheminement. Faites en sorte que les éléments de l’interface utilisateur utilisés pour naviguer dans l’application (ou les pages d’un site Web) soient identifiables et navigables à l’aide d’autres méthodes, comme un clavier. Lorsque cela est possible, utilisez une conception uniforme de sorte que les actions semblables fonctionnent de la même façon dans toute l’application. Cette uniformité aidera à créer une impression de continuité pour l’utilisateur et augmentera sa convivialité.

Niveau du système

Au niveau du système, tous les éléments de conception et les critères d’accessibilité fonctionnent conjointement pour créer une expérience utilisateur fluide et uniforme. Par exemple, faites en sorte que tous les points de cheminement mis en œuvre au niveau de l’intégration soient uniformes sur toutes les pages.

Ce niveau représente la vérification finale de la réussite aux niveaux inférieurs. Les blocs de navigation devraient être uniformes parmi tous les sous-systèmes (ou les pages du site Web) pour faciliter la navigation. Cela comprend les formulations, le mode d’interaction et la position des éléments. Assurez-vous de ne laisser aucun cul-de-sac de navigation (une page qui ne mène vers aucune autre page) et que la navigation entre les pages soit prévisible et facile à comprendre.

Introduction à l’accessibilité dans le langage HTML

Le langage HTML (HyperText Markup Language) est le langage de balisage (code) utilisé pour structurer les pages Web et leur contenu. Puisqu’il aide à définir les sites Web, ce langage est un facteur important de l’accessibilité des sites Web. Le langage HTML fournit des motifs attendus pour lire le contenu ou naviguer sur une page Web, un facteur décisif de l’accessibilité de l’expérience utilisateur. La structure du contenu HTML comprend des en-têtes, des paragraphes, des listes à puces, des images et des tableaux de données. Ce langage permet d’utiliser des balises pour étiqueter vos éléments.

Il existe plusieurs sous-ensembles de balises dans le langage HTML, dont les balises sémantiques. Les balises sémantiques contribuent grandement à l’accessibilité. En HTML, l’expression « sémantique » renvoie à la signification du code. Les balises sémantiques définissent le rôle de chaque élément. Par exemple, la balise <h1> représente un en-tête de niveau 1 sur la page (le titre principal), alors que la balise <li> définit un élément dans une liste. En comparaison, la balise <div> n’a aucune teneur sémantique et n’offre aucune information pertinente du point de vue de l’accessibilité. Par exemple, il est plus efficace d’utiliser la balise <button> sur un bouton et de lui donner un style particulier que d’utiliser la balise <div> et de lui ajouter des qualificatifs et des scripts. Les boutons comportent des traits inhérents et ont un comportement prévisible lorsqu’on interagit avec eux à l’aide d’une souris, d’un clavier ou d’un écran tactile. Utilisez les balises sémantiques chaque fois que possible pour favoriser l’accessibilité. Il vaut toujours mieux utiliser le code HTML et les balises sémantiques existantes plutôt que de créer quelque chose de nouveau.

En somme, acquérir une compréhension de base du langage HTML peut grandement faciliter la création de produits accessibles. Lorsque vous le pouvez, suivez les pratiques exemplaires en matière de codage HTML. De plus, vous pouvez utiliser les feuilles de style en cascade (CSS) pour contrôler le style du contenu HTML ou ajouter JavaScript (JS) pour la fonctionnalité. En général, les éléments sémantiques standards du langage HTML sont conformes aux normes d’accessibilité actuelles comme les WCAG, à condition que vous ne modifiiez pas trop leur fonctionnalité.

 

Ressources :

Introduction à ARIA

Le langage HTML (HyperText Markup Language) a d’abord été conçu pour créer des pages de texte statiques. JavaScript propose des composants qui n’existent pas dans le modèle HTML natif. La norme ARIA (Accessible Rich Internet Applications) offre aux responsables du développement des fonctionnalités d’accessibilité qui ne sont pas possibles avec le langage HTML seul.

ARIA est un ensemble d’attributs (propriétés des balises HTML) qui rend le contenu Web et les applications plus accessibles. Lorsque le recours aux balises sémantiques HTML n’est pas possible, ARIA permet de communiquer des renseignements sémantiques et des interactions aux technologies d’assistance. ARIA transmet aux technologies d’assistance de l’information sémantique sur les widgets (éléments de l’interface utilisateur), les structures (relations) et les comportements. Une expérience réellement accessible repose sur le bon usage de cet outil, car une mauvaise utilisation d’ARIA peut rendre les expériences désagréables, voire inutilisables.

Lorsque le code natif ou la technologie sous-jacente ne suffisent pas, les attributs ARIA peuvent rendre les balises HTML non sémantiques comme <div> plus accessibles. Par exemple, supposons que vous utilisiez une bibliothèque ou un cadre externe qui utilise la balise <div> pour définir un bouton. Il pourrait être plus simple d’ajouter une balise ARIA comme role=" button" pour ce composant plutôt que de récrire les fonctions et les styles existants. Faites attention lorsque vous adoptez cette approche, car vous devrez aussi confirmer que le code JavaScript approprié est en place pour rendre l’élément accessible (assurez-vous par exemple que l’élément peut recevoir le focus et définissez les gestionnaires d’événements lorsque l’utilisateur appuie sur une touche ou effectue un clic).

Si vous comptez améliorer l’accessibilité de votre contenu HTML à l’aide de balises ARIA, consultez les pratiques de rédaction et les exemples détaillés ci-dessous. En résumé, la première règle d’ARIA est la suivante : si vous pouvez utiliser des attributs sémantiques ou HTML, utilisez-les. Notez bien qu’ARIA n’est utile que lorsqu’il est bien utilisé : il vaut mieux l’éviter complètement plutôt que de l’utiliser incorrectement.

Exemples de situations qui justifient l’utilisation d’ARIA

Points de repère

  • Les points de repère définissent les sections d’une page Web, ce qui facilite la navigation pour les utilisateurs de lecteurs d’écran. Les points de repère peuvent être définis en tant qu’éléments HTML ou à l’aide de rôles ARIA : un point de repère <header> peut être remplacé, au besoin, sur n’importe quel élément (comme une balise <div>) par l’ajout de role="banner".
  • Un point de repère <aside> peut être remplacé par role="complementary".
  • Un point de repère <footer> peut être remplacé par  role="contentinfo".

Rôles ARIA et JavaScript

Certains cadres JavaScript génèrent des pages Web contenant du code non sémantique, par exemple un élément <div> au lieu de <button>. Ajouter le rôle ARIA role="button" attribuera un rôle sémantique à l’élément <div>.

Lorsque JavaScript est utilisé pour créer des composants spéciaux qui n’existent pas nativement en HTML, il peut être nécessaire de donner un rôle ARIA pour définir ces composants. Par exemple :

  • Un accordéon sera agrandi et réduit à l’aide d’un bouton portant l’attribut suivant : aria‑expanded="true"/"false".
  • Un ensemble d’onglets sur une page Web devra avoir les attributs role="tablist", role="tab" et role="tabpanel".

D’autres exemples sont fournis sur le site des pratiques de rédaction ARIA (en anglais seulement).

Étiquettes

Il existe plusieurs façons d’étiqueter un bouton (en plus du texte à l’écran). Par exemple :

  • Un attribut aria-label suivi d’un texte précisant l’étiquette, p. ex. aria-label="continue".
  • Un attribut aria-labelledby peut pointer vers le texte existant à l’écran à titre d’étiquette.
  • Un attribut aria-describedby peut relier sémantiquement un champ à remplir avec une erreur intégrée. Un lecteur d’écran annoncera automatiquement l’erreur lorsque l’utilisateur utilise la touche de tabulation pour atteindre le champ de saisie.

Zones live ARIA

Une zone live Aria est une section d’une page Web qu’un lecteur d’écran annonce automatiquement si le contenu change dynamiquement après le chargement initial de la page. La zone live ARIA fournit des messages importants quant à l’état du contenu. On retrouve plusieurs codes, dont :

  • role="alert" ou aria-live="assertive", qui indique au lecteur d’écran d’arrêter le message actuel pour annoncer un changement de contenu dynamique;
  • aria-live="polite", qui indique au lecteur d’écran d’annoncer la zone live mise à jour après avoir terminé d’annoncer le contenu en cours de lecture.

aria-hidden

L’attribut aria-hidden="true" indique au lecteur d’écran d’ignorer un élément et de ne pas l’annoncer. Aria-hidden peut être utile pour le contenu qui s’affiche à l’écran, mais qui pourrait provoquer la confusion chez les utilisateurs de lecteurs d’écran.

Par exemple :

  • Une icône placée à côté d’un texte redondant (comme une icône de corbeille apposée au mot « supprimer »), car l’utilisateur n’a pas besoin que les deux éléments soient annoncés;
  • Le contenu de l’arrière-plan qui est grisé lorsqu’une fenêtre contextuelle s’affiche par-dessus la page. Lorsqu’une fenêtre contextuelle s’affiche, les utilisateurs de lecteurs d’écran n’ont pas besoin de lire la page en arrière-plan.

Ressources :

Modèles accessibles

Une bonne accessibilité est intégrée dans chacune des étapes du processus de développement Web. Les responsables de la conception, les responsables du développement et les autres spécialistes du contenu ont tous un rôle à jouer dans la création de sites Web accessibles. Cette page explique comment les modèles accessibles peuvent faciliter ce processus.

Créer des maquettes fonctionnelles accessibles (responsables de la conception)

La maquette fonctionnelle d’une page Web est un document de conception visuelle créé par les responsables de la conception. La maquette fonctionnelle montre la disposition d’une page Web en organisant la page en diverses sections qui seront plus tard remplies par des images et du texte. Cette maquette peut régler la disposition des pages d’une manière qui maximise la convivialité et la facilité d’utilisation. L’utilisation de maquettes fonctionnelles permet d’assurer l’uniformité de la disposition des pages d’un même site Web, améliorant ainsi l’accessibilité pour les utilisateurs présentant un handicap cognitif.

Créer des modèles accessibles (responsables du développement)

Les responsables du développement analysent la maquette fonctionnelle créée par les responsables de la conception et créent un modèle de page Web codé en HTML. Le modèle doit être codé de manière à assurer l’accessibilité des pages de contenu. Ce modèle peut définir chaque section de la page en prévision du contenu, qui sera fourni plus tard par les spécialistes du contenu (p. ex. les titres, la navigation, le corps, le pied de page, etc.).

Le World Wide Web Consortium (W3C) offre d’excellentes ressources sur la création de modèles accessibles, notamment :

 

Créer du contenu accessible dans les modèles (spécialistes du contenu)

Même si les modèles de contenu peuvent établir une sorte de barrière de sécurité, comme un formulaire dans un système de gestion de contenu, il peut arriver que le contenu des sites Web crée aussi des obstacles. Un modèle de contenu accessible aide les spécialistes du contenu à produire du contenu accessible. Consultez la section Accessibilité des documents pour en savoir plus.

Un modèle de contenu devrait permettre aux spécialistes du contenu de mettre à jour tout le contenu pertinent pour la page Web, y compris :

  • le titre de la page <title> (qui s’affiche dans l’onglet du navigateur);
  • les titres et leur niveau (h1, h2, h3, etc.);
  • les paragraphes;
  • les listes, ordonnées (numérotées) et non ordonnées (à puces);
  • les images et leur texte de remplacement.

Comment ajouter du contenu accessible

Essayez toujours de faire en sorte que le contenu des pages Web soit écrit avec un code sémantique, c.-à-d. qui utilise la mise en forme HTML standard. Le contenu sémantique améliorera l’accessibilité et est compatible avec les technologies d’assistance comme les lecteurs d’écran, la reconnaissance vocale et les claviers. Le contenu mis en forme de cette façon présente plusieurs avantages en matière d’accessibilité. Par exemple :

  • Le titre de la page <title> est annoncé par les lecteurs d’écran lors du chargement de la page;
  • Les titres et leur niveau (h1, h2, h3, etc.) sont annoncés par les lecteurs d’écran pour fournir du contexte aux utilisateurs ayant une déficience visuelle. Les titres fournissent également une façon de parcourir ou de survoler le contenu d’une page;
  • Les paragraphes correctement étiquetés améliorent la lisibilité et permettent aux utilisateurs de mieux contrôler la personnalisation des contrastes;
  • Les listes ordonnées (numérotées) et non ordonnées (à puces) sont annoncées par les lecteurs d’écran pour fournir du contexte et définir les attentes (nombre d’éléments dans la liste);
  • Le texte de remplacement des images est annoncé par les lecteurs d’écran pour donner du sens au contenu pour les personnes ayant une déficience visuelle.

Comment demander la modification d’un modèle

Il est important que les spécialistes du contenu consultent les responsables de la conception ou l’architecte en TI avant d’apporter des modifications aux modèles de pages ou aux maquettes fonctionnelles. Si les modifications apportées à une maquette fonctionnelle ont un effet sur le contenu de la page, alors le modèle de contenu devra peut-être aussi être revu.

Références :

Tests en cours de développement

Il est essentiel de faire des tests afin d’établir et de maintenir l’accessibilité d’un site Web. Intégrer des tests dans le processus de développement permettra de confirmer que les spécifications d’accessibilité ont été respectées. Les responsables de la conception, les spécialistes du contenu, les responsables des tests de fonctionnalité et les responsables du développement jouent tous un rôle dans l’évaluation de l’accessibilité. Tous les aspects du produit (le code, les mises à jour et même la modification de la couleur du texte ou des icônes) peuvent créer des problèmes d’accessibilité imprévus.

L’évolution des technologies d’assistance et des navigateurs pourraient également générer de nouveaux problèmes d’accessibilité dans l’avenir. Des mises à jour régulières ou une bonne surveillance peuvent réduire ce risque.

Le reste de cette page présente des outils pratiques selon les divers rôles.

  • Responsables de la conception : Vérifiez le contraste de couleurs du texte et des icônes. Consultez la section Mise à l’essai du contraste des couleurs.
  • Spécialistes du contenu : Réfléchissez à la lisibilité et à la compréhensibilité de votre contenu. Pensez notamment à utiliser un langage simple pour rendre votre contenu accessible aux personnes ayant un trouble d’apprentissage, un handicap cognitif ou une barrière de langue. Consultez la section sur l’utilisation d’un langage simple.
  • Responsables des tests de fonctionnalité : Les tests d’utilisation des claviers et des lecteurs d’écran assurent que les fonctionnalités et les flux de travail sont accessibles à l’aide d’un clavier seul (sans souris). Consultez les sections Mise à l’essai à l’aide d’un clavier et Mise à l’essai à l’aide d’un lecteur d’écran.
  • Responsables du développement : L’automatisation est une excellente façon de tester l’accessibilité. Les tests automatisés peuvent aider à déceler et à prévenir les solutions temporaires. Cependant, l’automatisation à elle seule ne garantit pas l’accessibilité; une certaine validation manuelle est aussi nécessaire. Consultez la section sur les outils axe de Deque et Accessibility Insights.

Outils de surveillance de sites Web

Pour les sites Web déjà publiés, il existe plusieurs outils de tableau de bord qui permettent de surveiller le site en continu pour déceler les problèmes d’accessibilité. Ceux-ci sont particulièrement utiles pour les grandes organisations possédant des sites Web de grande envergure. Ces outils sont habituellement payants. Parmi les outils principaux de ce type dans l’industrie, il y a :

Exception aux normes

Il ne faut pas se limiter aux seules règles de conception de sites Web. Ce qui compte avant tout, c’est l’expérience utilisateur. Pour cette raison, certaines exceptions aux règles peuvent être admises. Voici quelques exemples de situations où les critères de réussite des WCAG peuvent être flexibles afin d’accorder la priorité à l’expérience client :

1.3.4 : Orientation

Ce critère de réussite établit qu’une application mobile ou une page Web doit pouvoir s’afficher au format portrait et au format paysage. Une exception possible est dans les situations où le contenu ne serait pas compris si ce critère était respecté, par exemple dans le cas du dépôt électronique de chèques, d’une application de réalité virtuelle (RV) ou d’une application de piano. Toutes ces situations exigent une orientation paysage exclusivement.

1.4.3 : Contraste (minimum)

Ce critère de réussite précise que le texte et les icônes doivent respecter une exigence établie en matière de contraste de couleurs. Les logos d’entreprises, cependant, ne sont pas soumis à cette règle.

1.4.5 : Images représentant du texte

Utilisez du texte plutôt que des images représentant du texte. Les logos sont exemptés de cette exigence.

2.4.3 : Parcours de focus

Lorsqu’un utilisateur utilise la tabulation pour parcourir les éléments cliquables sur une page, le parcours de focus doit aller de haut en bas, de gauche à droite. Dans certaines situations, l’expérience peut être améliorée en dérogeant à cette règle.

Par exemple, lorsque le bouton primaire (« Continuer ») est situé sur la droite (par convivialité) et que le bouton secondaire (« Annuler ») est sur la gauche. Dans ce cas, le bouton « Continuer » doit être atteint avant le bouton « Annuler ».

Contexte supplémentaire pour aider les utilisateurs de lecteurs d’écran

Le texte à l’écran est la meilleure façon d’étiqueter les boutons. Cependant, il est acceptable d’utiliser une étiquette aria-label si le bouton est facilement reconnaissable. Assurez-vous d’étiqueter l’icône de manière concise, par exemple en utilisant « imprimer » plutôt que « bouton imprimer ».

Contenu pour ordinateurs et contenu mobile

De nos jours, le développement Web de contenu pour ordinateurs et de contenu mobile est très similaire. Néanmoins, certaines différences doivent être prises en compte dans le processus de développement.

Historiquement, les appareils mobiles de premières générations offraient souvent une faible résolution et peu de caractéristiques. Quant à eux, les appareils modernes, comme les téléphones intelligents et les tablettes informatiques, peuvent généralement afficher des sites Web entiers. Ainsi, la distinction entre le développement de contenu Web pour les ordinateurs et les appareils mobiles s’est atténuée. Les contenus réactifs sélectionnent automatiquement la disposition optimale en fonction des dimensions de l’écran de l’utilisateur, ce qui est pratique pour les responsables du développement, car cela permet de créer une seule version d’un site Web. Cette version peut adapter l’affichage de manière dynamique en fonction des dimensions ou de la résolution de l’écran ou de la fenêtre.

Cela dit, il existe tout de même certains éléments propres à chaque mode d’utilisation des contenus Web qu’il faut prendre en compte dans la conception d’un site Web destiné à être consulté à partir de plusieurs plateformes.

Souris ou écran tactile

L’utilisateur peut utiliser une souris pour cliquer sur les divers éléments dans un navigateur standard sur son ordinateur. Le pointeur de la souris est un moyen de contrôle précis. En général, les personnes qui peuvent utiliser une souris peuvent cliquer sur une zone cible de petite taille.

Les critères de réussite des WCAG précisent que les cibles doivent être espacées d’au moins 24 pixels CSS (pour le niveau de conformité AA) et avoir une taille d’au moins 44 sur 44 pixels CSS (pour le niveau de conformité AAA).

Deux boutons, chacun de 44 sur 44 pixels CSS, espacés de 24 pixels CSS

En plus des aspects d’accessibilité entourant les cibles de petite taille, il faut également songer à l’expérience mobile. Les utilisateurs d’appareils mobiles utilisent leurs doigts pour toucher les icônes, les boutons et les autres éléments de l’interface utilisateur. Un doigt est un outil de sélection beaucoup plus gros (et moins ciblé) qu’un pointeur de souris. De plus, utiliser un doigt bloque la vue de l’écran. Par conséquent, il est essentiel de veiller à créer des zones cibles larges et, si possible, assez espacées pour permettre une sélection facile, sans activer accidentellement les éléments avoisinants.

Commutateur ou clavier

Sur les systèmes de bureautique, les technologies d’assistance prennent souvent la forme de claviers virtuels. Ceux-ci peuvent utiliser la touche de tabulation pour parcourir les éléments sélectionnables de l’interface utilisateur ou encore les flèches (ou les touches Page précédente ou Page suivante) pour faire défiler le contenu.

Les appareils mobiles utilisent souvent des méthodes différentes. Les utilisateurs dont le handicap affecte la dextérité peuvent utiliser un appareil composé de deux commutateurs (ou plus) pour parcourir les éléments interactifs ou sélectionner le mode de ciblage. En général, un commutateur sert à parcourir les éléments de l’interface utilisateur sur la page, alors que l’autre sert à activer l’élément. Une autre méthode consiste à utiliser un commutateur pour activer un balayage de l’écran, permettant à l’utilisateur de cibler directement les éléments à l’écran. Les commutateurs peuvent être manuels, installés sur un fauteuil roulant ou activés à l’aide du pied.

Voici un appareil de base comportant deux commutateurs : l’un pour parcourir les éléments de l’interface, et l’autre pour les activer.

Pour les dispositifs d’aspiration/expiration, un commutateur est activé par l’aspiration, et l’autre, par l’expiration.

Un suiveur oculaire peut être installé au bas de l’écran. Ce type d’appareil utilise une lumière infrarouge et une série de caméras pour détecter la direction du regard. Fixer un élément de l’interface utilisateur pendant une durée déterminée permet d’activer cet élément.

Zoom à deux doigts

Les utilisateurs d’appareils mobiles s’attendent à pouvoir agrandir ou rapetisser le contenu sur leur appareil. Assurez-vous que votre application répond aux événements de zoom, comme le pincement à deux doigts, sans défaire la disposition du contenu.

Paramètres de police des appareils

Les applications mobiles doivent respecter les paramètres de police de chaque appareil, par exemple si l’utilisateur a défini une police grasse ou de grande taille. Les sites Web mobiles n’ont pas besoin de s’adapter aux paramètres des appareils.

Au-delà du langage HTML : les applications accessibles

Même si plusieurs normes, y compris les règles pour l’accessibilité des contenus Web (WCAG) ont été élaborées pour les sites Web et le langage HTML, les principes sous-jacents peuvent aussi s’appliquer à d’autres technologies. Les WCAG traitent des principes de conception pour la présentation du contenu, la navigabilité des contrôles (comme l’utilisation d’une souris ou d’un clavier) et les principes généraux de l’interaction des utilisateurs avec les contenus. Comprendre ces principes dès les premières étapes du développement vous aidera à prendre les bonnes décisions en matière de conception tout au long du projet, peu importe la technologie dont il est question. Le World Wide Web Consortium (W3C) fournit des directives quand l’application des WCAG aux technologies autres que les sites Web (en anglais seulement).

Pour les tests, il existe quelques outils standards qui utilisent l’automatisation pour tester l’accessibilité des programmes informatiques. L’outil Accessibility Insights pour Windows de Microsoft en est un exemple. La plupart des systèmes d’exploitation sont dotés d’une technologie d’accessibilité intégrée. Prenez le temps d’explorer les caractéristiques d’accessibilité du système d’exploitation cible de votre contenu, puis utilisez les outils qui s’offrent à vous pour tester votre logiciel tout au long du développement. Vous trouverez des exemples et des conseils à la section Tests en cours de développement.

Accessibilité des documents

Les fichiers comme les PDF, les feuilles de calcul Excel, les fichiers Word et les présentations créent des obstacles pour le personnel et les étudiants lorsqu’ils ne sont pas créés pour être accessibles.

En structurant votre contenu en amont, vous économiserez du temps au moment de préparer des documents accessibles. Si votre objectif est de créer un PDF, alors la façon la plus directe de le rendre accessible est à la source (dans Word, Excel, PowerPoint, etc.). Vous aurez aussi besoin d’Adobe Acrobat Pro ou de PDF Accessibility Checker (PAC) 2 (pour Windows seulement) pour rendre vos PDF accessibles.

Voici quelques conseils utiles pour la création de documents accessibles, peu importe l’application utilisée :

  • Utilisez un langage simple;
  • Utilisez des liens contextuels descriptifs;
  • Ajoutez du texte de remplacement;
  • Utilisez les titres dans les documents;
  • Pensez à l’accessibilité des médias temporels (audio et vidéo);
  • Utilisez les vérificateurs d’accessibilité intégrés.

Utiliser un langage simple

Un langage simple rend votre texte concis et facile à comprendre. Ce type de langage est utile pour les personnes qui présentent un trouble d’apprentissage, un handicap cognitif ou une barrière de langue. Déterminez le niveau de simplicité nécessaire en fonction de votre public cible. Dans le contexte d’études postsecondaires, il peut être difficile d’utiliser un langage simple, car un niveau de lecture avancé ou certaines connaissances techniques peuvent être des prérequis dans certains cours ou programmes. Cependant, lorsque l’information doit être accessible au public, utilisez un langage simple autant que possible.

Pour écrire en langage simple, essayez d’appliquer les conseils suivants :

  • Éliminez les mots superflus;
  • Utilisez des mots courts de tous les jours, par exemple :
    • souvent, plutôt que fréquemment;
    • ensuite, plutôt que subséquemment;
    • aide, plutôt qu’assistance;
  • Utilisez la voix active (c.-à-d. que le sujet qui fait l’action est au début de la phrase);
    • « Nous examinerons les dossiers soumis » (voix active);
    • « Les dossiers soumis seront examinés » (voix passive);
  • Rédigez des phrases courtes;
  • Utilisez des verbes d’action;
  • Évitez les mots compliqués, ou expliquez-les si vous devez les utiliser;
  • Évitez les doubles négations;
  • Utilisez des listes à puces;
  • Choisissez des mots clairs.

    Pour plus d’information et de ressources sur le langage simple, consultez les liens suivants :

     

Utiliser des liens contextuels descriptifs

Sur les sites Web comme les applications, on retrouve souvent des liens qui mènent vers d’autres pages. Le texte qui décrit ces liens n’est pas toujours très clair. Par exemple, si un utilisateur utilise un lecteur d’écran et entend les mots « cliquez ici », sans plus d’information, alors il ne saura pas où mène ce lien. Le texte du lien devrait annoncer clairement la page de destination. Évitez les expressions comme « cliquez ici » ou « en savoir plus », car elles ne sont pas assez descriptives et elles n’indiquent pas à l’utilisateur l’objectif ou la direction des liens.

Ajouter du texte de remplacement

Le texte de remplacement est une série de mots descriptifs appliqués à de l’information visuelle comme une image, un graphique ou un diagramme. Le texte de remplacement est incorporé et habituellement caché. Lorsqu’un lecteur d’écran rencontre une image, il lit le texte de remplacement qui y est rattaché.

Dans Microsoft Word, vous pouvez ajouter un texte de remplacement aux images à l’aide d’un clic droit sur l’image, puis en sélectionnant l’option « Afficher le texte de remplacement… ». Dans PowerPoint, sélectionnez votre image, puis accédez à l’onglet menu Format de l’image dans le ruban. Vous trouverez l’option « Texte de remplacement » dans le groupe Accessibilité.

Une capture d’écran montrant le panneau d’ajout de texte de remplacement dans Microsoft Word

La plupart des outils, y compris les systèmes de messagerie électronique et PowerPoint, présentent également des outils intégrés pour ajouter du texte descriptif. Beaucoup d’applications génèrent une description automatique des images. Ne vous fiez pas à ces descriptions, car elles sont souvent de mauvaise qualité.

Utiliser des titres dans les documents

Les titres peuvent aider à structurer les documents. Ils améliorent également leur lisibilité. Les titres divisent visuellement le texte et aident les lecteurs à parcourir et à repérer l’information qu’ils recherchent.

Il est important que ces titres soient correctement codés pour les personnes qui utilisent des lecteurs d’écran. Dans Microsoft Word, utilisez les formats de titres fournis dans le groupe Styles du ruban. Utilisez les titres de niveau 1 pour les titres principaux, et les titres de niveau 2 ou supérieurs pour les sous-titres au sein d’une section donnée. Cela améliore l’efficacité des lecteurs d’écran et permet de parcourir le contenu plus facilement.

Penser à l’accessibilité des médias temporels (audio et vidéo)

Assurez-vous de fournir un équivalent textuel pour les médias temporels comme le contenu audio ou vidéo. Pour ce faire, vous pouvez utiliser les sous-titres ou les transcriptions. Ne vous fiez pas uniquement à l’audio pour communiquer le sens. De la même manière, ajoutez une description audio des vidéos, et ne vous fiez pas uniquement à la vidéo pour communiquer le sens.

Évitez les animations répétitives ou les effets clignotants, car ceux-ci peuvent déclencher des crises de photosensibilité chez certaines personnes. Vous pouvez également considérer l’intégration de paramètres de mouvements réduits, c.-à-d. qui permettent aux utilisateurs de limiter ou d’éliminer les animations, s’ils le souhaitent.

Conseils propres à certaines applications

Adobe PDF (Portable Document Format)

Les fichiers PDF peuvent être rendus accessibles à l’aide d’étiquettes, comme le recommandent les plus récentes règles d’accessibilité universelles PDF/UA (en anglais seulement) et les WCAG 2.0 pour les PDF (en anglais seulement). Inclure une mise en forme accessible dans votre document source peut aider à étiqueter correctement votre PDF, mais vous pourriez devoir en ajouter manuellement.

Produits de Microsoft

Microsoft inclut des Vérificateurs d’accessibilité dans ses applications. Pour utiliser le vérificateur, dans le ruban, ouvrez l’onglet Révision, puis cliquez sur l’option « Check Accessibility » (vérifier l’accessibilité). Le programme détectera certains obstacles potentiels (pas tous) pour les personnes ayant un handicap, puis fournira des suggestions pour éliminer ces obstacles et améliorer l’accessibilité de vos documents.

Microsoft Excel

Les conseils suivants vous aideront à améliorer l’accessibilité de vos feuilles de calcul Excel :

  • Ajoutez une description pour la disposition du document. Par exemple, ajoutez une note indiquant la direction du texte, soit de haut en bas ou de gauche à droite;
  • Utilisez des conventions uniformes dans l’ensemble du document;
  • Appliquez les bons formats à vos cellules, selon qu’il s’agit de texte, de données monétaires, de dates, etc.;
  • Donnez un titre aux colonnes et aux lignes des tableaux de données;
  • Séparez les titres pour qu’ils soient compréhensibles;
  • Donnez à chaque feuille un nom clair, plutôt que de laisser le nom par défaut « Feuil1 », « Feuil2 », etc.
Microsoft PowerPoint

Les conseils suivants vous aideront à améliorer l’accessibilité de vos présentations PowerPoint :

  • Créez des présentations courtes et claires. Cela aidera les personnes avec un trouble d’apprentissage ou cognitif à rester concentrées;
  • Gardez votre message aussi concis que possible; ne remplissez pas vos diapositives de texte. Cela permet également de respecter les différentes vitesses de lecture et de compréhension des personnes. Essayez de vous en tenir à un maximum de 4 ou 5 puces par diapositive;
  • Gardez en tête que l’ordre des éléments des éléments (premier plan, arrière-plan, etc.) définit l’ordre de lecture des technologies d’assistance;
  • N’oubliez pas que puisque les présentations sont destinées à être visionnées à partir d’une certaine distance, la taille de la police et les contrastes sont très importants. Utilisez une police d’au moins 24 points et des couleurs contrastantes;
  • Limitez ou éliminez les animations ou les transitions entre les diapositives, car celles-ci créent des distractions visuelles inutiles.

Si votre présentation est destinée à être transmise au format numérique, par exemple sur votre site Web ou dans un courriel, pensez aux personnes qui ont une perte visuelle ou qui utilisent un lecteur d’écran :

  • Ajoutez un texte de remplacement pour chaque image;
  • Utilisez les modèles de diapositives intégrés, car ils offrent une structure de navigation pour les lecteurs d’écran.
Pour en savoir plus, consultez le guide d’accessibilité de Microsoft pour les présentations PowerPoint.

 

Déclarations d’accessibilité

Pensez à créer une déclaration d’accessibilité à publier sur votre site. Une telle déclaration témoigne de votre engagement envers l’accessibilité et énonce vos normes en la matière.  Documenter les caractéristiques d’accessibilité de votre site et ses limites connues favorise la confiance et la discussion. Vous pouvez également inviter les visiteurs du site à fournir leurs commentaires, puis leur répondre pour montrer que vous êtes engagés à faire de votre mieux pour incorporer leurs suggestions. La Loi de 2005 sur l’accessibilité des personnes handicapées de l’Ontario exige des organisations qu’elles établissent « processus de rétroaction qui lui permet de recevoir les observations des intéressés sur [la façon dont elle fournit ses biens, ses services ou ses installations aux personnes handicapées] et d’y répondre ».

Le World Wide Web Consortium (W3C) propose une excellente ressource sur l’élaboration d’une déclaration d’accessibilité (en anglais seulement). Par exemple, l’énoncé sur l’accessibilité du Gouvernement du Canada peut vous donner quelques idées pour créer votre propre déclaration.

10

Approvisionnement accessible

Les politiques et autres documents présentant les processus et les engagements envers l’accessibilité peuvent contribuer à savoir quand et comment les critères d’accessibilité seront intégrés dans l’approvisionnement comme l’exige la Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario. L’intégration des critères d’accessibilité peut ne pas être pratique pour certains approvisionnements, comme les petits achats de la faculté. Toutefois, il faut considérer l’intégration des critères d’accessibilité pour les autres achats d’envergure ou les outils numériques essentiels. Ceci garantira un accès égal à tous les apprenants et à toutes les apprenantes.

De nombreux collèges et universités disposent de politiques sur les pratiques d’approvisionnement accessible. Toutefois, peu d’établissements d’enseignement postsecondaire de l’Ontario disposent de politiques écrites sur l’approvisionnement numérique accessible. Par exemple, bon nombre d’universités américaines disposent de politiques sur l’approvisionnement en matière d’accessibilité numérique en raison des obligations légales imposées par la Section 508. Même si les modalités précises de ces politiques ne peuvent être directement appliquées aux établissements d’enseignement postsecondaire de l’Ontario, elles offrent un cadre général pour intégrer certaines considérations sur l’accessibilité numérique dans les processus d’approvisionnement.

Il est possible de consulter, par exemple :

Chaque organisation abordera l’approvisionnement numérique accessible de manière légèrement différente. Les politiques présentées ci-dessus et les autres pratiques exemplaires utilisent, en général, les étapes présentées sur ces pages.

Organisation de l’approvisionnement

Rassembler les bonnes personnes

Au début du processus d’approvisionnement d’une technologie éducative principale, il est utile de rassembler les bonnes parties prenantes. Idéalement, ce groupe est composé de parties prenantes pour l’approvisionnement, les technologies de l’information, les handicaps et l’accessibilité, la population étudiante, le corps enseignant et les responsables de l’administration.

Ce groupe de travail doit participer à toutes les étapes de l’approvisionnement, lorsque cela est possible et pertinent. Les parties prenantes peuvent participer à l’élaboration des spécifications, à la rédaction des demandes de soumission, à l’évaluation des propositions et aux rencontres avec les fournisseurs.

Rassembler l’information

Avant de commencer le processus d’approvisionnement, faites le point sur les obstacles à l’accessibilité numérique dans votre organisation. Les services d’accessibilité et les technologues en adaptation peuvent vous fournir des renseignements utiles sur les obstacles que rencontre la population étudiante en situation de handicap. Avoir ces obstacles en tête permettra de s’assurer que l’accessibilité demeure une priorité tout au long du processus d’approvisionnement.

Détermination des spécifications

La première étape consiste à déterminer les exigences précises qui s’appliquent, le cas échéant, à votre organisation. En plus de l’obligation générale de prendre « en compte la conception axée sur l’accessibilité et les critères et options d’accessibilité lors de l’obtention ou de l’acquisition de biens, de services ou d’installations », les exigences actuelles de la Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario relatives aux collèges et aux universités sont présentées sur la page Exigences juridiques pour l’Ontario. Il est à noter que ces obligations légales peuvent changer dans le futur.

En plus de ces obligations, les établissements d’enseignement postsecondaire sont invités à intégrer des spécifications relatives à l’accessibilité dans leurs approvisionnements. Mettre en place une politique qui définit le niveau d’accessibilité permettra plus facilement de toujours offrir du contenu accessible. Voir la page Approvisionnement accessible pour obtenir des conseils sur les politiques.

Définition des spécifications

Certaines organisations incluent un énoncé général dans leurs demandes de soumission demandant vaguement le respect des normes ou des dispositions législatives. Il est pratiquement impossible de déterminer si un produit respecte les exigences en matière d’accessibilité à partir d’un énoncé général. Par exemple, un énoncé exigeant « le respect des normes de la Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario » serait sans intérêt pour la plupart des approvisionnements parce qu’il n’existe aucune norme précise dans cette loi au sujet de l’approvisionnement.  Il est donc préférable de préciser les exigences que le produit doit respecter en matière d’accessibilité.

La précision des spécifications dépend de l’objet de l’approvisionnement (p. ex. matériel informatique, logiciel, tablette, téléphone) ainsi que de sa fonction prévue (p. ex. communications vocales, transmissions vidéo). Afin d’assurer une accessibilité totale, il faudra inclure certaines spécifications qui peuvent sembler à première vue inutiles. Par exemple, si la documentation du produit comprend une vidéo, il pourra être alors utile de mentionner les spécifications relatives à la vidéo et à l’audio.

Deux outils principaux peuvent vous aider à définir les spécifications dans les documents d’approvisionnement : un outil du gouvernement canadien et un du gouvernement des États-Unis (lien uniquement en anglais). Ils sont fondés sur des normes très similaires, mais légèrement différentes (Institut européen des normes de télécommunication [ETSI] et Section 508). L’outil canadien s’applique davantage aux établissements ontariens, car il ne fait pas référence à la législation américaine.

Intégration des spécifications dans les demandes de soumission

Étude de marché 

Les exigences en matière d’accessibilité aux États-Unis et en Europe font qu’il existe de plus en plus de produits accessibles dans le monde. (Voir la page Normes internationales pour obtenir davantage d’information). L’étude de marché peut éclairer une stratégie d’approvisionnement en déterminant les produits accessibles disponibles. De nombreux fournisseurs offrent ou publient également des rapports de conformité en matière d’accessibilité (RCA) ou des modèles volontaires d’accessibilité des produits (VPAT) pour présenter le niveau actuel d’accessibilité de leurs produits.

De plus, il faut penser à rencontrer les fournisseurs pour discuter de l’importance de l’accessibilité dans le cadre de l’approvisionnement. L’organisme Global Initiative for Inclusive ICTs (G3ICT) a préparé un guide de discussion (en anglais seulement) pour guider les conversations avec les fournisseurs. Celui-ci comporte des questions clés et les réponses possibles des principaux acteurs en matière de technologie accessible. L’organisme G3ICT recommande :

  • d’organiser une série de rencontres avec les fournisseurs sélectionnés pour leur respect des critères d’accessibilité dans le cadre de l’appel d’offres ou de la demande de soumission
  • de préciser de quelle manière les produits des fournisseurs respectent les spécifications en matière d’accessibilité
  • de poser des questions sur l’expérience des fournisseurs en matière d’accessibilité et sur la manière dont leurs processus opérationnels garantissent l’accessibilité de leurs produits
  • de demander aux fournisseurs de faire des démonstrations de l’utilisation du produit dans le contexte visé, en se concentrant sur son accessibilité et son application dans différentes situations, notamment une utilisation individuelle et une utilisation collaborative

Intégration des spécifications dans les demandes de soumission

Dans les demandes de soumission, en plus des spécifications, il peut aussi être utile de :

  1. Citer précisément les normes et l’engagement de l’organisation en matière d’accessibilité, ainsi que ses obligations envers la Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario.
  2. Mentionner certaines spécifications (voir la page Détermination des spécifications pour plus d’information à ce sujet). L’organisme G3ICT recommande (lien uniquement en anglais) d’inclure des renseignements détaillés sur le produit ou le service recherché, notamment les exigences en matière d’accessibilité et les modalités de l’approvisionnement.
  3. Préciser que les propositions doivent démontrer l’accessibilité dans leur processus de conception et de développement s’il s’agit d’un nouveau produit.
  4. Préciser aux fournisseurs comment démontrer la conformité de leurs produits en matière d’accessibilité (p. ex. VPAT/RCA). Cela peut comprendre les attentes relatives à la documentation (voir la section sur l’évaluation ci-dessous), une mise à l’essai, des scénarios relatifs à l’utilisateur type et des plans pour combler les lacunes connues. Voir le site Section508.gov pour obtenir un modèle de ce type de directives à l’intention des fournisseurs (lien uniquement en anglais). Demander des VPAT a également l’avantage indirect de communiquer l’importance de l’accessibilité aux fournisseurs.
  5. Demander des références précises au sujet de l’accessibilité du produit aux fournisseurs.
  6. Préciser si ces spécifications sont des critères d’acceptation minimaux et de quelle manière ils seront évalués par rapport aux autres facteurs.

Interprétation des affirmations des fournisseurs

VPAT et RCA 

Sans confirmation écrite ni validation, les affirmations des fournisseurs relatives à l’accessibilité ne peuvent être acceptées sans réserve. Les rapports de conformité en matière d’accessibilité (RCA) sont une méthode communément acceptée pour déclarer l’accessibilité d’un produit. On les appelle également modèles volontaires d’accessibilité des produits (VPAT). Un VPAT est un modèle générique utilisé par les entreprises pour rédiger des rapports sur l’accessibilité de leur produit en fonction des normes de la Section 508 (États-Unis) ou de la norme EN 201 549 (Europe).

Pour la majorité des produits disponibles sur le marché, on peut trouver les VPAT en ligne. La majorité des grands fournisseurs, dont les clients sont notamment des établissements d’enseignement postsecondaire aux États-Unis ou en Europe, auront déjà rempli des VPAT qu’ils pourront présenter.

Il est important de noter qu’un VPAT n’est pas un rapport de vérification, même si le fournisseur doit avoir réalisé une vérification pour le remplir. Malgré leur utilité, il ne faut pas présumer de l’exactitude d’un VPAT. Les VPAT peuvent exagérer l’accessibilité d’un produit donné puisqu’ils sont rédigés par le fournisseur.

Texte alternatif : Extrait d’un document commenté intitulé : Zoom Video Accessibility Conformance Report International Edition. Les commentaires expliquent que : « Les VPAT se nomment également RCA, ou rapports de conformité d’accessibilité » et « S’agit-il de la bonne version? La version internationale est fondée sur la norme EN 301 549. Les autres sont fondées sur les normes des États-Unis. Sous-titre : VPAT = Version 2.3 - Décembre 2018 Commentaire : « Ont-ils utilisé la version la plus récente du modèle? » Contenu : Nom du produit Version : Zoom Video Conferencing and Webinar v4 6.0 (Windows) Description du produit : L’ensemble de produits de communication par vidéo de Zoom fonctionne sur les appareils mobiles, les ordinateurs et les systèmes de salle de conférence. La plateforme Zoom réunit la conférence vidéo et audio, les petites réunions en ligne, la messagerie de groupe et une solution logicielle de salle de conférence en une seule plateforme conviviale simple à déployer. Date : 14 octobre 2019. Commentaire : À quelle date le rapport a-t-il été rempli? Y a-t-il eu des mises à jour depuis?

Drapeaux rouges

Les éléments suivants sont préoccupants ou indiquent qu’un VPAT n’est peut-être pas exact :

  • Une ancienne version d’un VPAT (VPAT 1.X) indique que le fournisseur n’a pas mis à jour ses documents.  De manière similaire, un VPAT rempli il y a plus de 12 mois suggère que le produit n’a pas été mis à jour.
  • Le VPAT n’est pas rempli ou est rempli avec un langage non normalisé (p. ex. il utilise les termes « Réussite » et « Échec » au lieu de « Respecte », « Respecte partiellement » ou « Ne respecte pas »). Ceci indique que la personne qui l’a rédigé manque d’expertise en matière d’accessibilité.
  • Il y a un VPAT pour plusieurs produits et des descriptions inexactes/floues du produit. Un VPAT doit être spécifique au produit pour être exact.
  • Les méthodes d’évaluation ne sont pas mentionnées ou montrent que seuls des essais automatisés ont été réalisés.  Les essais automatisés peuvent seulement mettre à l’essai environ 30 % de la conformité. Il ne faut pas se fier uniquement à ce type d’essai.
  • Le VPAT énonce qu’il « Respecte » toutes les spécifications en matière d’accessibilité. Bien que cela soit possible, il est extrêmement rare qu’un produit respecte tous les critères. Cela indique parfois que la personne qui a rédigé le VPAT ne comprenait pas la conformité ou ne l’a pas confirmée. Il est à noter que dans les VPAT, certains fournisseurs peuvent indiquer « Respecte » au lieu de « Sans objet » lorsqu’un critère n’est pas pertinent.
  • Les VPAT qui indiquent constamment « Respecte » et incluent peu de contenu dans la colonne « Remarques ». La colonne Remarques ne doit pas rester vide. Elle doit expliquer de quelle manière la personne qui a rédigé le VPAT en est arrivée à cette conclusion.  Si la majorité des réponses du VPAT paraphrasent le critère, il faut se demander de quelle manière la personne en est arrivée à ces conclusions.
  • La personne qui rédige le VPAT peut également indiquer « Sans objet » à de nombreux critères. Bien que cela puisse être une réponse pertinente, cette mention doit être accompagnée d’une courte explication. Les réponses « Sans objet » sans explication sont suspectes puisqu’il devient alors difficile de déterminer la raison pour laquelle le critère ne s’applique pas.

En cas de drapeaux rouges

Si vous voyez n’importe lequel de ces drapeaux rouges lors de l’examen d’un VPAT, vous pouvez faire quelques contrôles rapides pour confirmer l’exactitude des affirmations. Ces contrôles ne remplacent pas une vérification complète de l’accessibilité, mais peuvent permettre de valider certaines des affirmations d’un VPAT. Vous pouvez par exemple effectuer les contrôles suivants, puis vérifier que les résultats sont décrits avec exactitude dans le VPAT :

  • Tester le produit à l’aide d’un clavier (voir le point 4.5.2 si vous ne savez pas très bien en quoi cela consiste)
    • les éléments sont-ils tous fonctionnels à partir du clavier?
    • les éléments actifs ont-ils un indicateur clairement visible?
    • est-il possible d’activer le contenu caché comme les menus?
    • est-il possible de remplir et de soumettre des formulaires?
  • Y a-t-il du mouvement sur le site? Dispose-t-il d’une fonction de pause accessible (souris, clavier, élément tactile), ou s’arrête-t-il en moins de 5 secondes?
  • Si vous remplissez un formulaire vide ou inexact (p. ex. une connexion), les erreurs sont-elles bien décrites?

Si les résultats ne correspondent pas au VPAT, ce dernier n’est pas fiable. Dans ce cas, il est impossible de savoir si le produit est accessible sans le mettre à l’essai vous-même.

Si vous avez des questions suite à votre lecture du VPAT, communiquez avec le fournisseur. Vous pourriez lui poser des questions comme :

  • Pourquoi ce VPAT date-t-il de 18 mois? Le produit n’a-t-il pas été mis à jour?
  • Pourquoi ce critère mentionne-t-il « Sans objet » alors que le produit dispose de cette fonction?
  • Quels essais ont été réalisés pour obtenir ces résultats?

Signes d’un VPAT fiable

Voici maintenant des indications de fiabilité d’un VPAT :

  • Il a été rédigé par une tierce personne possédant une grande expertise en matière de critères d’accessibilité et ayant probablement un point de vue objectif.
  • La page de couverture du VPAT est bien remplie, elle présente notamment des renseignements détaillés sur le type exact d’essai utilisé. Par exemple, l’énumération de nombreuses technologies d’aide et de différents types de tests confirme la rigueur de la mise à l’essai. De manière similaire, une remarque au sujet de la portée de la mise à l’essai est rassurante.
  • Des exemples de la manière dont le produit répond à un critère de réussite en particulier démontrent une compréhension des critères de réussite.
  • Le VPAT est du domaine public, ce qui démontre une confiance du fournisseur envers le rapport.
Extrait d’un VPAT sans titre. Composé de colonnes Critères, Niveau de conformité, Commentaires et Explications. Première rangée : Contenu : 1.1.1 Contenu sans texte (niveau A). Niveau de conformité : Respecte. Commentaires et explications : Le produit fournit du texte alternatif pour le contenu sans texte comme les boutons et les graphiques. Des étiquettes de programmation permettent aux utilisateurs.trices de technologies d’aide à déchiffrer la nature et l’objectif du contenu sans texte.

Évaluation et non-conformité

L’assistant pour les exigences d’accessibilité des TIC du gouvernement du Canada produit des modèles d’évaluation correspondant aux spécifications qu’il crée. Pour chaque processus d’approvisionnement, vous devez déterminer les spécifications en matière d’accessibilité qui représentent des exigences minimales, et les critères à évaluer et à noter ainsi que d’autres exigences. Les obligations légales pertinentes sont un élément à prendre en compte pour déterminer les spécifications. La qualité des produits de rechange est également un facteur à considérer. Si un établissement d’enseignement postsecondaire trouve à la fois des produits accessibles et des produits « inaccessibles » qui répondent à ses besoins, il peut accorder la priorité aux produits accessibles. Pour les produits qui concernent de nombreuses personnes ou de nature plus critique, vous pouvez considérer fixer des attentes plus élevées en matière d’accessibilité.  

Il peut vous arriver parfois de conclure que la meilleure solution est d’acheter un produit qui ne respecte pas complètement les spécifications en matière d’accessibilité. La Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario énonce que si « une organisation désignée du secteur public détermine qu’il n’est pas matériellement possible de prendre en compte la conception axée sur l’accessibilité et les critères et options d’accessibilité lors de l’obtention ou de l’acquisition de biens, de services ou d’installations, [elle] en fournit une explication sur demande ». Dans de telles situations, il est alors préférable de documenter la décision afin d’expliquer la raison pour laquelle une solution accessible n’a pu être achetée et d’élaborer un plan d’action correctif si possible.

Une autre pratique exemplaire à considérer lorsque le produit choisi n’est pas complètement accessible est d’élaborer un plan pour contourner les problèmes d’accessibilité. Cette solution de rechange est parfois appelée mesure d’adaptation ou « plan d’action de rechange tout aussi efficace. ». Ces solutions sont essentielles pour garantir l’accès des personnes en situation de handicap aux renseignements ou aux ressources nécessaires.

Une organisation peut faire preuve de proactivité en mettant en place un plan de rechange tout aussi efficace pour contourner certains problèmes connus, ou de réactivité en répondant à des demandes distinctes. Un plan d’accès de rechange tout aussi efficace est présenté ci-dessous au sujet des problèmes connus de Zoom.

Extrait du document intitulé : Table 1. Zoom features and actions to enhance meeting accessibility. Première rangée Fonction : Description du clavier. Description/Ressource À faire : Partager le lien vers les raccourcis clavier de Zoom et vers le Centre d’aide lors de l’envoi d’une invitation à une réunion Zoom ou lorsque demandé. Deuxième rangée : Fonctions : Partage du contenu à l’écran. Description/Ressources/À faire : Intégrer une description du contenu dans la présentation orale. Fournir d’autres moyens d’accéder au contenu et aux URL partagés à l’écran, comme la publication d’une présentation accessible après la séance.

Capture d’écran du site anglophone https://dssbackyardfence.wordpress.com/

Le site UDL (Universal Design for Learning in Higher Education) on Campus dispose de ressources sur l’élaboration d’un plan d’action de rechange tout aussi efficace (en anglais). Comme ce sont des ressources américaines, elles présentent de l’information adaptées aux normes des États-Unis et non aux normes canadiennes ou européennes.

Libellé des contrats

Une fois le produit et le fournisseur choisis, le contrat présentera les différentes spécifications en matière d’accessibilité, notamment les modalités de mise à l’essai et de validation du produit, et l’approche en cas de non-conformités. Voici une liste des éléments à vérifier lorsque vous finalisez les détails du contrat :

  • énoncer la norme pertinente en matière d’accessibilité (p. ex. WCAG 2.1 niveau AA)
  • définir le processus pour le traitement des exceptions relatives aux normes et aux spécifications
  • s’entendre sur les procédures de mise en service et de soutien afin de s’assurer que l’équipe de soutien dédiée du fournisseur traite l’accessibilité
  • inclure toute l’information pertinente au sujet de la mise à l’essai et de la livraison
  • indiquer que le fournisseur est responsable de tout manque d’accessibilité du produit en exigeant qu’il corrige les obstacles, livre un nouveau produit, rembourse les montants versés ou paie des dommages
  • inclure une disposition permettant de demander au fournisseur et aux utilisateurs.trices de donner leur avis sur le produit
  • préciser que la correction des problèmes d’accessibilité relève de la responsabilité du fournisseur, peu importe le moment où ils sont détectés puisqu’ils ne sont pas toujours immédiatement visibles

Pour obtenir de l’information supplémentaire, consultez la ressource 9 Steps to Procuring Accessible ICTs for Inclusive Education de l’organisme Global Initiative for Inclusive ICTs (G3ICT) (en anglais seulement).

Le site Section508.gov (la ressource en matière de législation sur l’accessibilité aux États-Unis) propose des modèles de libellés de contrat (en anglais seulement) pour différentes situations :

  • services de développement personnalisé des technologies de l’information et des communications (TIC)
  • services d’installation, de configuration et d’intégration
  • entretien, mises à niveau et remplacements
  • personnel de service
  • services d’hébergement
  • validation des éléments des TIC
  • documentation
  • production de rapports sur la conformité
  • non-conformité 

Puisqu’ils font référence aux exigences de la Section 508, vous devrez adapter ces libellés pour qu’ils correspondent aux normes de votre collège ou université en matière d’accessibilité.

IV

Mise à l’essai

Qu’elle ait été développée ou achetée, la technologie doit être mise à l’essai pour déterminer si elle est accessible ou non. La présente section indique à quel moment et de quelle façon la technologie doit être mise à l’essai et donne un aperçu du processus de mise à l’essai et de certains outils courants à inclure dans ce processus.

La présente section traite des thèmes suivants :

 

11

Établissement des critères de réussite pour les sites Web

Afin d’améliorer l’accessibilité de votre contenu Web, vous pouvez viser l’application des Règles pour l’accessibilité des contenus Web (WCAG). Voir la page Normes internationales pour obtenir davantage d’information.

Différences entre les WCAG 2.0 et les WCAG 2.1

Le World Wide Web Consortium (W3C) et l’Initiative d’Accès au Web (WAI) sont chargés de la création, de l’entretien et des mises à jour des WCAG. Les WCAG sont régulièrement mises à jour afin de refléter le processus continu d’amélioration de l’accessibilité et de répercuter les avancements technologiques et du développement de contenu Web. Chaque mise à jour est numérotée à l’aide de deux chiffres séparés d’un point. Le premier chiffre représente le numéro de version principale, alors que le second représente le numéro de version mineure.

La Loi de 2005 sur l’accessibilité pour les personnes handicapées de l’Ontario exige seulement l’application des WCAG 2.0 pour le moment. En raison des versions des WCAG actuellement publiées et de l’utilisation généralisée de la technologie tactile, il vaut mieux viser l’application des WCAG 2.1. Votre site Web est alors prêt pour la suite, et les WCAG 2.1 offrent des critères de réussite relatifs aux écrans tactiles. Il faut garder en tête que les WCAG 2.2 et WCAG 3.0 sont en cours de rédaction et seront bientôt publiés.

Niveaux A, AA et AAA

Il existe un certain nombre de critères de réussite dans les WCAG. Chaque critère de réussite correspond à un aspect précis de l’accessibilité numérique. Les WCAG présentent trois niveaux d’accessibilité en fonction du nombre de critères de réussite respectés par un site Web. Lorsqu’une page Web satisfait les critères de réussite, on dit qu’elle respecte les critères (et non qu’elle est conforme aux critères).

Les trois niveaux d’accessibilité, du plus faible au plus élevé, sont le niveau A, le niveau AA et le niveau AAA. Le niveau A fait référence à une accessibilité de base. Le niveau AA est considéré comme une très bonne accessibilité, alors que le niveau AAA représente une excellente accessibilité. La majorité des organisations visent le niveau AA puisqu’il est parfois impossible de respecter tous les critères de réussite du niveau AAA. Même si votre contenu doit seulement respecter le niveau AA, c’est une bonne habitude de documenter les fonctionnalités qui respectent le niveau AAA.

Le tableau 1 ci-dessous montre le nombre de critères de réussite à respecter pour atteindre les différents niveaux d’accessibilité associés aux WCAG 2.0 et 2.1.

Niveau A Niveau AA Niveau AAA
WCAG 2.0 25 critères de réussite 13 critères de réussite 23 critères de réussite
WCAG 2.1 30 critères de réussite 20 critères de réussite 28 critères de réussite
Tableau 1 : Exigences des WCAG 2.0 et 2.1
  • Pour qu’une page Web atteigne le niveau A, elle doit respecter tous les critères de réussite du niveau A.
  • Pour qu’une page Web atteigne le niveau AA, elle doit respecter tous les critères de réussite du niveau A ainsi que tous les critères de réussite du niveau AA.
  • Pour qu’une page Web atteigne le niveau AAA, elle doit respecter tous les critères de réussite du niveau A, tous les critères de réussite du niveau AA ainsi que tous les critères de réussite du niveau AAA.

 

Critères de réussite

Les critères de réussite sont rédigés en langage clair et sont conçus pour être mis à l’essai. Cela signifie qu’il est facile de déterminer si un contenu Web respecte, ou non, un critère précis. Par exemple, le Critère de réussite 1.1.1 énonce que « tout contenu non textuel présenté à l’utilisateur a un équivalent textuel qui remplit une fonction équivalente sauf dans [certaines situations] ». À partir de cet énoncé, une personne peut examiner tout le contenu non textuel et confirmer si le critère est respecté ou non.

Habituellement, la mise à l’essai se fait à l’aide d’une combinaison d’essais automatisés et d’évaluations par un humain (davantage d’information sur la mise à l’essai se trouve sur la page). La mise à l’essai officielle est également parfois accompagnée d’essais de convivialité, où des personnes en situation de handicap interagissent avec le contenu Web et formulent directement des commentaires sur ce qui fonctionne ou non pour eux. Habituellement, la mise à l’essai se fait à l’aide d’une combinaison d’essais automatisés et d’évaluation par un humain. Consultez la page Méthodes de mise à l’essai pour obtenir davantage d’information. La mise à l’essai officielle est également parfois accompagnée d’essais de convivialité, où des personnes en situation de handicap interagissent avec le contenu Web et formulent directement des commentaires sur ce qui fonctionne ou non pour eux.

Tous les critères de réussite se trouvent dans le Guide de référence rapide des WCAG (en anglais seulement).

Techniques et échecs

Pour chaque critère de réussite, les WCAG fournissent des informations supplémentaires, notamment des techniques suffisantes et recommandées ainsi que des exemples d’échecs. Ces informations supplémentaires vous aideront à respecter les critères de réussite :

  • Les techniques suffisantes sont des moyens fiables de respecter le critère de réussite. D’autres techniques non présentées peuvent être utilisées, si elles fonctionnent. Consulter : Techniques suffisantes (en anglais seulement).
  • Les techniques recommandées sont des moyens suggérés pour améliorer l’accessibilité, mais elles ne sont pas obligatoires. Consulter : Techniques recommandées (en anglais seulement).
  • Les échecs sont les résultats d’un essai. Ils démontrent le non-respect du critère de réussite. Consulter : Échecs (en anglais seulement).

Davantage de détails sont présentés sur la page Comprendre les techniques pour les critères de réussite des WCAG (en anglais seulement).

Différence entre normatif et informatif

Il faut garder en tête que les techniques suffisantes et recommandées sont fournies à titre d’information supplémentaire pour vous aider à respecter les critères. Comme il est décrit dans les WCAG, les techniques sont présentées à titre informatif, ce qui signifie que vous n’avez pas à utiliser une technique en particulier, tant que la technique utilisée fonctionne.

Par contre, tous les critères de réussite sont normatifs, ce qui signifie que vos pages Web doivent les satisfaire afin de respecter les WCAG.

Ressources :  Respecter les WCAG (Référence rapide, en anglais seulement)

12

Quand effectuer une mise à l’essai

Une bonne accessibilité n’arrive pas par hasard. Il est essentiel de tenir compte de l’accessibilité dès les premières étapes du développement ou de la refonte d’un site Web ou d’une application Web. Il faut en évaluer l’accessibilité dès le début ainsi que tout au long du processus. Plus vous cernez les problèmes d’accessibilité rapidement, plus il est facile et moins coûteux de les régler.

Pour emprunter une expression populaire dans le développement de logiciels modernes : « décalez vers la gauche ». Cela signifie qu’il est préférable de réaliser des essais tôt dans le processus pour régler les problèmes à peu de frais. Vous gagnerez aussi du temps plus loin dans le processus puisque vous n’aurez pas à mettre à nouveau à l’essai des fonctions similaires.

Développement de contenu

Lors de la création de nouveau contenu ou d’une nouvelle page Web, l’accessibilité doit être évaluée aussi tôt que possible en examinant les éléments de la page et en observant le code dans les outils de développement du navigateur. Parfois, les responsables du développement utilisent également des outils de test automatisé, comme l’outil Axe de Deque, afin d’augmenter la fréquence des mises à l’essai. L’utilisation de certaines technologies connues, comme des lecteurs d’écran (NVDA pour Windows ou VoiceOver pour les produits Apple) est aussi recommandée pour évaluer l’accessibilité.

Mises à jour du contenu

Tout comme vous le faites pour du nouveau contenu, il est important d’évaluer l’accessibilité du contenu que vous mettez à jour avant de le publier. Pour ce faire, vous pouvez utiliser la fonction de prévisualisation offerte dans la plupart des systèmes de gestion du contenu. Dans certains cas, vous pouvez travailler avec la personne responsable du développement pour mettre à l’essai vos mises à jour rapidement. Il est toujours préférable d’examiner le contenu et d’assurer son accessibilité avant de le publier sur votre site public.

Surveillance continue du site

Pour les sites Web déjà publiés, il existe plusieurs outils de tableau de bord qui permettent de surveiller le site en continu pour déceler les problèmes d’accessibilité. Ceux-ci sont particulièrement utiles pour les grandes organisations possédant des sites Web de grande envergure. Ces outils sont habituellement payants. Parmi les outils principaux de ce type dans l’industrie, il y a :

  • Deque – axe Monitor (un outil différent de l’extension de navigateur gratuit nommé Axe de Deque pour la mise à l’essai)
  • TPGi – ARC Domain Monitoring
  • Level Access – AMP (plateforme de gestion de l’accessibilité)

 

Ressources : Évaluer l’accessibilité Web – Vue d’ensemble

13

Méthodes de mise à l’essai

La méthode la plus rigoureuse et exhaustive pour évaluer l’accessibilité d’un site Web est de réaliser une vérification complète en parcourant l’intégralité du site pour déceler et résoudre les problèmes d’accessibilité. Toutefois, il n’est pas toujours possible de vérifier l’intégralité d’un site en une seule fois. Lorsqu’une vérification complète est impossible, des vérifications prioritaires rapides et la résolution précoce de bogues sont des moyens utiles pour réduire les erreurs relevées lors des vérifications suivantes. 

Vérifications rapides

Pour établir la priorité des contenus à évaluer, vous pouvez vous concentrer sur les fonctions ou les pages pour lesquelles vous avez reçu de la rétroaction. Vous pouvez alors rapidement mettre à l’essai une page ou un flux de travail se rapportant aux fonctions abordées dans la rétroaction des utilisateur.trice.s.

Si vous décelez des problèmes sur une page ou dans une fonction, tentez de déterminer si des problèmes similaires surviennent dans les pages connexes de votre site. Une fois que vous aurez cerné et réglé un problème, peut-être gagnerez-vous du temps lors de la résolution de problèmes similaires.

Différences entre les vérifications internes et les vérifications par des tiers

Lorsqu’une vérification complète est réalisable, celle-ci peut être effectuée par du personnel à l’interne ou par un tiers.

Vérifications internes

La vérification de votre propre site (ou l’aide apportée au personnel de TI interne lors d’une vérification) exige un certain niveau de connaissances de l’accessibilité numérique et de la mise à l’essai en matière d’accessibilité, ainsi que suffisamment de ressources humaines pour réaliser la vérification. Effectuer cette vérification à l’interne peut présenter d’autres avantages, comme celui de permettre au personnel de mieux connaître votre site. Comme pour les vérifications rapides, une fois que vous avez décelé un problème, vous pouvez examiner le contenu connexe ou les pages dont la structure similaire pourrait présenter le même obstacle. Chercher des schémas ou problèmes qui se répètent, et les résoudre peut mener à des solutions communes.

Vérifications par des tiers

Une autre option qui comporte aussi ses avantages est de demander à un cabinet d’experts-conseils en accessibilité de réaliser la vérification. Les responsables de la vérification sont bien au fait des tendances Web, des techniques de mise à l’essai et des conseils de codage pour votre équipe.

Il est important d’adopter une approche stratégique et de définir précisément la portée du travail, surtout lorsque les vérifications sont réalisées à l’externe. Vous pouvez vous servir du trafic sur votre site pour établir la priorité du travail. Les pages les plus consultées seront donc mises à l’essai en premier. Une manière d’organiser le travail est de définir une série de sprints : de courts délais (habituellement quelques semaines) pendant lesquels un nombre établi de pages sont mises à l’essai et pour lesquelles des rapports d’observation sont produits. La mise à l’essai de votre site par sections vous donne alors le temps de régler les problèmes communs entre les sprints. Par exemple, vous pourriez définir quatre lots de pages à mettre à l’essai, soit quatre sprints. Une fois le premier lot mis à l’essai, un rapport de vérification vous est remis et votre personnel de TI a alors de temps de régler les problèmes. Puis, lorsque la mise à l’essai commence pour le deuxième sprint, il devrait y avoir moins de problèmes, puisque bon nombre d’entre eux devraient déjà avoir été réglés.

Essais de convivialité

Une autre option est de recruter (et préférablement de payer) des personnes en situation de handicap pour mettre votre site à l’essai. Elles vous donneront de la rétroaction en fonction de leur expérience, qui sera différente pour chacune d’entre elles. Pensez à un large éventail de personnes vivant avec des handicaps différents, par exemple des personnes :

  • aveugles
  • daltoniennes ou malvoyantes
  • ayant des problèmes de dextérité
  • présentant des troubles cognitifs, comme le TDAH (trouble déficitaire de l’attention avec hyperactivité) ou TSA (trouble du spectre de l’autisme)

Si vous optez pour cette approche, vous devez vous rappeler que chaque personne en situation de handicap a une expérience unique. Vous ne devez donc pas vous fier uniquement à la rétroaction des utilisateur.trice.s pour déterminer si votre site est accessible ou non. Les essais de convivialité complètent, mais ne remplacent pas le respect des lignes directrices en matière d’accessibilité.

14

Aperçu du processus de mise à l’essai

Si vous décidez d’évaluer l’accessibilité de votre site Web, vous devez suivre quatre grandes étapes :

  1. planifier les essais
  2. réaliser les essais
  3. compiler les résultats des essais
  4. régler tous les problèmes relevés

Le reste de cette page présente quelques conseils sur la planification du processus de mise à l’essai et la réalisation des essais en tant que tels.

Conseils de planification

Planifier le processus de mise à l’essai peut permettre d’en optimiser l’efficacité et le déroulement. Pour ce faire, tenez compte des éléments suivants :

  • Gardez bien en tête les objectifs que vous souhaitez atteindre. Par exemple, avant de commencer la mise à l’essai, vous pourriez consulter les critères de réussite des WCAG (site en anglais seulement) ainsi que le site WAI-ARIA sur les pratiques de rédaction (également en anglais seulement) pour vous renseigner sur les éléments comme les accordéons ou les menus. Une liste de vérification ou une feuille de travail peuvent également être utiles. Cliquez ici pour télécharger un modèle de vérification des WCAG 2.1 (en format Excel) (en anglais seulement).
  • Comprenez les priorités des utilisateur.trice.s de votre site Web. Certaines pages et certains flux de travail précis (comme l’inscription à un cours ou la vérification d’une note) sont utilisés plus fréquemment et devraient donc être vérifiés en priorité. Vous pouvez discuter de l’établissement de ces priorités avec les parties prenantes ou les utilisateurs.trices ou consulter les données et les analyses du site.
  • Définissez les modules à mettre à l’essai, chaque module requérant environ le même niveau d’effort. Habituellement, une page équivaut à un module. Il est conseillé de traiter les éléments complexes ou les widgets à part. Par exemple, si votre page comporte du texte statique, une barre de recherche et un calendrier, vous pouvez définir ces trois éléments comme trois modules distincts.
  • Organisez la mise à l’essai en sprints, chaque sprint traitant d’un ensemble précis de modules.
  • Réservez du temps pour régler les problèmes entre chaque sprint.
  • Déterminez si vous avez besoin de comptes de test ou de données uniques afin d’évaluer des fonctions précises. Par exemple, vous aurez peut-être besoin du compte d’une étudiante ou d’un étudiant fictif ainsi que de notes et de cours fictifs pour mettre une fonction précise à l’essai.
  • Trouvez des personnes qui peuvent effectuer la mise à l’essai. Assurez-vous qu’elles ont l’expertise et le temps nécessaires pour réaliser la mise à l’essai.
  • Établissez des communications claires avec le personnel de TI et le personnel responsable du contenu, et développez des flux de travail pour résoudre les problèmes décelés.

Conseils pour la mise à l’essai

Voici des pratiques exemplaires pour effectuer la mise à l’essai de votre site Web :

  • Utilisez les outils de mise à l’essai appropriés (comme ceux mentionnés dans la section Outils de mise à l’essai). Assurez-vous d’être en mesure de les installer et d’en comprendre le fonctionnement. Ces outils peuvent être utilisés dans l’ordre de votre choix. Voici quelques outils recommandés :
  • Consignez les problèmes dans un système de suivi des bogues, comme Jira ou dans une feuille de travail. Décrivez les comportements non souhaitables et, si possible, précisez la correction à apporter. Les captures d’écran de l’erreur sont utiles.
  • Précisez le critère de réussite des WCAG correspondant aux problèmes relevés, le cas échéant.
  • Communiquez les bogues aux fournisseurs tiers si vous n’avez pas les accès nécessaires pour corriger l’erreur.
  • Collaborez, lorsque possible, avec le personnel de TI et le personnel responsable du contenu pour corriger rapidement tout problème. Faites une liste des problèmes que vous ne pouvez pas prioriser.
  • Mettez à l’essai les correctifs et réalisez des tests de régression pour veiller à ce que le site et ses caractéristiques fonctionnent toujours comme prévu.

Ressources :

Consignation des résultats des essais

Une pratique exemplaire consiste à consigner les résultats de tout essai d’accessibilité réalisé. Vous pourrez alors plus facilement communiquer vos résultats aux parties prenantes ou à la direction de l’organisation, et prioriser et mettre en place les correctifs requis.

Information importante

Pour chaque problème, indiquez, si vous le pouvez, les éléments suivants :

  • Une courte description du problème pour assurer la facilité du suivi.
  • Une description plus longue du problème indiquant la raison du non-respect d’un critère de réussite des WCAG en particulier, expliquant l’incidence du problème relevé sur les personnes présentant un certain handicap, ou précisant pourquoi il va à l’encontre d’une norme organisationnelle.
  • La gravité du problème pour en décrire l’incidence sur l’utilisateur.trice.
  • Les étapes pour trouver, recréer et mettre à l’essai le problème (p. ex. un hyperlien ou un identifiant).
  • Le code HTML actuel (qui cause le problème).
  • Le code HTML recommandé (pour régler le problème). Si le problème concerne un élément complexe (comme un ensemble d’onglets, un méga menu ou un carrousel), il peut être préférable de se référer à un modèle accessible existant, comme ceux du site ARIA sur les pratiques de rédaction (lien uniquement en anglais), au lieu de développer un code HTML recommandé.
  • Si possible, une capture d’écran mettant le problème en évidence à l’aide d’un cadre ou d’une flèche.

Rédaction d’un rapport d’essais

Le format d’un rapport d’essais varie en fonction du public, par exemple :

  • Les cadres supérieurs préfèrent peut-être un résumé de haut niveau qui donne un certain aperçu des défis en matière d’accessibilité pour les utilisateurs.trices ainsi que des obligations légales.
  • Les gestionnaires veulent peut-être un aperçu des résultats, comme un tableau de bord qui présente les cinq principaux problèmes, ou les problèmes regroupés en catégories.
  • Les responsables du développement souhaitent peut-être que vous leur présentiez les correctifs à apporter au code ou des liens vers des modèles d’accessibilité pour résoudre les problèmes. Ces personnes veulent parfois une feuille de travail (comme celle-ci; uniquement en anglais) ou un autre format facile à importer dans leur logiciel de suivi des bogues.

Modèles

Il existe plusieurs formats pour créer un rapport d’essais.

  • Si vous utilisez un logiciel d’entreprise qui évalue votre site, vérifiez s’il présente une fonction d’exportation de rapport.
  • Vous pouvez aussi créer un modèle de rapport en vous appuyant sur les conseils ci-dessus ou sur un rapport précédent.
  • Le site du W3C (World Wide Web Consortium) offre un modèle de rapports d’évaluation de l’accessibilité Web (uniquement en anglais). Ce modèle comporte des renseignements clés comme la portée de l’examen, les responsables de l’examen, le processus d’examen, les résultats et les mesures recommandées.

En fin de compte, le rapport doit répondre à vos besoins et aux besoins de votre public. Voyez qui utilisera ces renseignements et vous saurez si vous devez créer plusieurs modèles adaptés aux différents publics.

Priorité et gravité

Il est parfois impossible de régler tous les problèmes immédiatement, de mettre à l’essai les correctifs, puis de les mettre en œuvre. Pour cette raison, définissez la gravité et la priorité de chaque problème pour déterminer l’ordre selon lequel ils seront réglés. 

Gravité

L’expert.e-conseil en accessibilité, ou la personne responsable des essais, doit définir la gravité de problème. La gravité précise l’incidence du problème sur les utilisateurs.trices.

Voici un exemple d’échelle de gravité :

  • G-1 Critique – Les personnes présentant certains handicaps ne peuvent utiliser aucun élément du système ou du site Web. Un correctif immédiat est nécessaire.
  • G-2 Élevé – Les personnes présentant certains handicaps trouveront l’utilisation du système ou du site Web difficile. Certains résultats inexacts relevés peuvent avoir de grandes répercussions sur le bon fonctionnement du site Web. Un correctif immédiat est fortement recommandé.
  • G-3 Moyen – Les personnes peuvent utiliser le site, mais certaines fonctionnalités sont limitées. Elles peuvent avoir du mal à utiliser une fonction ou un flux de travail en particulier, mais il est facile de contourner le problème.
  • G-4 Faible – Un problème mineur qui n’affecte pas le fonctionnement ou la convivialité du système. Il peut s’agir de quelques problèmes mineurs de convivialité ou d’écarts fonctionnels qu’il est possible d’éviter.

Priorité

La priorité doit être définie en fonction de la gravité. C’est le ou la responsable du produit ou le ou la gestionnaire du site Web qui l’établit. Contrairement à la gravité, qui décrit le problème de manière isolée, l’établissement de la priorité tient également compte du contexte de tous les problèmes et de la rapidité de leur résolution. Par exemple, il pourrait y avoir plus de problèmes G-1 Critiques à résoudre que ce qui peut être raisonnablement corrigé dans un délai déterminé (p. ex. un sprint). Le ou la responsable du produit pourrait accorder la priorité à certains problèmes G-1 Critiques au lieu d’autres problèmes selon la capacité des TI et les commentaires de la direction.

Voici un exemple d’échelle de priorité semblable à l’échelle de gravité précédente :

  • P-1 Critique
  • P-2 Élevée
  • P-3 Moyenne
  • P-4 Faible

Faites preuve de jugement

En fin de compte, vous devez faire preuve de jugement pour définir la gravité et de la priorité de chaque problème en fonction des répercussions sur les utilisateurs.trices et de l’importance de chaque fonctionnalité.

15

Outils de mise à l’essai

Il existe une panoplie d’outils disponibles pour mettre à l’essai l’accessibilité de votre page Web ou d’autres types de contenu (p. ex. documents, diapositives PowerPoint). Les pages suivantes décriront ces outils et la manière de les utiliser pour évaluer l’accessibilité de vos contenus. Certains outils (clavier, vérificateur de contraste des couleurs et lecteur d’écran) sont adaptés à tous les types d’examens de l’accessibilité. D’autres outils sont spécifiques à une technologie, comme les vérificateurs de document, les vérificateurs de navigateur Web et Accessibility Insights de Microsoft (pour vérifier les applications de Windows). 

Page d’essai

Le World Wide Web Consortium (W3C) offre une page d’essai (uniquement en anglais) permettant de vérifier plusieurs types de problèmes. Il s’agit donc d’un excellent terrain de jeux pour mettre à l’essai tous les outils ci-dessus dans le cadre de l’évaluation de l’accessibilité d’un site Web.

Mise à l’essai à l’aide d’un clavier

L’utilisation d’un clavier est une bonne manière de commencer les essais d’accessibilité. C’est un outil que vous avez déjà sous la main et que vous connaissez bien. Certaines personnes en situation de handicap utilisent uniquement leur clavier et ne se servent pas du tout de la souris. Par conséquent, toutes les fonctions de la page Web doivent être accessibles à l’aide du clavier. Cela signifie qu’il n’est pas nécessaire d’avoir une souris pour naviguer sur votre page Web.

 

Mains sur un clavier

Commandes clavier

Tous les navigateurs Internet comportent les commandes clavier suivantes :

  • la touche de tabulation sélectionne le prochain élément cliquable (lien ou commande de formulaire), alors que les touches Maj+TAB sélectionnent l’élément précédent
  • lorsqu’un lien est sélectionné, la touche Entrée permet de l’ouvrir
  • lorsqu’un bouton est sélectionné, la touche Entrée ou Espace permet de l’activer
  • lorsqu’une case à cocher ou une case d’option est sélectionnée, les touches fléchées Haut/Bas ou Gauche/Droite sélectionnent tour à tour chacun des éléments du groupe

Différences entre l’état de survol et l’état de focus

Pour indiquer l’emplacement d’un utilisateur.trice sur une page Web, vous pouvez utiliser des indicateurs visuels que l’on appelle : « état de survol» pour la navigation à l’aide de la souris et « état de focus » pour la navigation à l’aide du clavier.

L’état de survol est une fonction visuelle de mise en évidence qui apparaît sur un élément cliquable lorsqu’une personne place le curseur de sa souris dessus.

L’état de focus est une fonction visuelle de mise en évidence qui apparaît sur un élément cliquable lorsqu’une personne utilise la touche de tabulation pour aller jusqu’à cet élément (à l’aide de son clavier).

Un état de focus facilement reconnaissable et visible permet aux personnes voyantes qui utilisent uniquement un clavier de naviguer sur la page Web et d’interagir avec celle-ci.

Lorsque les responsables de la conception et du développement personnalisent l’état de focus, ce dernier peut devenir plus difficile à reconnaître. Par conséquent, il est particulièrement important de mettre l’état de focus à l’essai sur tous les éléments cliquables si ceux-ci ont été personnalisés.

Indicateur de focus visible

Dans certains cas, l’état de focus est appelé indicateur de focus. Lorsqu’un lien ou un bouton reçoit le focus (lorsqu’un utilisateur.trice utilise la touche de tabulation pour aller jusqu’à cet élément), un indicateur de focus visible apparaît. Un indicateur de focus visible est toute ligne pointillée, toute mise en évidence ou tout repère visible pour montrer quel élément cliquable fait l’objet du focus et peut être activé.

Exemples d’indicateur de focus visible :

  • une ligne pointillée (ou pleine) autour d’un lien :
Capture d’écran du site de W3C avec un lien mis en évidence
Capture d’écran du site d’eCampus Ontario avec un lien mis en évidence
  • un curseur à l’intérieur d’une zone de texte :
Capture d’écran du site de W3C avec une zone de texte
Capture d’écran du site d’eCampus Ontario avec une zone de texte
  • des éléments de style pour montrer quelle case d’option est sélectionnée :
Capture d’écran de cases d’option avec des éléments de style de base
Capture d’écran de cases d’option avec des éléments de style personnalisés
  • un soulignement ou un autre repère :
Captures d’écran d’une barre de navigation de la BBC. Lors de l’utilisation de la touche de tabulation pour passer d’un lien à un autre, chaque lien étant souligné d’une couleur différente

Indicateurs de focus visible acceptables

Actuellement, les Règles pour l’accessibilité des contenus Web (WCAG) 2.1 exigent seulement qu’un indicateur de focus soit visible (2.4.7 : Visibilité du focus, uniquement en anglais).  Les WCAG 2.2 (en cours de rédaction) fourniront de nouveaux critères de réussite supplémentaires (uniquement en anglais) relatifs à l’apparence d’un indicateur de focus (p. ex. taille, contraste des couleurs). Bien que ces exigences ne soient pas en vigueur, il est préférable de se préparer pour cette amélioration.

La force des indicateurs de focus des navigateurs varie, même si les versions récentes des navigateurs s’améliorent. Dans le tableau ci-dessous, Internet Explorer (IE) de Microsoft possède un indicateur de focus très faible. En comparaison, les autres navigateurs ont des indicateurs de focus robustes : Firefox de Mozilla dispose d’une bordure double, alors que Chrome de Google et Edge de Microsoft possèdent des bordures foncées.

Comparaison des indicateurs de focus pour IE, Firefox, Chrome et Edge

Cas de mise à l’essai

Lors des essais d’accessibilité par clavier, voici quelques cas de mise à l’essai recommandés :

Étape Essai Réussite Échec
1 Utilisez la touche de tabulation pour naviguer dans la page, puis vérifiez que vous pouvez vous rendre sur tous les éléments cliquables. Vous pouvez vous rendre sur tous les éléments cliquables. Vous ne pouvez pas vous rendre sur certains éléments cliquables.
2 Lors de la navigation à l’aide de la touche de tabulation, tous les éléments cliquables doivent présenter un indicateur de focus visible. Tous les éléments cliquables affichent un indicateur de focus visible. Certains éléments cliquables n’affichent pas d’indicateur de focus visible.
3 Vous devez pouvoir passer d’un élément cliquable à un autre dans un ordre logique (du haut vers le bas, de gauche à droite). Tous les éléments cliquables suivent un ordre logique. Certains éléments cliquables ne suivent pas un ordre logique.
4 Utilisez la touche de tabulation pour aller sur certains liens, puis enfoncer la touche Entrée. Les liens fonctionnent comme si on avait cliqué dessus. Les liens ne fonctionnent pas comme si on avait cliqué dessus.
5 Allez sur une case à cocher ou une case d’option et appuyez sur les touches fléchées Haut/Bas pour passer d’un élément à l’autre. Il est possible d’aller sur tous les éléments du groupe. Il n’est pas possible d’aller sur tous les éléments du groupe.
6 Allez sur un bouton et vous appuyez sur la touche Entrée ou Espace pour effectuer l’action proposée. L’action est effectuée. Rien ne se produit, l’action n’est pas effectuée.
Tableau 1 : Cas recommandés de mise à l’essai de l’accessibilité au moyen d’un clavier

Ressources :

 

Outils de développement de Chrome

Les outils de développement de Chrome sont une fonctionnalité du navigateur Chrome qui permet d’afficher le code HTML de la page ouverte. Ils sont utiles pour repérer les problèmes d’accessibilité, déterminer leurs causes et mettre à l’essai les correctifs.

Comment inspecter un élément de page

Pour consulter le code HTML relatif à un élément précis de la page, il est possible d’utiliser le bouton droit de la souris pour cliquer sur l’élément, puis sélectionner « Inspect » (Inspecter). Voici un champ de recherche à titre d’exemple.

Champ de recherche sur une page Web

Vous pouvez utiliser le bouton droit de la souris sur le champ de recherche… puis de sélectionner « Inspect » (Inspecter).

Cliquer avec le bouton droit de la souris sur le champ de recherche, puis sélectionner « Inspect » (Inspecter).

Les outils de développement ouvrent alors un panneau à côté de la page Web. Celui-ci affiche le code HTML actuel de la page et met en évidence le code précis relatif à l’élément sélectionné à l’aide du bouton droit de la souris.

Les outils de développement affichent le code HTML à côté de la page Web

Comment copier le code

Lorsque vous signalez un problème d’accessibilité, c’est une bonne idée d’indiquer le code de l’élément défectueux. Pour ce faire, cliquer avec le bouton droit de la souris sur la ligne de code, puis sélectionner « Copy » (Copier). Maintenant, coller ce code dans le rapport de vérification.

Copier un élément des outils de développement

Comment modifier le code

Vous pouvez aussi mettre des correctifs de code à l’essai directement dans le navigateur. Il vous suffit de cliquer avec le bouton droit de la souris sur le code en question, de sélectionner « Edit as HTML » (Modifier au format HTML), puis d’apporter les changements souhaités. Une fois le code modifié, vous pouvez mettre l’élément à l’essai à nouveau. Remarque : cette méthode modifie le code seulement de manière temporaire. Les modifications seront effacées si la page est générée de nouveau ou si une autre page est ouverte avant de revenir à la page précédemment modifiée.

Modifier un élément dans les outils de développement

Ressources :  Outils de développement de Chrome

 

Mise à l’essai du contraste des couleurs

Un bon contraste des couleurs dans votre contenu est important pour les personnes présentant une déficience visuelle. C’est ce qui fait qu’elles peuvent voir et interpréter votre contenu (visuel et textuel) ou non.

Contraste des couleurs

Le contraste des couleurs mesure la différence de luminosité entre les couleurs en avant-plan et en arrière-plan, soit habituellement les couleurs du texte et du fond derrière celui-ci.  Les Règles pour l’accessibilité des contenus Web (WCAG) 2.1 au sujet du contraste des couleurs exigent ce qui suit :

  • le texte agrandi doit avoir un rapport de contraste d’au moins 3,0:1 (du texte agrandi est défini comme tout texte de taille : 1,5 em, 18 pt, 24 px, 1,2 em en caractères gras, 14 pt en caractères gras, 19 px en caractères gras, ou plus grand)
  • le texte plus petit doit avoir un rapport de contraste d’au moins 4,5:1
  • les icônes doivent avoir un rapport de contraste d’au moins 3,0:1
  • les logos sont exemptés des règles relatives au contraste des couleurs

Il existe deux outils courants d’évaluation du contraste des couleurs : l’analyseur de contraste des couleurs de TPGi et le sélecteur de couleurs de Chrome.

Analyseur de contraste des couleurs de TPGi

L’analyseur de contraste des couleurs (CCA) de TPGi sert à échantillonner n’importe quelle couleur visible à l’écran. Par conséquent, il peut être utilisé pour mettre à l’essai tout type de contenu numérique, notamment les pages Web, les documents Word, les PDF, etc. Pour l’utiliser, suivez les étapes suivantes :

  1. CCA dispose de deux pipettes, une pour échantillonner les couleurs à l’avant-plan et l’autre, celles en arrière-plan.
L’analyseur de contraste des couleurs dispose de deux pipettes pour sélectionner les couleurs à l’avant-plan et en arrière-plan
  1. Sélectionnez d’abord la première pipette, puis cliquez sur le pixel le plus foncé (possible) dans le texte.
La première pipette sert à échantillonner les couleurs en avant-plan
  1. Sélectionnez la deuxième pipette, puis échantillonnez la couleur en arrière-plan (l’espace blanc dans cet exemple).
La deuxième pipette sert à échantillonner les couleurs en arrière-plan
  1. CCA affichera le rapport de contraste.
Le rapport de contraste est affiché après l’échantillonnage des deux couleurs

Dans cet exemple, le contraste des couleurs a un rapport de 10,4:1 et dépasse largement les exigences minimales du contraste des couleurs établies par les WCAG 2.1.

Sélecteur de couleurs de Chrome

Dans le navigateur de Chrome, le panneau des outils de développement comporte une fonction de « sélecteur de couleurs ». Pour l’utiliser, suivez les étapes suivantes :

  1. Trouvez l’élément (texte ou icône) à mettre à l’essai, cliquez dessus avec le bouton droit de la souris, puis sélectionnez « Inspect » (Inspecter).
  2. Dans le panneau des outils de développement, sélectionnez l’onglet « Elements » (éléments) à moins qu’il ne soit déjà ouvert.
  3. Cliquez sur le carré coloré à côté de la valeur de couleur de l’élément dans le volet « Styles ».
Dans les outils de développement de Chrome, il est possible d’inspecter un élément et de consulter sa valeur de couleur
  1. Consultez la section « Contrast ratio » (Rapport de contraste) du sélecteur de couleurs. <Vous y trouverez le rapport de contraste de l’élément. Un crochet signifie que l’élément respecte la recommandation A des WCAG (rapport de 4,5:1). Deux crochets signifient qu’il respecte la recommandation AA des WCAG (rapport de 7,0:1).
Lorsque vous cliquez sur le carré de couleur, le rapport de contraste s’affiche
  1. Vous pouvez aussi utiliser les pipettes pour mettre à l’essai d’autres couleurs visibles sur la page. La pipette pour les couleurs en avant-plan se trouve au-dessus du code hexadécimal. Celle pour les couleurs en arrière-plan se trouve dans la section cachée sous le rapport de contraste.
Les pipettes servent à échantillonner les couleurs en avant-plan et en arrière-plan

Ressources :

 

Mise à l’essai à l’aide de l’extension de navigateur Axe de Deque

Suite à la reconnaissance accrue de l’importance de l’accessibilité numérique, de nouveaux outils sont développés pour vous aider à rendre votre site plus accessible. Un de ces outils est l’extension de navigateur Axe de Deque. Cet outil de mise à l’essai est automatisé et gratuit. Il est utile lorsque combiné à la mise à l’essai manuelle, comme les vérifications par clavier seulement et la mise à l’essai par lecteur d’écran.  

Remarque : Deque offre également des versions payantes de Axe. Ces versions disposent de fonctions automatisées supplémentaires de mise à l’essai pour les flux de travail ainsi qu’une manière d’exporter tous les problèmes sur une page donnée.

Comment installer Axe sur votre navigateur

Pour installer l’extension de navigateur, rendez-vous sur le site Web de Axe de Deque (en anglais uniquement) et sélectionnez la version pertinente pour votre navigateur (Chrome, Firefox ou Edge).

Comment effectuer une mise à l’essai avec Axe

L’exemple suivant mettra à l’essai une page du W3C présentant de nombreux problèmes : https://www.w3.org/WAI/demos/bad/before/home.html (en anglais uniquement). Ce site Web présente délibérément des problèmes afin d’illustrer certaines difficultés courantes en matière d’accessibilité.

Pour mettre la page Web mentionnée à l’essai dans Chrome (ou toute autre page Web consultée), suivez les étapes suivantes :

  1. Ouvrez les outils de développement à l’aide de la touche F12, ou des touches Contrôle+Maj+I, ou Commande+Option+I (macOS). Assurez-vous d’être dans l’onglet « Elements » (Éléments).
Chrome affiche une page Web de mise à l’essai avec le panneau des outils de développement ouvert
  1. Cliquez sur le bouton » (si un lecteur d’écran est utilisé, il s’agit du bouton « More tabs » [Onglets supplémentaires]). Ceci ouvre un sous-menu. Sélectionnez « axe DevTools » (Outils de développement de Axe) dans le sous-menu.
Dans les outils de développement, sélectionnez le sous-menu More tabs (Onglets supplémentaires), puis axe DevTools (Outils de développement de Axe)
  1. Un nouvel onglet nommé « axe DevTools » (Outils de développement de Axe) apparaît. Cliquez sur la vignette « Scan ALL of my page » (Analyser l’ensemble de ma page).
Dans les outils de développement, sélectionnez « Scan ALL of my page » (Analyser l’ensemble de ma page)
  1. Les résultats de l’essai de Axe apparaissent. Dans cet exemple, il existe 70 problèmes, dont 34 sont critiques.
Axe affiche 70 problèmes, dont 34 sont critiques
  1. Ensuite, il est possible d’obtenir des renseignements supplémentaires sur un problème particulier. Dans le cadre de cet exemple, « Images must have alternate text » (Les images doivent avoir un équivalent textuel) est sélectionné.
Sélectionnez le problème « Images must have alternate text » (Les images doivent avoir un équivalent textuel)
  1. Un problème précis est affiché, ainsi que les balises de problème. La balise « wcag2a » précise qu’il s’agit d’un problème qui relève du niveau AA du critère de réussite des WCAG. La balise « wcag111 » indique qu’il s’agit d’une non-conformité relative au critère de réussite 1.1.1. Le code HTML responsable du problème se trouve sous le titre « Element source » (Source de l’élément).
Axe affiche un problème spécifique en détail
  1. Si vous cliquez sur le bouton « highlight » (Mise en évidence), le navigateur ajoute une mise en évidence visuelle sur l’élément responsable du problème.
Cliquez sur le bouton « highlight » (Mise en évidence) pour mettre le problème en évidence
  1. Si vous cliquez sur le bouton « Inspect » (Inspecter), l’onglet Elements (Éléments) s’affiche et le code HTML responsable du problème est mis en évidence.  Il y a une balise <img> sans attribut équivalent dans cet exemple.
Dans l’onglet « Elements » (Éléments), le code responsable de l’erreur est mis en évidence
  1. Si vous retournez sous l’onglet « axe DevTools » (Outils de développement de Axe) et que vous cliquez sur le bouton « more info » (Renseignements supplémentaires), un nouvel onglet du navigateur s’ouvre et affiche des renseignements sur ce type de problème. Fermez cet onglet lorsque vous avez consulté les détails affichés.
Le site Deque University présente des renseignements sur ce problème
  1. Lorsque vous consignez les résultats de l’essai, vous pouvez recommander un correctif de code. Vous pouvez mettre le correctif de code à l’essai directement dans le navigateur : allez sous l’onglet « Elements » (Éléments), cliquez avec le bouton droit de la souris sur la ligne de code à modifier, puis sélectionnez « Edit as HTML » (Modifier au format HTML).
Cliquez avec le bouton droit de la souris sur le code à modifier, puis sélectionnez « Edit as HTML » (Modifier au format HTML)
  1. Pour ce problème précis concernant une image sans équivalent textuel, si vous ajoutez alt=””, le problème sera corrigé! (Dans ce cas-ci, l’image fait partie d’une bordure, elle est donc simplement décorative. Elle exige tout de même un attribut équivalent.)
Corrigez le code HTML en ajoutant un attribut équivalent
  1. Maintenant, cliquez sur l’onglet « axe DevTools » (Outils de développement de Axe) pour revenir à Axe.
Cliquez sur l’onglet axe DevTools (Outils de développement de Axe)
  1. Cliquez sur le bouton qui ressemble à une flèche dans un cercle (si un lecteur d’écran est utilisé, il s’agit du bouton « Re-run automatic scan » [Redémarrer l’analyse automatique]). Ceci exécute l’analyse à nouveau.
Cliquez sur le bouton de redémarrage de l’analyse pour refaire celle-ci
  1. Maintenant que le problème est corrigé, il y a un problème en moins. Aussi, puisque la méthode est vérifiée, il faut se rappeler de préciser le correctif du code dans le rapport de vérification.
Les résultats de Axe montrent un problème de moins

Conseils pour la mise à l’essai

Voici quelques conseils supplémentaires utiles pour la mise à l’essai :

  • Axe présente habituellement des résultats précis, même s’il présente parfois un rapport avec un faux positif. Par exemple : s’il y a du texte blanc sur un fond coloré, Axe présume parfois que le fond est blanc et pense donc que du texte blanc est utilisé sur un fond blanc. Il signalera incorrectement ceci comme étant un problème de contraste des couleurs
  • le contenu doit être affiché pour être analysé par Axe. Pour mettre à l’essai en profondeur toutes les parties de la page, il faudra peut-être ouvrir tous les accordéons et toutes les boîtes de dialogue modales, et essayer toutes les dispositions réactives (par la modification de la largeur de la fenêtre du navigateur).

Ressources :

 

Mise à l’essai à l’aide d’un lecteur d’écran

Les lecteurs d’écran permettent aux personnes ayant une déficience visuelle ou des problèmes de lecture d’accéder à l’information. Ces outils repèrent le texte sur un site Web, dans une application ou dans un document et le lisent à voix haute au moyen d’un synthétiseur vocal. Les lecteurs d’écran sont alimentés par l’intelligence artificielle (IA), alors ils ne comprennent pas intuitivement l’ordre dans lequel le texte doit être lu. Ainsi, ils se fient aux éléments comme les titres et autres indices intégrés aux documents, aux sites Web et aux applications en guise de contexte. Faire lire votre contenu à un lecteur d’écran est une manière d’en évaluer l’accessibilité.

Introduction à NVDA

NonVisual Desktop Access (NVDA) est un lecteur d’écran gratuit pour Windows. NVDA est populaire pour évaluer l’accessibilité de pages Web et de documents, car :

  • Il est gratuit (« payez ce que vous pouvez ») et bien actualisé.
  • Il est petit (c.-à-d. que son fichier d’installation est relativement petit) et se charge rapidement.
  • Il respecte les normes du Web, c’est donc un outil de mise à l’essai très précis. Un autre lecteur d’écran pour Windows, JAWS, applique des règles heuristiques et devine la manière d’annoncer les éléments sur la page. Par exemple, si un champ de saisie n’a pas de titre, NVDA le mentionnera, alors que JAWS utilisera le texte à proximité pour le deviner.

Installer NVDA

Vous pouvez télécharger NVDA à partir de la page d’installation de NVDA (en anglais seulement).

Commandes de NVDA

Commandes de base

Ces commandes sont les toutes premières à utiliser pour commencer.

Commande Fonction
Contrôle Arrêter de parler jusqu’à ce qu’une autre touche soit enfoncée
Insertion+S Activer/Désactiver la parole
Insertion+Q Fermer NVDA

Réglages

Voici quelques commandes de configuration de base à régler selon vos préférences.

Commande Fonction
Insertion+M Activer/Désactiver le suivi de la souris (éteindre cette fonction désactivera la fonction d’annonce du contenu touché par le curseur de la souris)
NVDA > Outils > Visionneuse de parole Visionneuse de parole (activer cette fonction pour voir ce que NVDA annonce. Inclure ceci dans les captures d’écran)
NVDA > Préférences > Paramètres > Parole Sélectionner le synthétiseur de parole préféré, puis régler le Débit (la vitesse à laquelle le texte est lu).

Visionneuse de parole

La visionneuse de parole est une fenêtre flottante où tout ce que NVDA annonce est affiché.  Vous pouvez déplacer la fenêtre n’importe où pour l’inclure dans les captures d’écran des problèmes que vous consignez. Pour ouvrir la visionneuse, cliquez sur le logo de NVDA dans la barre des tâches de Windows, sélectionnez « Outils », puis « Visionneuse de parole ».

Une page Web avec la fenêtre de la visionneuse de parole par-dessus

Commandes principales de navigation

Voici les principales commandes à utiliser pour se déplacer sur une page Web.

Commande Fonction
Flèche vers le haut Monter d’une ligne
Flèche vers le bas Descendre d’une ligne
Tabulation Passer à l’élément cliquable suivant
Maj+TAB Passer à l’élément cliquable précédent
Insertion+F7 Ouvrir la liste des éléments afin d’énumérer les liens, les titres, les champs de formulaire, les boutons et les repères
Ctrl+touche Début Aller au début de la page

Liste des éléments

La fonction « Liste des éléments » affiche tous les liens, titres, champs de formulaire, boutons et repères sur la page actuelle. Elle donne un bon aperçu de la page.

Une page Web avec la fenêtre de la liste des éléments par-dessus

Autres commandes de navigation

Voici d’autres commandes utilisées moins souvent, mais tout aussi utiles.

Commande Fonction
Insertion+Espace ou Échap Fermer le mode formulaire (lors de la saisie d’un champ) – pour enfoncer la touche fléchée vers le bas et poursuivre la lecture
H Passer au titre suivant
Maj+H Passer au titre précédent
Flèche vers la droite Annoncer le caractère suivant
Flèche vers la gauche Annoncer le caractère précédent
D Passer au repère suivant
Maj+D Passer au repère précédent

Commandes pour un tableau de données

Pour mettre un tableau de données à l’essai, NVDA dispose de commandes pour se déplacer vers le haut, le bas, la gauche et la droite.

Commande Fonction
Ctrl+Alt+Flèche vers le haut Se déplacer d’une cellule vers le haut
Ctrl+Alt+Flèche vers le bas Se déplacer d’une cellule vers le bas
Ctrl+Alt+Flèche vers la gauche Se déplacer d’une cellule vers la gauche
Ctrl+Alt+Flèche vers la droite Se déplacer d’une cellule vers la droite

Différences entre le mode navigation et le mode formulaire

NVDA dispose de deux modes de fonctionnement distincts. Il active l’un ou l’autre selon son interprétation de la présentation de la page Web. Dans la majorité des types de présentation, NVDA utilisera le mode navigation, à moins que le logiciel ne détecte le passage à un formulaire (ce qui signifie que l’utilisateur.trice devra saisir de l’information). Dans un formulaire, NVDA passera au mode formulaire.

Mode navigation

Lorsque la touche fléchée vers le bas est enfoncée (pour passer à la ligne suivante sur la page), NVDA annonce tous les types de contenu de la page Web, notamment le texte, les liens et les commandes de formulaire. Il s’agit du mode navigation.  L’utilisation de ce mode est une excellente manière de lire l’ensemble du contenu sans rien manquer, du haut de la page jusqu’au bas de celle-ci.

Mode formulaire

Lorsque la tabulation est utilisée pour passer à une commande de formulaire, l’utilisation des touches fléchées entraînera des résultats différents. Il s’agit alors du mode formulaire. Par exemple, vous pouvez sélectionner la case d’option que vous souhaitez à l’aide des touches fléchées. Ou, dans un champ de saisie, l’utilisation des touches fléchées vers le haut ou le bas n’aura aucun effet. Pour sortir du mode formulaire, il suffit d’enfoncer les touches Insertion+Espace ou la touche Échap pour passer à nouveau au mode navigation.

Conseil : Si vous n’arrivez pas à sortir d’un champ de saisie, appuyez sur les touches Insertion+Espace pour quitter le mode formulaire. Vous pourrez alors utiliser la touche fléchée vers le bas pour poursuivre la lecture.

Comment mettre à l’essai une page Web avec NVDA

Pour mettre à l’essai une page Web avec NVDA, suivez ces étapes :

  1. Ouvrez la page Web à mettre à l’essai.
  2. Lancez NVDA.
  3. Cliquez n’importe où sur la fenêtre du navigateur afin d’attirer l’attention de NVDA sur celle-ci.
  4. Utilisez la touche de tabulation dans la page Web pour que NVDA en lise le contenu.
  5. Laissez la souris de côté afin qu’elle n’interfère pas avec l’essai.
  6. Appuyez sur la touche Ctrl pour arrêter la lecture de NVDA (cette fonction sera utilisée fréquemment).
  7. Appuyez sur les touches Ctrl+touche Début pour passer au haut de la page. Puis, appuyer de manière répétée sur la touche fléchée vers le bas pour lire le contenu de la page du haut vers le bas.
  8. Une fois le bas de la page atteint, appuyez sur Ctrl+touche Début pour passer au haut de la page à nouveau. Cette fois, utilisez la touche de tabulation pour parcourir la page. Vous pourrez ainsi accéder à chaque lien et chaque commande du formulaire. Mettez à l’essai chaque élément (ou au moins un bon échantillon) à l’aide de la touche Entrée.
  9. Vous devriez être en mesure de faire annoncer n’importe quel élément de la page à NVDA sans avoir à utiliser la souris. Vous devriez pouvoir utiliser tous les liens et les commandes du formulaire.
  10. Appuyez sur Insertion+F7; cela affichera un menu pratique de liens, des titres, des champs de formulaire, des boutons et des repères.
  11. Appuyez sur Insertion+Q pour fermer NVDA.

    Ressources :

     

Accessibility Insights pour Windows

Il existe un autre outil de vérification de l’accessibilité pour les applications Windows. Il se nomme Accessibility Insights de Microsoft. Cet outil inspecte les applications Windows selon une norme intitulée automatisation d’interface utilisateur (UIA). Il s’agit du cadre d’accessibilité pour Windows de Microsoft. L’UIA donne accès aux éléments de l’interface utilisateur (IU). C’est ce qui permet aux produits de technologie d’aide (AT), comme les lecteurs d’écran, de donner de l’information à propos de l’IU aux utilisateurs.trices.  

Installation d’Accessibility Insights

Afin de télécharger Accessibility Insights pour Windows, consultez la page Accessibility Insights pour Windows (uniquement en anglais), puis cliquez sur le bouton « Download for Windows » (télécharger pour Windows). Suivez les messages-guides pour installer le logiciel.

Wildlife Manager (application de démonstration)

Accessibility Insights comporte une application de démonstration : Wildlife Manager. Cette application permet d’apprendre à utiliser Accessibility Insights. Pour obtenir cette application, consultez la page WildlifeManager et téléchargez WildlifeManager.exe.  Vous pouvez ouvrir le fichier .exe immédiatement (aucune installation n’est nécessaire).

Live Inspect (inspection en temps réel)

Vous pouvez utiliser la fonction « Live Inspect » (inspection en temps réel) pour inspecter les éléments de l’IU en passant votre souris sur ceux-ci.

Pour l’utiliser, ouvrez l’application de démonstration et Accessibility Insights côte à côte. Déplacez le curseur de votre souris sur chaque élément de l’IU, ou utilisez la touche de tabulation. Accessibility Insights affichera le nom et les propriétés de l’élément.

Lorsque vous passez votre souris sur un élément de Wildlife Manager, Insights en affiche les propriétés

Vous pouvez personnaliser la liste des propriétés affichées en cliquant sur le bouton « Properties Settings » (réglages des propriétés) qui ressemble à une icône d’engrenage.

Cliquez sur le bouton « Properties Settings » (réglages des propriétés) qui ressemble à une icône d’engrenage

Vous pouvez alors gérer la liste des propriétés sélectionnées.

Gestion de la liste des propriétés sélectionnées

FastPass (essais automatiques)

Lorsque les responsables du développement modifient le code, ils peuvent utiliser l’essai FastPass (essai automatique) avant chaque vérification de code pour s’assurer qu’ils n’ont créé aucun problème d’accessibilité lors de leurs modifications. FastPass est composé de deux fonctions principales : des vérifications automatisées et des arrêts de tabulation.

Automated Checks (vérifications automatisées)

La fonction Automated Checks (vérifications automatisées) vérifie que les éléments d’une application respectent les douzaines d’exigences en matière d’accessibilité.

Pour utiliser cette fonction, placez votre souris sur le ou les éléments à mettre à l’essai (un encadrement bleu apparaît) et cliquez sur l’icône de mise à l’essai (il ressemble à un bécher).

Placez votre souris sur le ou les éléments à mettre à l’essai, puis cliquez sur le bouton Test (mise à l’essai)

Des problèmes seront signalés pour certains éléments. Pour en sélectionner un, cliquez sur l’icône d’échec (!) correspondant.

Cliquez sur l’icône d’échec (!) souhaité

De l’information sur le problème mis en évidence s’affichera ainsi que des conseils sur la manière de le régler.

L’élément défectueux sera mis en évidence

Vous pouvez enregistrer une capture d’écran du problème à l’aide du bouton « Save » (enregistrer, il ressemble à une disquette).

Tab Stops (arrêts de tabulation)

La fonction Tab Stops (arrêts de tabulation) des essais FastPass vous aide à vérifier que le défilement à l’aide de la touche de tabulation est accessible. Pour mettre à l’essai les arrêts de tabulation, cliquez sur le lien Tests.

Cliquez sur le lien Tests

Puis, sélectionnez « Tab Stops » (arrêts de tabulation).

Cliquez sur « Tab Stops » (arrêts de tabulation)

Activez l’option « Record tab stops » (enregistrer les arrêts de tabulation).

Activez l’option « Record tab stops » (enregistrer les arrêts de tabulation)

Puis, appuyez sur la touche de tabulation plusieurs fois. Chaque arrêt de tabulation sera indiqué dans le tableau « Recorded order results » (résultats de l’ordre enregistré). Il sera alors facile de déterminer quels arrêts de tabulation sont manquants ou dans le mauvais ordre.

Les résultats de l’ordre enregistré sont affichés dans un tableau

Dépannage

La fonction « Troubleshooting » (dépannage) comporte deux éléments relativement importants à garder à l’esprit. Le premier vous permet d’observer les modèles liés à une commande et utilise les méthodes d’UIA pour vérifier si cette commande répond correctement à l’action de l’utilisateur.trice. Le second enregistre les événements de l’application.

Patterns (modèles)

Pour utiliser cette fonction, sélectionnez le bouton « Inspect » (inspecter) dans Accessibility Insights. Puis, sélectionnez un élément de l’IU dans l’application. Ensuite, sélectionnez un « Pattern » (modèle) à inspecter dans Accessibility Insights.

Sélectionnez « Inspect » (inspecter), sélectionnez l’élément dans l’application, puis sélectionnez un « Pattern » (modèle) dans Insights

Par la suite, cliquez sur le bouton « Actions… » du modèle.

Cliquez sur le bouton Action du modèle

Une boîte de dialogue Actions s’ouvrira. Cliquez sur l’onglet « Select » (sélectionner).

Cliquez sur l’onglet « Select » (sélectionner)

Puis, cliquez sur le bouton « Run action » (exécuter l’action).

Cliquez sur le bouton « Run action » (exécuter l’action)

Le message « Succeeded » (réussi) apparaît alors.

Message « Succeeded! » (Réussi!)

Enregistrer les événements de l’application

Une autre partie du dépannage vise à enregistrer les événements de l’application. Pour ce faire, sélectionnez un élément dans l’application. Cet élément sera mis en évidence dans Insights. Cliquez sur le bouton « More options » (plus d’options), puis sélectionnez « Listen to Events » (écouter les événements).

Cliquez sur More options (plus d’options), puis sur Listen to Events (écouter les événements).

Ensuite, cliquez sur le bouton « Start recording » (commencer l’enregistrement).

Cliquez sur le bouton « Start recording » (commencer l’enregistrement)

Les événements invoqués seront consignés sous le titre « Events » (événements).

Les événements sont consignés

Ressources :

 

Mise à l’essai qui ne requiert aucune installation

Au sein de certains organismes, il est possible que vous ne soyez pas autorisé à installer certaines applications sur votre ordinateur. Heureusement, il existe des outils de mise à l’essai de l’accessibilité qui ne requièrent aucune installation.

Signapplet ANDI

ANDI (Accessible Name & Description Inspector) est un ensemble d’outils répartis en menus, qui est développé par la US Social Security Administration. Il comprend plusieurs outils qui mettent graphiquement en évidence les caractéristiques d’une page comme l’ordre de tabulation, les niveaux de titre et le texte de remplacement pour les images.

ANDI peut être « installé » en glissant-déposant un lien sur la barre de signets de votre navigateur (consultez la page d’installation d’ANDI pour obtenir des instructions).

Découvrez les fonctionnalités d’ANDI sur cette page de tutoriel (en anglais seulement).

Menu de signapplets d’ANDI

Applications mobiles

Certaines versions d’applications sont spécialement conçues pour être « mobiles », c’est-à-dire qu’elles peuvent être exécutées sur votre ordinateur à partir d’un dossier ou d’une clé USB.

L’outil Colour Contrast Analyser (CCA) propose une application mobile

La version mobile de CCA peut être téléchargée à partir du site PortableApps.com.

Ouvrez le programme d’installation et sélectionnez un dossier où installer les fichiers de programme. Vous pourrez les supprimer plus tard si vous voulez.

Choisissez un emplacement pour l’installation où les fichiers de programme seront installés

Une fois le processus d’installation terminé, vous pouvez exécuter CCA en double-cliquant sur le fichier ColourContrastAnalyser.exe. Vous pouvez créer un raccourci vers ce fichier et le placer sur le bureau de votre ordinateur.

Pour ouvrir CCA, double-cliquez sur le fichier ColourContrastAnalyser.exe

L’outil NVDA propose une application mobile

NonVisual Desktop Access (NVDA) est un lecteur d’écran gratuit conçu pour Windows. Pour installer l’application mobile de NVDA, téléchargez d’abord le logiciel sur la page de téléchargement de NVDA.

Ouvrez le fichier d’installation, puis cliquez sur le bouton « Create portable copy » (créer une copie portable) plutôt que sur le bouton d’installation.

Sur l’écran d’installation, sélectionnez « Create portable copy » (créer une copie portable)

Ensuite, saisissez (ou naviguez vers) le répertoire dans lequel vous souhaitez stocker les fichiers de programme.

Entrez le répertoire dans lequel les fichiers de programme doivent être stockés

Ouvrez ensuite le dossier contenant les fichiers de programme et ouvrez le fichier nvda.exe.

Vous pouvez également créer un raccourci sur le bureau.

Lighthouse pour Chrome

Le navigateur Chrome comprend l’application Lighthouse. Lighthouse utilise axe, l’outil de vérification d’accessibilité de Deque, pour effectuer une analyse des problèmes d’accessibilité.

Pour analyser une page Web avec Lighthouse, téléchargez la page Web d’abord. Ensuite, appuyez sur F12 ou Control+Shift+i (Command+Shift+i sur MacOS), cliquez sur le bouton « More tabs » (») (plus d’onglets), puis sélectionnez Lighthouse.

Dans DevTools, sélectionnez « More tabs » (plus d’onglets), puis « Lighthouse »

Lighthouse peut exécuter plusieurs essais. Vous pouvez sélectionner ou désélectionner les essais que vous voulez inclure. Sélectionnez un appareil (de bureau ou portable), puis cliquez sur le bouton « Generate report » (générer un rapport).

Cochez « Accessibility » (accessibilité), « Desktop » (bureau), puis cliquez sur « Generate report » (générer un rapport).

Lighthouse affichera un rapport incluant une note globale et une liste de défauts.

Rapport de vérification de Lighthouse

Sa11y

Sa11y est un outil d’assurance de la qualité de l’accessibilité qui met graphiquement en évidence les problèmes courants d’accessibilité et d’utilisabilité. Il aide les auteurs de contenu à repérer les erreurs et les avertissements en affichant des infobulles qui expliquent les corrections à faire. Sa11y donne de meilleurs résultats dans un modèle de système de gestion de contenu, mais il est également offert sous forme de signapplet.

Ressources :

 

Vérificateurs d’accessibilité des documents

Certaines applications de documents comprennent des vérificateurs d’accessibilité et dépendent de techniques particulières pour rendre accessibles les documents.

Microsoft Word

Pour exécuter le vérificateur d’accessibilité dans Word, suivez les étapes ci-dessous :

  1. Dans le ruban, sélectionnez l’onglet « Révision ».
  2. Sélectionnez ensuite « Vérifier l’accessibilité ». Dans le menu déroulant qui apparaît, sélectionnez de nouveau « Vérifier l’accessibilité ». Un essai d’accessibilité s’exécutera et les résultats seront affichés.
Capture d’écran de Word – sélectionnez l’onglet « Révision », puis sélectionnez « Vérifier l’accessibilité »
  1. Examinez les résultats. Une liste d’erreurs, d’avertissements et de conseils comprenant des recommandations sur les corrections nécessaires sera affichée. Consultez la page Règles pour le vérificateur d’accessibilité pour en savoir plus.
Capture d’écran de la page Résultats de l’inspection affichant l’avertissement « Texte de remplacement manquant »

Microsoft PowerPoint

Pour exécuter le vérificateur d’accessibilité dans PowerPoint, suivez les étapes ci-dessous :

  1. Dans le ruban, sélectionnez l’onglet « Révision ».
  2. Sélectionnez ensuite « Vérifier l’accessibilité ». Dans le menu déroulant qui apparaît, sélectionnez de nouveau « Vérifier l’accessibilité ». Un essai d’accessibilité s’exécutera et les résultats seront affichés.
Capture d’écran de PowerPoint – sélectionnez l’onglet « Révision », puis sélectionnez « Vérifier l’accessibilité »
  1. Examinez les résultats. Une liste d’erreurs, d’avertissements et de conseils comprenant des recommandations sur les corrections nécessaires sera affichée. Consultez la page Règles pour le vérificateur d’accessibilité pour en savoir plus.

Adobe PDF

Seulement certains produits d’Adobe comportent un vérificateur d’accessibilité. Adobe Acrobat Reader n’a pas de vérificateur d’accessibilité, mais Adobe Acrobat Pro en possède un. Pour exécuter le vérificateur d’accessibilité dans Acrobat Pro, suivez les étapes ci-dessous :

  1. Sélectionnez Outils > Accessibilité.
  2. La boîte à outils d’accessibilité est affichée dans la barre d’outils secondaire.
  3. Dans la barre d’outils secondaire, cliquez sur « Vérification complète/Vérification de l’accessibilité ».
  4. La boîte de dialogue des options du vérificateur d’accessibilité est affichée.
  5. Dans la section des options de rapport, sélectionnez les options d’affichage des résultats. Vous pouvez enregistrer les résultats sous la forme de fichier HTML ou joindre le fichier des résultats au document.
  6. Sélectionnez une plage de pages si vous souhaitez vérifier individuellement des pages du document.
    Remarque : Lorsque vous avez un document volumineux, vous pouvez soit exécuter une vérification complète, soit vérifier une page à la fois, selon vos préférences.
  7. Sélectionnez une ou plusieurs options de vérification. Celles-ci correspondent aux différents éléments de l’accessibilité que vous souhaitez vérifier (contenu de la page, commentaires, ordre de tabulation, etc.).
Options du vérificateur d’accessibilité
  1. Cliquez sur « Vérifier ». Les résultats sont affichés dans le panneau « Vérificateur d’accessibilité » à gauche, qui contient également des liens et des conseils pratiques pour résoudre les problèmes. Si vous avez créé un rapport à l’étape 5, les résultats sont disponibles dans le dossier sélectionné.
  2. Dans la mesure où la fonction « Vérification complète/Vérification de l’accessibilité » ne fait pas la distinction entre les types de contenu essentiels et non essentiels (par exemple, les bordures décoratives), certains problèmes signalés ne nuisent pas à la lisibilité. Il convient de passer en revue tous les problèmes afin de déterminer lesquels doivent être corrigés.
  1. Le rapport affiche l’un des états suivants pour chaque règle vérifiée :
    • Opération réussie : l’élément est accessible.
    • Ignoré : la règle n’a pas été vérifiée car elle n’était pas sélectionnée dans la boîte de dialogue Options du vérificateur d’accessibilité.
    • Vérification manuelle requise : la fonction Vérification complète/Vérification de l’accessibilité n’a pas pu vérifier automatiquement l’élément. Vérifiez l’élément manuellement.
    • Échec de l’opération : l’accessibilité de l’élément n’a pas pu être confirmée.
Capture d’écran d’Acrobat Pro – Résultats du vérificateur d’accessibilité

Ressources :

 

V

Glossaire

Acronymes

A11y

Abréviation qui se rapporte aux onze lettres situées entre le A et le Y du mot anglais « accessibility ». Cet acronyme fait normalement référence à l’accessibilité numérique.

CDPO

Code des droits de la personne de l’Ontario

CR

Critère de réussite

DevTools

Outils de développement

EFA

Exigences fonctionnelles en matière d’accessibilité

ETSI

European Telecommunications Standards Institute

IPA

Interface de programmation d’applications

IU

Interface utilisateur

JAWS

Job Access With Speech (lecteur d’écran)

LAPHO

Loi sur l’accessibilité pour les personnes handicapées de l’Ontario

LCA

Loi canadienne sur l’accessibilité

NAI

Normes d’accessibilité intégrées

NVDA

Non-visual display access (lecteur d’écran)

PUCR

Sigle des quatre principes des WCAG : la perceptibilité, l’utilisabilité, la compréhensibilité et la robustesse

SO

Système d’exploitation

TDAH

Trouble déficitaire de l’attention avec hyperactivité

TI

Technologie de l’information

TIC

Technologie de l’information et des communications

TSA

Trouble du spectre de l’autisme

W3C

World Wide Web Consortium

WAI

Web Accessibility Initiative (initiative d’accès au Web)

WCAG

Web Content Accessibility Guidelines (règles pour l’accessibilité des contenus Web)

Termes

Accessibilité

Conception de produits, d’appareils, de services, d’environnements, de technologies, de politiques et de règles auxquels toutes les personnes, y compris celles atteintes de divers handicaps, ont accès.

Composante

Partie identifiable d’un programme ou d’une organisation plus vaste.

Conception inclusive

Conception qui tient compte de la gamme complète de la diversité humaine quant aux capacités, à la langue, à la culture, au genre, à l’âge et aux autres formes de différences parmi les humains.

Conformité

Le fait de répondre aux exigences d’un produit, d’un service ou d’un système.

Convivialité

Principe qui garantit qu’un produit, un service ou un système est non seulement accessible, mais aussi facile à utiliser et à comprendre.

Égalité et équité

L’égalité signifie que chaque personne ou groupe reçoit les mêmes ressources ou possibilités. L’équité signifie que chaque personne ou groupe reçoit des ressources ou des possibilités qui tiennent compte des inégalités dans les systèmes sociaux. L’équité vise à produire des résultats égaux.

Handicap

Incapacité ou différence sur le plan physique, mental, intellectuel ou cognitif, de l’apprentissage ou de la communication. Les handicaps peuvent être permanents, temporaires ou épisodiques (ce qui implique que l’incidence du handicap peut varier au fil du temps). Les types de handicaps sont nombreux, ils sont notamment physiques, visuels, auditifs et cognitifs. Les particularités d’un handicap varient d’une personne à l’autre, et une personne peut avoir plusieurs handicaps.

Inclusivité

Pratique ou politique visant à offrir aux personnes qui pourraient autrement être exclues ou marginalisées, notamment les personnes atteintes de handicaps physiques ou mentaux ou appartenant à une autre minorité, un accès égal aux possibilités et aux ressources.

Mesure d’adaptation

Changement apporté afin qu’une personne en situation de handicap puisse pleinement accéder à de l’information et interagir avec celle-ci.

Obstacle

Tout élément qui peut nuire à la participation entière et égale des personnes en situation de handicap. Les obstacles peuvent être de nature architecturale, technologique ou comportementale, provenir de l’information ou des communications, ou découler de politiques ou de procédures. Ils peuvent aussi être financiers, axés sur les connaissances ou directement liés à un handicap (p. ex., une photo sans texte de remplacement explicatif qui l’accompagne est un obstacle pour une personne atteinte de déficience visuelle).

Persona

Utilisateur type fictif créé pour représenter de vraies personnes qui pourraient utiliser un service, un produit ou un site. Créer plusieurs personas diversifiés permet de reconnaître plus facilement les divers besoins et les attentes des éventuels utilisateurs.

Prêt à être converti

Terme servant à décrire une information en format numérique pouvant être aisément convertie dans un format accessible.

Respect

La mesure dans laquelle un élément, p. ex., un produit, un service ou un système, satisfait à une norme prévue.

Technologie adaptée

Version spéciale d’une technologie ou d’un outil qui existe déjà (p. ex., livre en gros caractères, clavier modifié ou outil d’accessibilité d’un système d’exploitation). La technologie adaptée aide les personnes à effectuer des tâches précises.

Technologie d’assistance

Matériel ou logiciel spécialisé qui peut aider les personnes avec un handicap à percevoir le contenu numérique et à interagir avec celui-ci.

Widget

Composante ajoutée à un site Web ou une application en tant que fonctionnalité autonome.

Technologies d’assistance et technologies adaptées

Agrandisseur d’écran

Logiciel qui affiche du contenu de plus grande dimension en grossissant une partie ou la totalité de l’écran.

Contrôle de commutateurs

Logiciel qui interagit avec un dispositif numérique au moyen d’un ou plusieurs commutateurs et qui remplace les clics sur une souris ou les touchers sur un écran.

Lecteur d’écran

Technologie qui aide les personnes ayant des troubles visuels à accéder à du contenu numérique comme des sites Web et des applications et à interagir avec celui-ci à l’aide de l’audition ou du toucher (p. ex., Braille). Les lecteurs d’écran comprennent JAWS, NVDA et VoiceOver.

Synthèse vocale de texte

Technologie analogue au lecteur d’écran. Voir « lecteur d’écran ».

Transcription automatique de la parole

Logiciel qui convertit les paroles en texte numérique ou en commandes.

1

Ressources supplémentaires

Public cible

Bibliothèques :

Pédagogues :

Apprentissage en ligne :

Approvisionnement

Accessibilité sur diverses plateformes

Documents :

Sites Web :

Graphisme :

Médias sociaux :

Apprentissage en ligne :

Vidéos et médias numériques :

Événements virtuels :

Gestion d’un programme d’accessibilité :

Gouvernement de l’Ontario et lois de l’Ontario :

2

Déclaration d’accessibilité

eCampusOntario croit que l’éducation devrait être facile d’accès pour tous. C’est pourquoi il est important de soutenir la création de ressources d’enseignement gratuites, accessibles et libres de droits. Lorsque cela est possible, la Boîte à outils de l’accessibilité numérique d’eCampusOntario respecte les niveaux de conformité A et AA des règles pour l’accessibilité des contenus Web (WCAG 2.0, 2.1) en matière de perceptibilité, d’utilisabilité, de compréhensibilité, de robustesse et de conformité des contenus (https://www.w3.org/Translations/WCAG21-fr/).

Pressbooks a été choisie pour son engagement à l’accessibilité intégrée, telle que décrite à l’adresse https://pressbooks.org/user-docs/accessibility/.