English | Contactez-nous | Aide | Recherche | Site du Canada | |||||
Quoi de neuf? | À notre sujet | Politiques | Documents | Site du SCT |
Calendrier | Liens | FAQ | Présentations | Accueil |
|
NSI - Accessibilité
Norme 1.1Tous les sites Web du GdC doivent être conformes aux critères de la Priorité 1 et de la Priorité 2 du W3C afin de garantir un accès facile au plus vaste auditoire possible. JustificationLa 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 1.1 Pratiques exemplairesNombre précis de pixels (février 2003) 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 accessiblesUn 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.) :
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 HTMLLes 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 :
Éléments d'un formulaire accessible :
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 CSSLa 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
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éehttp://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) :
Exemple : http://www.w3.org/WAI/wcag-curric/sam71-0.htm Comment rendre vos fenêtres en incrustation plus accessiblesPour 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/ <IMG alt=Nouvelles src="nouvelles.gif" <noscript> </TD>
Assurer l'accessibilité, quelle que soit la plate-forme utiliséePour assurer l'accessibilité entre les plates-formes :
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. |
|||||||||||||||||||||||||
|
|
Haut de la page |
Avis importants |