NSI - Accessibilité

Justification

La présente norme énonce la principale exigence concernant l'accessibilité au sein du GdC. Elle renvoie à une norme internationale existante, la recommandation 1.0 des Directives pour l'accessibilité aux contenus Web (Cet hyperlien donne accès à un site d'un organisme qui n'est pas assujetti à la Loi sur les langues officielles. L'information qui s'y trouve est donc dans la langue du site du World Wide Web Consortium (W3C).)

Les critères du GdC mentionnés dans la norme de la NSI sont énoncés et définis dans la Recommandation du W3C. Ce document explique la justification de chacune des quatorze directives fondamentales concernant l'accessibilité universelle des sites Web. Chaque directive est suivie d'une ou plusieurs mesures que doit prendre un concepteur de page pour satisfaire aux exigences de ces directives. Ces mesures s'appellent des « critères ».

Cette norme de la NSI exige des sites Web du GdC qu'ils se conforment aux critères de la Priorité 1 et de la Priorité 2.

Interprétation

[Priorité 1]

Un développeur de contenu Web doit satisfaire à ce critère. À défaut, un ou plusieurs groupes seront dans l'impossibilité d'accéder aux informations contenues dans le document. La satisfaction de ce critère est une condition préalable fondamentale pour que certains groupes puissent utiliser des documents Web.

[Priorité 2]

Un développeur de contenu Web doit satisfaire à ce critère. À défaut, un ou plusieurs groupes auront des difficultés à accéder aux informations contenues dans le document. La satisfaction de ce critère lèvera des barrières significatives à l'accès aux documents Web.

Critères du W3C
Essai du navigateur

1.1 Pratiques exemplaires

Nombre précis de pixels (février 2003)
Les principaux documents de référence utilisés pour la conception de sites Web accessibles
Pratique pour l'accessibilité aux formulaires HTML
Utilisation des feuilles de style en cascade CSS
Utilisation de fonctions qui permettent l'activation d'éléments de page par divers dispositifs d'entrée
Menus déroulants
Assurer l'accessibilité, quelle que soit la plate-forme utilisée

Nombre précis de pixels (février 2003)

On sait qu'il existe des anomalies entre les points 6.1 et 6.2 des normes de la NSI et les points de contrôle 3.4 et 5.3 de l'Initiative d'accessibilité au Web du Consortium W3. La NSI impose l'utilisation d'un nombre précis de pixels pour la présentation des tableaux alors que les points de contrôle 3.4 et 5.3 de l'Initiative d'accessibilité au Web du Consortium W3 ne recommandent pas l'utilisation de nombres précis de pixels ou de tableaux pour la mise en page.

Le motif d'origine, qui est toujours valable, pour exiger que les sites Web du gouvernement du Canada soient conçus avec un nombre précis de pixels pour les cellules des tableaux des barres de menu communes et institutionnels était de garantir une présentation uniforme et un emplacement identique des principaux outils d'aide à la navigation sur tous les sites Web du gouvernement du Canada.

Cette présentation structurée de la NSI demeure suffisamment flexible pour permettre l'expansion des éléments textuels qui forment ces principaux outils d'aide à la navigation, atteignant ainsi les objectifs d'accessibilité des points de contrôle de l'Initiative d'accessibilité au Web du Consortium W3 et, dans la mesure du possible, les objectifs de la Normalisation des sites Internet.

Les principaux documents de référence utilisés pour la conception de sites Web accessibles

Un ensemble de documents et d'outils de soutien sont associés et intégrés aux Directives pour l'accessibilité aux contenus Web. Voici les principaux documents de référence utilisés pour la conception de sites Web accessibles (Ces hyperliens donnent accès à des sites d'un organisme qui n'est pas assujetti à la Loi sur les langues officielles. L'information qui s'y trouve est donc dans la langue du site.) :

• Techniques associées aux Directives pour l'accessibilité aux contenus Web 1.0
  Ce document est une source précieuse d'exemples, de codes et d'explications sur la manière d'assurer la mise en oeuvre de chaque critère. Il associe un exemple à chacun des critères du document sur les directives.
• Liste des erreurs connues dans les Directives
  Compte tenu que la recommandation du W3C est une norme officielle, il est interdit de modifier le document original. Toute correction d'erreur ou tout éclaircissement jugés nécessaires dans le document original sont signalés dans un document d'Errata.
• Liste de vérification des critères - Directives pour l'accessibilité aux contenus Web
  La liste de vérification des critères est un bon outil dont les concepteurs de pages ou les webmestres peuvent se servir pour identifier les problèmes de conception et inscrire les mesures pertinentes qui ont été prises. Ce document est présenté sous forme de tableau, format qui peut être inaccessible à certaines personnes.
  Une version plus accessible de la liste est également disponible.
• Programme d'études - Directives pour l'accessibilité aux contenus Web
  Le programme d'études est un guide autodidactique qui concerne l'information portant sur les contenus de sites Web du W3C. Il inclut, comme le document sur les techniques, des exemples associés à plusieurs des critères. Toutefois, il tente d'utiliser des exemples plus faciles à comprendre et, lorsque c'est possible, affiche les résultats de l'application de ces techniques à une page Web.

Compte tenu de la portée et du niveau de détail des ressources ci-dessus, nous n'avons pas tenté de reproduire ou de réinventer dans la Boîte à outils de la NSI tous les exemples que l'on peut y trouver. Certains aspects de la conception de la NSI peuvent toutefois tirer avantage de l'application des techniques particulières présentées dans les pages suivantes.

L'application des normes et l'utilisation cohérente de techniques de conception accessibles permettront au GdC d'atteindre son objectif de brancher tous les Canadiens.

Pratique pour l'accessibilité aux formulaires HTML

Les formulaires HTML en eux-mêmes ne sont pas inaccessibles. L'utilisation qu'en fait l'auteur du programme et/ou de la page détermine l'accessibilité du produit final.

Éléments d'un formulaire inaccessible :

• mise en page et emplacement complexes des contrôles et des zones de saisie
• explications non claires des exigences
• champs de texte et leur étiquette séparés et non clairement associées aux contrôles correspondants
• langage de script côté client pour valider ou remplir les entrées
• aucune autre méthode d'envoi de l'information fournie (p. ex., aucune adresse de courrier électronique pour communiquer avec une personne-ressource, aucun numéro de téléphone pour obtenir de l'aide)

Éléments d'un formulaire accessible :

• mise en page simple (p. ex., sur une seule colonne) des contrôles et des zones de saisie
• explications ou étiquettes claires (significatives) associées aux zones et aux contrôles
• utilisation appropriée de balises HTML conçues spécifiquement pour améliorer l'accessibilité (p. ex., LABEL, OPTGROUP)
• vérification et validation côté serveur de la saisie des données
• proposition d'autres méthodes pour communiquer avec une personne-ressource et/ou transmettre de l'information

Toutes les plus anciennes des technologies fonctionnelles sont en mesure de prendre en charge des formulaires HTML bien conçus. L'astuce consiste à obtenir des concepteurs qu'ils réalisent des pages simples du côté serveur.

Utilisation des feuilles de style en cascade CSS

La plupart des entreprises codent le texte de leurs pages Web au moyen des balises de police <FONT> à éviter, et pire encore, fixent la taille du texte (en pixels ou en points) dans le balisage ou dans les feuilles de style associées. Cette méthode empêche l'utilisateur de modifier la taille du texte, ce qui brime les personnes ayant des problèmes de vision ou qui préfèrent utiliser une résolution d'écran différente des standards 640x480 ou 800x600.

Solution : Utiliser les feuilles de style en cascade CSS

• Les feuilles de style CSS ont été conçues pour permettre de définir de façon précise – séparément du balisage – les aspects tels que l'espacement entre les caractères, l'alignement du texte, la position des éléments dans la page, les sons et la voix, les caractéristiques des polices de caractères, etc.
• En séparant le style du balisage, les auteurs peuvent simplifier et épurer le code HTML de leurs documents, ce qui rend ces derniers plus accessibles.
• Les feuilles de style CSS permettent de définir avec exactitude l'espacement, l'alignement et le positionnement des éléments, en plus d'éviter aux auteurs de faire une mauvaise utilisation des balises (c.-à-d. l'utilisation des balises pour une fonction autre que ce pourquoi elles sont conçues). Par exemple, les balises HTML <BLOCKQUOTE> et <TABLE>, qui sont conçues respectivement pour marquer une citation et pour créer un tableau, sont fréquemment utilisées pour créer des effets visuels tels que la mise en retrait ou l'alignement de texte. Lorsque ces balises mal utilisées sont lues par un logiciel de navigation spécialisé (p. ex., logiciel de synthèse vocale), elles risquent d'être mal interprétées, ce qui rend le document incompréhensible.
• En plus de prévenir une utilisation détournée des balises, les feuilles de style permettent de réduire la mauvaise utilisation d'images. Par exemple, les auteurs utilisent parfois des images invisibles d'un pixel pour positionner le contenu de leurs pages. En plus d'alourdir les documents, ce qui ralentit leur téléchargement, cette méthode désoriente également les agents logiciels qui cherchent du texte alternatif (attribut « alt ») pour ces images. Grâce aux propriétés de positionnement des feuilles de style CSS, il n'est plus nécessaire d'utiliser des images invisibles pour définir la position des objets dans la page.
• Les feuilles de style CSS permettent de définir de façon précise la taille, la couleur et le style des polices. Certains auteurs intègrent du texte à des images lorsqu'ils ne sont pas certains que la police qu'ils souhaitent utiliser est installée sur l'ordinateur du client. Le texte intégré à des images ne peut être lu par des logiciels spécialisés tels que les lecteurs sonores d'écran, et ne peut être répertorié par les moteurs de recherche. Pour remédier à cette situation, les puissantes polices WebFonts des feuilles de style CSS permettent aux utilisateurs d'exercer un meilleur contrôle sur les polices côté client. Grâce aux polices WebFonts, les auteurs peuvent se fier aux mécanismes de substitution qui s'exécutent chez le client lorsque les polices choisies par l'auteur ne sont pas disponibles. Les polices peuvent être substituées avec exactitude, synthétisées par le logiciel du client ou encore téléchargées du Web, selon les instructions de l'auteur.
• Les feuilles de style CSS permettent aux utilisateurs de passer outre aux styles de l'auteur. Cette caractéristique est très importante pour les utilisateurs qui ne peuvent afficher la page selon les polices et les couleurs choisies par l'auteur. Les feuilles de style CSS permettent aux utilisateurs d'afficher des documents avec leurs propres polices, couleurs, etc., préalablement précisées dans une feuille de style de l'utilisateur.
• Les feuilles de style CSS permettent de générer automatiquement des listes numérotées, des puces, ainsi que d'autres marqueurs permettant aux utilisateurs de s'orienter dans un document. Les listes, tables ou documents qui contiennent beaucoup d'information sont plus faciles à consulter lorsqu'ils comprennent des chiffres ou d'autres repères contextuels.
• Les feuilles de style CSS permettent également la définition de sons, ce qui permet de définir la façon dont le document sera lu par un logiciel de synthèse vocale. Les feuilles de style sonores (ou feuilles de style ACSS) permettent aux auteurs et aux utilisateurs de préciser le volume du contenu sonore, des sons en arrière-plan, des propriétés spatiales du son, ainsi que toute une série de propriétés permettant d'ajouter des effets à la parole synthétisée comparables à celles utilisées à l'égard des polices stylisées pour créer des effets visuels.
• Les feuilles de style CSS permettent une définition plus précise de l'affichage des éléments optionnels qu'avec le HTML utilisé seul. Les sélecteurs CSS2 donnent accès aux valeurs d'attribut, souvent utilisées pour l'affichage de contenu optionnel. Avec les feuilles de style CSS2, les valeurs d'attribut peuvent être intégrées à un document, avec le contenu d'un élément principal.

Pour plus d'information à propos des feuilles de style.

Plus d'information sur la mise en œuvre des feuilles de style CSS.

Mise en œuvre des feuilles de style CSS

Les logiciels de navigation les plus répandus ne prennent pas en charge les feuilles de style CSS de façon uniforme. Toutefois, la dernière génération de logiciels de navigation d'un certain nombre de fournisseurs démontre une solide mise en œuvre de la plupart des technologies CSS1 et d'un grand nombre des technologies CSS2, et cette tendance va en s'améliorant.

Un aspect de la conception de documents accessibles au moyen des feuilles de style CSS consiste à veiller à ce que les documents demeurent accessibles lorsque les feuilles de style sont désactivées ou non prises en charge.

En attendant que la plupart des logiciels de navigation prennent en charge les feuilles de style de façon uniforme, les concepteurs Web peuvent quand même créer des documents accessibles en combinant les caractéristiques prises en charge des feuilles de style CSS à certaines fonctions de présentation du HTML.

Les documents qui utilisent le HTML plutôt que les feuilles de style CSS pour la présentation doivent pouvoir être convertis de façon harmonieuse. Par exemple, si des tables sont utilisées pour la mise en page, elles doivent continuer à avoir du sens lorsqu'elles sont intégrées en série.

Utilisation de fonctions qui permettent l'activation d'éléments de page par divers dispositifs d'entrée

http://www.w3.org/WAI/wcag-curric/chk10-0.htm

L'accès non tributaire du type d'unité permet à l'utilisateur d'interagir avec un agent ou un document au moyen de l'unité d'entrée (ou de sortie) voulue - souris, clavier, voix, licorne ou autre. Si, par exemple, le contrôle d'un formulaire ne peut s'activer qu'au moyen d'une souris ou d'un autre dispositif de pointage, une personne qui accède à la page sans la voir et effectue l'entrée par la voix, le clavier ou tout autre dispositif qui n'est pas un outil de pointage ne pourra utiliser le formulaire.

Remarque. Le fait de fournir des texte l'équivalents aux graphiques aux des images servant de liens permet d'utiliser ceux-ci sans dispositif de pointage.

En général, dans les pages permettant l'interaction au moyen du clavier, il est aussi possible d'utiliser l'entrée vocale ou une interface de ligne de commande.

Conception pour la non-subordination à un type d'unité particulier

Critère 9.3 du W3C - Pour les scripts, définir des programmes de traitement (ou gestionnaires) d'événements logiques plutôt que des programmes de traitement d'événements tributaires du type d'unité.

Un programme de traitement d'événements appelle un script lorsqu'un certain événement se produit (p. ex., déplacement de la souris, pression d'une touche, chargement du document, etc.). Dans le langage HTML 4.0, les gestionnaires d'événements sont couplés aux éléments par des attributs (commençant par « on », comme dans « onkeyup »).

Ce qui survient après l'événement dépend du script qu'a créé l'auteur de la page. Il peut s'agir simplement d'effets décoratifs comme la mise en évidence d'une image ou le changement de couleur du texte d'un élément. Il peut y avoir aussi des effets plus importants, comme l'exécution d'un calcul, l'affichage d'un renseignement important pour l'utilisateur ou la transmission d'un formulaire. En ce qui concerne les scripts qui ne font pas que modifier la présentation d'un élément, les développeurs de contenus devraient procéder comme suit :

Utiliser des déclencheurs d'événements associés à l'application plutôt qu'à l'interaction de l'utilisateur. Dans le langage HTML 4.0, les attributs d'événements associés à l'application sont « onfocus », « onblur » (le contraire de « onfocus ») et « onselect ». Prendre note que ces attributs sont conçus pour ne pas être tributaires du type d'unité, mais qu'ils sont intégrés en tant qu'événements liés à l'utilisation du clavier dans les navigateurs courants.

Autrement, si vous devez utiliser des attributs tributaires du type d'unité, fournissez des mécanismes d'entrée redondante (c'est-à-dire, définir deux gestionnaires pour le même élément) :

• Utiliser « onmousedown » avec « onkeydown »
• Utiliser « onmouseup » avec « onkeyup »
• Utiliser « onclick » avec « onkeypress »
• Dans le langage HTML 4.0, il n'y a pas d'équivalent du double clique (« ondblclick ») pour le clavier

Exemple : http://www.w3.org/WAI/wcag-curric/sam71-0.htm

Comment rendre vos fenêtres en incrustation plus accessibles

Pour rendre les fenêtres en incrustation (à ouverture automatique) accessibles aux personnes qui n'utilisent pas une souris pour naviguer, ajoutez les déclencheurs « onFocus » et « onBlur » pour rendre l'effet accessible aux utilisateurs d'un clavier.

Veuillez noter que les fenêtres en incrustation codés du coté client peuvent être partiellement ou totalement inaccessibles pour certains utilisateurs. Il est possible que les utilisateurs de lecteurs d'écran ne sachent pas que de nouvelles fenêtres ont été ouvertes, ou qu'ils soient désorientés par leur apparition soudaine. De plus, les utilisateurs qui ont désactivé les scripts ou qui utilisent un navigateur ne supportant pas les scripts ne recevront pas le message. Lorsque pratique, utiliser des techniques coté serveur pour transmettre des messages importants.

Comment rendre vos menus plus accessibles

Les scripts qui mettent en surbrillance les boutons de la barre de navigation sont codés pour fonctionner uniquement avec les utilisateurs d'une souris (« onMouseOver » et « onMouseOut »), mais cette situation peut être rétablie facilement.

Ajoutez les déclencheurs d'événement « onFocus » et « onBlur » pour que l'effet soit disponible également pour les utilisateurs d'un clavier.

Voici comment modifier les menus déroulants :

Ajout d'un bloc <NOSCRIPT> : 

Dans l'exemple ci-dessous tiré de la page d'accueil en français, le code est extrait du bouton Salle des nouvelles. Les déclencheurs d'événement supplémentaires ne sont pas inclus; l'exemple utilisé montre uniquement l'utilisation du bloc <NOSCRIPT>.

Le solution : Les URL et le texte des liens sont simplement copiés du script figurant plus haut dans la page, puis collés en HTML ordinaire (liste <UL>) dans un bloc <NOSCRIPT> dans la cellule de la table qui contient le bouton :

<TD>

<A onmouseover="movepic('buttonNewsroom','/images.nsf/vLUImages/
WebHeaderEnglish/$file/top_nav_yellow_newsroom1.GIF'),popUp('elMenu6',event)"
onmouseout="movepic('buttonNewsroom','/images.nsf/vLUImages/
WebHeaderEnglish/$file/top_nav_yellow_newsroom.GIF'),popDown('elMenu6')"
href="http://www.acdi-cida.gc.ca/newsro-f.htm">

<IMG alt=Nouvelles src="nouvelles.gif"
border="0" name=buttonNouvelles></A>

<noscript>
<ul>
<li><a href="/newsro-f.htm">Nouvelles de Page principale</a><br></li>
<li><a href="/page/06b10c0? OpenView&Start=1&Count_00&Expand=1#1">Communiqués de presse</a><br></li>
<li><a href="/page/06a0064? OpenView&Start=1&Count_00&Expand=1#1">Discours</a><br></li>
<li><a href="/publications-f.htm">Publications</a><br></li>
<li><a href="/nouvelles.htm">Dépêches</a><br></li>
<li><a href="/événements.htm">À venir</a><br></li>
<li><a href="/issues-f.htm">Grands enjeux mondiaux</a><br></li>
<li><a href="/archives-f.htm">Nouvelles de l'ACDI – Archives</a><br></li>
<li><a href="/media-f.htm">Multimédia</a><br></li>
<li><a href="/inscrire-f">Abonnez-vous</a><br></li></ul>
</noscript>

</TD>

• Cette page a été testée avec un logiciel de navigation ne prenant pas en charge le JavaScript (Lynx) et avec Netscape 4.6 avec le JavaScript désactivé : cela fonctionne bien.
• La page s'affiche bizarrement dans Netscape avec le JavaScript désactivé, mais vous avez toujours accès à la fonction.
• Le bloc <NOSCRIPT> est ignoré (donc non affiché) par Internet Explorer 5.5 et par Netscape 4.6 lorsque le JavaScript est activé.

Assurer l'accessibilité, quelle que soit la plate-forme utilisée

Pour assurer l'accessibilité entre les plates-formes :

• Assurer qu'une liste de liens semblable à celle figurant dans le menu déroulant (ou dans le bloc <NOSCRIPT>) figure dans la page de destination du lien principal.
• Assurer que le menu déroulant (et le bloc <NOSCRIPT>) n'est pas L'UNIQUE façon d'obtenir les sous-liens.

Raison : Les gens qui utilisent un logiciel de navigation graphique prenant en charge les scripts risquent de ne pas voir le menu déroulant parce que la technologie d'aide qu'ils utilisent ne le reconnaît pas et de ne pas voir la solution de rechange du bloc <NOSCRIPT> parce que cette solution n'est pas activée lorsque l'utilisateur emploie un logiciel de navigation qui prend en charge les scripts.