Pour une meilleure accessibilité des sites publics aux personnes
publicité
Association BRAILLENET / Réseau Accessiweb Pour une meilleure accessibilité des sites publics aux personnes handicapées GUIDE BRAILLENET à l’usage des webmestres Association BrailleNet 12, bis rue de Picpus 75012 – Paris tél : 01 44 27 34 35 / 26 25 e-mail : [email protected] Document rédigé pour : Délégation Interministérielle à la Réforme de l’Etat Janvier 2002 Note préliminaire Le guide se réfère : • Pour ce qui concerne le HTML, à la version HTML 4.01 : http://www.w3.org/TR/html4/ • Pour ce qui concerne les recommandations WAI, à la version « Web Content Accessibility Guidelines 1.0 » (WCAG 1.0) de mai 1999 : http://www.w3.org/TR/WCAG10/ Pour la traduction française, à la version du site Internet.gouv : http://www.internet.gouv.fr/francais/guide/w3c/w3c.html Ce guide a été rédigé par : Dominique ARCHAMBAULT, Maître de Conférences, CNRS, INSERM, UPMC Denis BOULAY, Chargé de mission accessibilité, BrailleNet Dominique BURGER, Ingénieur de Recherche, INSERM, UPMC Maryline CLANCHIER, Ergonome, BrailleNet Sylvie DUCHATEAU, Chargée de mission accessibilité, BrailleNet Les experts suivants y ont apporté une contribution significative : Alain BLOURI, technicien - formateur, Association Paul Guinot, VILLEJUIF Jean-Marc BRUNO, technicien, EO - EDPS, LYON Sébastien GUEGNIARD, informaticien, EURL MONTECLAIR, ANGERS Bruno HAUSDORFF, administrateur réseau, CRDV, CLERMONT-FERRAND Rémy HAVET, informaticien, URBILOG, LILLE Michel HOEL, informaticien, URBILOG, LILLE Julien PERBEN, formateur, AG2R, PARIS Pierre REYNAUD, webmaster - formateur, ILE DE LA REUNION Jérôme SURUT, informaticien, EURL MONTECLAIR, ANGERS TABLE DES MATIERES INTRODUCTION ................................................................................................................................................. 7 POURQUOI RENDRE UN SITE ACCESSIBLE ? ........................................................................................... 8 1. 2. 3. 4. 5. 6. 7. L’ACCESSIBILITE UN CONCEPT GENERAL ................................................................................................... 8 L’ACCESSIBILITE, UN CHOIX CITOYEN........................................................................................................ 8 L’ACCESSIBILITE, UN CHOIX STRATEGIQUE ................................................................................................ 8 L’ACCESSIBILITE, UN CHOIX ECONOMIQUE ................................................................................................ 9 L’ACCESSIBILITE, UN CHOIX INTERNATIONAL ............................................................................................ 9 LES DISPOSITIONS EN FAVEUR DES PERSONNES HANDICAPEES ................................................................... 9 POPULATIONS CONCERNEES ..................................................................................................................... 10 Les personnes handicapées visuelles .......................................................................................................... 10 Les personnes déficientes auditives : ........................................................................................................... 11 Les personnes handicapées motrices ........................................................................................................... 12 Les déficients intellectuels et cognitifs......................................................................................................... 13 LES FICHES PRATIQUES BRAILLENET .................................................................................................... 15 FICHE 1 : LES IMAGES ................................................................................................................................... 16 1. RAPPEL DE LA RECOMMANDATION 1 DES WCAG 1.0 : ........................................................................... 16 Raisons de cette recommandation : ............................................................................................................. 16 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 16 La règle générale ......................................................................................................................................... 16 Images liens ................................................................................................................................................. 16 Images à zones cliquables ou réactives (images map)................................................................................. 16 Textes au format image................................................................................................................................ 17 Images illustratives ...................................................................................................................................... 17 Images à usage typographique .................................................................................................................... 17 Images de fond ............................................................................................................................................. 18 Images complexes ........................................................................................................................................ 18 Cas des images générées par un programme CGI....................................................................................... 19 3. APPLICATION A L’AIDE DES EDITEURS HTML ......................................................................................... 19 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 19 FICHE 2 : LES CADRES (OU « FRAMES »).................................................................................................. 20 RAPPEL DE LA RECOMMANDATION 12 DES WCAG 1.0 : ......................................................................... 20 Raisons de cette recommandation................................................................................................................ 20 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 20 3. APPLICATION A L’AIDE DES EDITEURS HTML ......................................................................................... 21 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 21 1. FICHE 3 : LES LIENS........................................................................................................................................ 22 RAPPEL DES RECOMMANDATIONS 1, 9 ET 13 DES WCAG 1.0 ................................................................. 22 Raisons de ces recommandations ................................................................................................................ 22 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 22 La formulation ............................................................................................................................................. 22 La présentation ............................................................................................................................................ 22 L’utilisation de l’attribut TITLE .................................................................................................................. 23 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 23 1. FICHE 4 : LES FEUILLES DE STYLE (CASCADING STYLE SHEETS) ................................................. 24 1. RAPPEL DES RECOMMANDATIONS 3 ET 6 DES WCAG 1.0........................................................................ 24 Raisons de cette recommandation................................................................................................................ 24 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 24 La règle générale ......................................................................................................................................... 24 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 25 FICHE 5 : LES TABLES.................................................................................................................................... 26 1. RAPPEL DES RECOMMANDATIONS 5 ET 10 DES WCAG 1.0 : ................................................................... 26 Raisons de ces recommandations ................................................................................................................ 26 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 26 La règle générale ......................................................................................................................................... 26 Tables utilisées pour la forme...................................................................................................................... 26 Les tableaux de données .............................................................................................................................. 27 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 27 FICHE 6 : LES FORMULAIRES...................................................................................................................... 28 RAPPEL DE LA RECOMMANDATION DES WCAG 1.0................................................................................. 28 Raisons de cette recommandation................................................................................................................ 28 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 28 La règle générale ......................................................................................................................................... 28 Accéder au formulaire grâce au clavier ...................................................................................................... 28 Donner un nom explicite aux contrôles des formulaires.............................................................................. 28 Grouper les contrôles des formulaires......................................................................................................... 29 Validation des formulaires........................................................................................................................... 30 3. APPLICATION A L’AIDE DES EDITEURS HTML ......................................................................................... 32 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 32 1. FICHE 7 : LES SCRIPTS................................................................................................................................... 33 RAPPEL DES RECOMMANDATIONS 6 ET 8 DES WCAG 1.0 : ..................................................................... 33 Raisons de ces recommandations ................................................................................................................ 33 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 33 La règle générale ......................................................................................................................................... 33 Les scripts et applets.................................................................................................................................... 33 3. APPLICATION A L’AIDE DES EDITEURS HTML ......................................................................................... 35 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 35 1. FICHE 8 : TECHNOLOGIE FLASH, APPLETS, OBJETS MULTIMEDIA .............................................. 36 RAPPEL DE LA RECOMMANDATION 6 DES WCAG 1.0.............................................................................. 36 Raisons de cette recommandation................................................................................................................ 36 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 36 La règle générale ......................................................................................................................................... 36 Pour les animations Flash ........................................................................................................................... 36 Pour les applets Java ................................................................................................................................... 37 3. APPLICATION A L’AIDE DES EDITEURS HTML ......................................................................................... 38 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 38 1. FICHE 9 : PRESENTATION VISUELLE........................................................................................................ 39 RAPPEL DES RECOMMANDATIONS 2, 3, 6 ET 7 DES WCAG 1.0 ............................................................... 39 Raisons de ces recommandations ................................................................................................................ 39 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 39 La règle générale ......................................................................................................................................... 39 Contrastes .................................................................................................................................................... 39 Information transmise.................................................................................................................................. 40 Taille des images.......................................................................................................................................... 40 Points à vérifier ........................................................................................................................................... 40 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 41 1. FICHE 10 : LES ELEMENTS SONORES ....................................................................................................... 42 1. RAPPEL DE LA RECOMMANDATION 1 DES WCAG 1.0 : ........................................................................... 42 Raisons de cette recommandation................................................................................................................ 42 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 42 La règle générale ......................................................................................................................................... 42 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 42 FICHE 11 : CONTROLE DE L'UTILISATEUR SUR LES CHANGEMENTS DU CONTENU ............... 43 RAPPEL DE LA RECOMMANDATION 7 DES WCAG 1.0 ............................................................................. 43 Raisons de cette recommandation................................................................................................................ 43 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 43 La règle générale ......................................................................................................................................... 43 Gifs animés .................................................................................................................................................. 43 Clignotements (mot ou dessin) et mouvements (texte défilant) .................................................................... 43 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 44 1. FICHE 12 : LES BALISES................................................................................................................................. 45 1. RAPPEL DES RECOMMANDATIONS 3 ET 4 DES WCAG 1.0 : ..................................................................... 45 Raisons de ces recommandations ................................................................................................................ 45 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 45 La règle générale ......................................................................................................................................... 45 Le type de document..................................................................................................................................... 45 Les éléments en-tête ..................................................................................................................................... 45 Les listes et éléments de listes ...................................................................................................................... 46 Le balisage des citations.............................................................................................................................. 46 L’attribut « lang »........................................................................................................................................ 46 L‘attribut « title »......................................................................................................................................... 46 3. APPLICATION A L’AIDE DES EDITEURS HTML ......................................................................................... 47 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 47 FICHE 13 : POINTS SUPPLEMENTAIRES A EVITER............................................................................... 48 1. 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 48 EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 48 FICHE 14 : INFORMATION DE CONTEXTE ET D'ORIENTATION....................................................... 49 RAPPEL DES RECOMMANDATIONS 12 ET 13 DES WCAG 1.0 ................................................................... 49 Raisons de cette recommandation................................................................................................................ 49 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 49 La règle générale ......................................................................................................................................... 49 Titre aux pages............................................................................................................................................. 49 Cadres.......................................................................................................................................................... 50 Blocs d'information...................................................................................................................................... 50 Méta-données............................................................................................................................................... 50 Informations sur les regroupements de documents...................................................................................... 50 Informations distinctives .............................................................................................................................. 50 Art ASCII...................................................................................................................................................... 50 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 51 1. FICHE 15 : MECANISMES D'AIDE A LA NAVIGATION .......................................................................... 52 1. RAPPEL DE LA RECOMMANDATION 13 DES WCAG 1.0 ........................................................................... 52 Raisons de cette recommandation................................................................................................................ 52 2. CE QU’IL FAUT FAIRE ............................................................................................................................... 52 La règle générale ......................................................................................................................................... 52 Plan du site .................................................................................................................................................. 52 Moteur de recherche .................................................................................................................................... 52 Page d'aide .................................................................................................................................................. 52 Liens 53 Barres de navigation.................................................................................................................................... 53 Pages et nombre de clics.............................................................................................................................. 53 3. EXEMPLES SUR LES SITES EVALUES .......................................................................................................... 53 FICHE 16 : UTILISATION DES FORMATS DE FICHIER ......................................................................... 54 1. RAPPEL DE LA RECOMMANDATION 11 DES WCAG 1.0 ........................................................................... 54 2. 3. Raisons de cette recommandation................................................................................................................ 54 CE QU’IL FAUT FAIRE ............................................................................................................................... 54 EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 55 FICHE 17 : UTILISATION DE VERSIONS ALTERNATIVES ................................................................... 56 RAPPEL DE LA RECOMMANDATION 11 WAI............................................................................................. 56 CE QU’IL FAUT FAIRE ............................................................................................................................... 56 La règle générale ......................................................................................................................................... 56 Version alternative....................................................................................................................................... 56 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES .................................................................................... 57 1. 2. LES OUTILS POUR L’EVALUATION DE L’ACCESSIBILITÉ D’UN SITE ............................................ 58 VERIFICATIONS SIMPLES .................................................................................................................................... 58 OUTILS D’EVALUATION AUTOMATIQUE DES SITES ............................................................................................. 59 OUTILS DE REPARATION .................................................................................................................................... 60 OUTILS DE FILTRAGE ......................................................................................................................................... 60 REFERENCES SUR L’ACCESSIBILITÉ ....................................................................................................... 62 RECOMMANDATIONS ................................................................................................................................. 62 LABELS ........................................................................................................................................................... 63 INTITULE DES LIENS HYPERTEXTES PRESENTS DANS LES FICHES.............................................. 64 INDEX .................................................................................................................................................................. 69 ANNEXE 1 : TRAVAIL ET AUTORITE DE LA WAI................................................................................... 74 ANNEXE 2 : LES 30 SITES EVALUES PAR BRAILLENET ....................................................................... 76 ANNEXE 3 : LE RESEAU ACCESSIWEB ...................................................................................................... 77 1. LES PARTENAIRES .................................................................................................................................... 77 LE LABEL ACCESSIWEB ................................................................................................................................... 78 INTRODUCTION Depuis 1997, l'Internet a connu un grand essor en Europe, et en France. De plus en plus de services, qui étaient jusque-là accessibles via le minitel ou le téléphone, sont disponibles sur la toile. L'Administration publique en fait aujourd'hui partie. La plupart des organismes de l'Etat ont leur site Web et mettent à la disposition des citoyens des informations, des formulaires, et l’accès à de nombreux services de l'Etat. La mise à disposition d'informations et de services sous forme électronique est une chance pour une meilleure intégration sociale et culturelle des personnes handicapées. En effet, des dispositifs spécifiques permettent à une personne handicapée, aveugle ou malvoyante, sourde ou malentendante, d’utiliser un ordinateur et d’accéder au Web comme les autres, et par conséquent d’accéder à des services qui nécessitaient jusqu’alors la médiation d’une tierce personne, comme par exemple d'effectuer une démarche administrative ou d'accéder à l'information d’un service public depuis son domicile, le lieu de travail ou encore l'hôpital. Grâce au courrier électronique, aux groupes de discussion, au transfert de fichiers, l'Internet est aussi un outil de communication qui permet aux personnes handicapées de rompre une forme d’isolement. Cependant, ces nouvelles possibilités offertes aux personnes handicapées sont freinées par les problèmes d'accès constatés sur la plupart des sites Web. Une étude effectuée par l'Association BrailleNet, à la demande de la DIRE, sur un échantillon de 30 sites publics en septembre-octobre 2001, montre que peu de sites publics sont aujourd'hui complètement accessibles1. Même si pour certains sites des efforts notables ont été faits, la majorité des sites ne respecte pas les recommandations internationales permettant au plus grand nombre d'accéder à l'information sur le Web. Ce guide BrailleNet a pour objectif d’aider les concepteurs à réaliser des sites Web accessibles à tous, sans rien perdre de leur qualité graphique. • • • • 1 Dans une première partie on définit ce qu'est l'accessibilité, ce qu'elle implique et ses avantages pour les concepteurs de sites et les internautes. La seconde partie est constituée d’une série de fiches pratiques destinées à répondre de manière concrète aux principales questions que se posent les développeurs de sites. La troisième partie présente les outils au service de l’accessibilité (recommandations, outils de vérification) et explique comment les utiliser. On trouvera aussi en fin de ce guide des références d’ouvrages, d’articles ou de sites Web utiles. Liste fournie en annexe 2 – rapport d’évaluation en ligne sur le site du Ministère de la Fonction Publique : http://www.fonction-publique.gouv.fr/lareform/admelec/evaluation2001-accessibilite.htm POURQUOI RENDRE UN SITE ACCESSIBLE ? 1. L’ACCESSIBILITE UN CONCEPT GENERAL Un site Web accessible est un site auquel il est possible d’accéder de façon équivalente, quels que soient l'interface, le navigateur ou la plate-forme d'accès utilisés. En particulier un site Web accessible est compatible avec les options de personnalisation du logiciel de navigation ou de lecture du document. Cela signifie que les contenus et les fonctionnalités du service sont envisagés à la conception de manière indépendante de leur présentation finale sur écran (ou sur tout autre dispositif). Pour cela le concepteur s’efforce de séparer le contenu de la forme (ou style), grâce à des mécanismes comme les feuilles de style de HTML 4.0 (Cascading Style Sheets ou CSS). Ou encore de prévoir diverses formulations équivalentes utilisables pour véhiculer le même message (par exemple une image et son commentaire explicite). Une bonne conception d’un site en amont est la condition pour que l’adaptation nécessite en aval, sur le poste client, soit possible. 2. L’ACCESSIBILITE, UN CHOIX CITOYEN Un site accessible doit donc être compatible avec des plates-formes permettant l’accès à des personnes handicapées. L’accessibilité est un facteur d’intégration sociale, professionnelle et culturelle de ces personnes. Par exemple, les utilisateurs aveugles utilisent des ordinateurs équipés de synthèses vocales ou d'afficheurs braille. Les utilisateurs malvoyants affichent les données avec des polices de caractères, des couleurs, des contrastes adaptés. Les personnes ayant une motricité réduite des membres supérieurs, rendant difficile le maniement de la souris ou du clavier, peuvent utiliser des logiciels de reconnaissance vocale. 3. L’ACCESSIBILITE, UN CHOIX STRATEGIQUE L'accessibilité est une notion générale qui s'applique aussi bien à l’accès par des personnes handicapées, qu'à l’accès aux services par téléphone, depuis une voiture ou sur de nouvelles plates-formes techniques pour lesquelles ils n’avaient pas été conçus à l’origine. Penser l’accessibilité d’un service dès l’origine permet d’en assurer la pérennité dans un contexte d’évolution technologique permanente. Un service Web accessible repose sur une organisation logique et fonctionnelle de l’information, sans a priori sur l’interface homme-machine à mettre en place. Ainsi l’ergonomie peut plus facilement évoluer et s’adapter aux besoins de différentes catégories d’utilisateurs. 4. L’ACCESSIBILITE, UN CHOIX ECONOMIQUE Rendre un service accessible ne représente pas un coût supplémentaire si les recommandations sont intégrées lors de la conception. Concevoir un service accessible permet de réaliser plus facilement des pages claires et des sites facilement navigables. L'utilisation de feuilles de style, par exemple, améliore efficacement l'accessibilité en séparant la forme du fond, tout en permettant de gagner du temps lors de la conception d'un site. La mise à jour du site devient plus facile à mettre à jour, et par conséquent sa maintenance est moins coûteuse. Par ailleurs, signaler un site comme étant accessible renforce son image et l’image citoyenne de l’organisme qui en est responsable. 5. L’ACCESSIBILITE, UN CHOIX INTERNATIONAL Afin d'universaliser la notion d'accessibilité, le consortium W3C 2 l'initiative WAI (Web Accessibility Initiative) à laquelle participent nombreux pays. Pour la France, l'INRIA (Institut National de Informatique et Automatique) joue un rôle moteur dans cette l'association BrailleNet notamment. a mis en place des acteurs de Recherche en réflexion, avec WAI définit et publie des recommandations pour l'accessibilité. Ces recommandations font aujourd'hui l'objet d'un consensus très large et servent de référence dans de nombreux pays. Elles ont été adoptées par la Communauté européenne. Tout concepteur de site qui désire réaliser un site accessible est invité à les appliquer (pour plus d’information sur la WAI, se reporter à l’annexe 1 ) 6. LES DISPOSITIONS EN FAVEUR DES PERSONNES HANDICAPEES La Commission Européenne a annoncé officiellement sa volonté que les sites publics soient rendus accessibles selon les recommandations WAI dans les différents Etats membres (25 septembre 2001). Plusieurs pays, le Royaume-Uni, le Danemark, le Portugal notamment, ont pris des mesures dans ce sens. En France, jusqu'à présent, il n'existe pas de loi sur l'accessibilité des sites web. Cependant, le 12 octobre 2000, le Comité Interministériel de la Réforme pour l’Etat (CIRE) a pris la décision suivante : « Tous les sites Internet des services de l ’État seront rendus accessibles aux nonvoyants. Ce point sera vérifié à échéance du 30 juin 2001, dans le cadre de l’évaluation annuelle publique des sites Internet publics menée par le ministère de la Fonction publique et de la Réforme de l ’État. Le développement des services publics "en ligne "doit, par ailleurs, aller de pair avec une meilleure utilisation des autres moyens d ’information et de communication, pour rendre les services publics plus facilement accessibles à tous les citoyens. » Source : http://www.fonctionpublique.gouv.fr/lactualite/lesgrandsdossiers/cire/Cire121000relevedecision.htm 2 Le World Wide Web Consortium est une organisation internationale, chargée d’assurer l’évolution du Web, l’interopérabilité des systèmes et des technologies utilisées. Il regroupe de plus de 500 organisations membres originaires de 34 pays : http://www.w3.org 7. POPULATIONS CONCERNEES Les difficultés rencontrées lors de la consultation des sites Web peuvent être liées à différents types de déficiences : • • • déficience sensorielle (handicap visuel ou auditif), déficience motrice (myopathie, polynévrite, etc.), déficience intellectuelle ou cognitive (difficulté de concentration, de compréhension, d’apprentissage, de mémorisation, etc.). Une étude de l’INSEE, menée fin 1999, a établi que le nombre de personnes handicapées en France s’élève à plus de 5 millions de personnes. Les taux par handicap sont résumés dans le tableau suivant : Type de handicap Déficiences sensorielles Déficiences motrices Déficiences intellectuelles ou mentales Pourcentage de la population 11.4 % 13.4 % 6.6 % Sources : MORMICHE, P. Le handicap se conjugue au pluriel. INSEE Première, 2000, N° 742, Division des Enquêtes et études démographiques, Groupe de Projet HID (Handicaps-IncapacitésDépendances) Les personnes handicapées visuelles De la malvoyance à la cécité, la déficience visuelle recouvre des déficits très divers : perte d'acuité visuelle, difficulté à percevoir les couleurs, photophobie, vision tubulaire, dégénérescence maculaire chez les personnes âgées, absence totale de vision, etc.… Pour lire les pages d’un site Web, certaines personnes malvoyantes peuvent utiliser les options de personnalisation de leur navigateur ou de Windows. Mais à partir d’un certain seuil de déficience elles auront besoin d’un logiciel spécifique, souvent appelé logiciel grossissement d’écran, tel Zoomtext. La personnalisation de l’affichage permet d’améliorer la présentation du document, par un meilleur choix des couleurs, des contrastes, du type de fonte utilisée. Le grossissement n'est en fait qu’une des réponses possibles aux difficultés de lecture dues à une déficience visuelle. Les personnes aveugles, quant à elles, peuvent lire sur ordinateur grâce à des aides techniques adaptées à leur handicap, terminal braille ou synthèse vocale. Dans les deux cas, la globalité du document est perdue, de même que sa mise en page et tous ses enrichissements typographiques qui facilitent tant le parcours rapide du document. De ce fait, le document est plus difficile à appréhender et à comprendre. L'utilisateur doit en ré-assembler mentalement les fragments pour reconstituer l'information. Le logiciel utilisé peut être un logiciel de lecture d’écran, tel que JAWS qui s’ajoute au navigateur standard et pilote le terminal braille ou la synthèse de parole. Ce peut également être un navigateur non-visuel, tel HOMEPAGE READER ou BRAILLESURF3, par exemple. Plus précisément : • Les terminaux braille Ils permettent aux aveugles de lire les informations affichées à l'écran, sur un dispositif appelé "plage braille", composé de cellules piézo-électriques qui représentent en braille les lettres et les symboles. L'affichage s’effectue sur une ligne de 20, 40 ou 80 caractères, selon le modèle. En voici deux illustrations : Terminaux braille à 84 caractères (à gauche : source www.eurobraille.fr) et 40 caractères (à droite : source www.baum.fr) • Les synthèses vocales Ces logiciels permettent aux aveugles et aux malvoyants de "se faire lire" par une voix de synthèse les informations affichées à l'écran. Ces synthèses peuvent être multilingues, permettant ainsi le travail en plusieurs langues. • Les logiciels de grossissement de caractères Ils permettent à des malvoyants de lire plus confortablement l'écran en agrandissant les caractères, mais aussi en aménageant les couleurs, les contrastes, les polices, en fonction de la vue de l'utilisateur, ainsi qu'en suivant automatiquement les menus, déplacements de souris, apparition d'objets, etc. Ces différents équipements peuvent être couplés, afin d'utiliser par exemple les aptitudes à lire le braille et un reste de vision qui aidera à la mise en page. Les personnes déficientes auditives : La perte d'acuité auditive est le plus généralement graduelle, bien que des différences importantes existent en fonction des individus. Le plus souvent, elle se manifeste d'abord par des fréquences aiguës (4 000 Hz) et on n'en prend conscience que beaucoup plus tard lorsqu'elle gagne les fréquences utilisées dans la vie quotidienne. Certaines personnes atteintes d'une déficience auditive entendent des 3 Jaws est un logiciel produit par Freedom Scientific ; HomePage Reader est un logiciel produit par IBM ; BrailleSurf est un logiciel libre développé par le laboratoire INSERM-Inova de l’Université pierre et Marie Curie : http://www.snv.jussieu.fr/inova/bs4 sons mais sont incapables de distinguer les mots prononcés. D'autres n'entendent rien du tout. De l'audition normale à la surdité totale, il existe plusieurs degrés de déficience auditive : - audition normale (perte en dessous de 20 dB) - déficience légère (entre 20 et 40 dB) : Elle se manifeste lorsque l'on ne perçoit plus les sons aigus. La personne entend des sons, mais certains éléments lui échappent lorsque les interlocuteurs ne forcent pas la voix. - déficience moyenne (entre 40 et 70 dB) : On a des difficultés à tenir une conversation en groupe, écouter la télévision..."les bruits de la vie quotidienne". Seule la parole forte est perçue. A partir de 50 dB, la personne contrôle difficilement sa propre voix. - déficience sévère (entre 70 et 120 dB) : La gêne ressentie est très importante et le trouble de la parole est apparent. L'appareillage devient indispensable. - surdité totale (perte d'audition supérieure à 120 dB) : Il semble néanmoins que certains sons soient perçus, mais trop faiblement pour permettre la compréhension du message auditif. Lorsque ces personnes surfent sur le web, elles ne peuvent entendre et/ou comprendre l'information délivrée par les messages oraux (vidéo d'interview par exemple) sur les sites de radios ou musicaux, par exemple. Les aides techniques concernant ce type de déficiences se résument au fait que toutes les informations habituellement véhiculées par voie sonore doivent être converties en signaux visuels c’est-à-dire en texte, copie d’écran à visée illustrative, etc. Exemple d’aide : « se connecter à internet » : http://www.audiofr.com/informatique_connexion.asp Les personnes handicapées motrices Les différentes déficiences motrices peuvent inclure faiblesse, limitation du contrôle musculaire (comme mouvements involontaires, manque de coordination, paralysie), limitation des sensations ou membre manquant. Quelques déficiences physiques peuvent engendrer des douleurs qui gênent le mouvement. Ces conditions peuvent affecter les mains et les bras aussi bien que les autres parties du corps. Les personnes handicapées motrices ont des difficultés avec l’utilisation du clavier, la prise ou l’utilisation des systèmes de commande permettant par exemple le contrôle des ascenseurs de défilement du texte ou l’utilisation de boutons. La capacité restreinte des bras et des mains rend difficile, voire impossible, la manipulation des objets (tourner, presser…). Pour ces personnes, il existe des équipements de remplacement du clavier et de la souris, comme le clavier virtuel qui s’affiche à l’écran et permet de sélectionner de façon séquentielle les caractères à taper. En voici une illustration : Présence d’un clavier virtuel à l’écran Il existe également des claviers de remplacement avec des touches plus larges et enfoncées pour permettre un meilleur contrôle ou des souris plus faciles à manipuler et à contrôler. En voici deux illustrations : Clavier et souris adaptés Les personnes déficientes motrices peuvent aussi recourir à des logiciels de commande vocale, comme ViaVoice ou Dragon Dictate 4. Les déficients intellectuels et cognitifs 4 ViaVoice est un logiciel développé par IBM (www-3.ibm.com/software/speech/) ; Dragon Dictate est développé par la société Dragon System (www.dragonsys.com). Certaines pathologies ont des répercutions sur l’attention, la mémoire, l’apprentissage et/ou la compréhension. Avoir du mal à se focaliser sur une lecture ou à comprendre rapidement une phrase simple, laisse présager des lectures longues et fastidieuses. Ces difficultés entraînent également une fatigue générale et visuelle. Il n’y a pas, à proprement parler, d’aides techniques adaptées à ces personnes mais il est tout de même possible de leur faciliter la tâche en améliorant la qualité ergonomique du site Web en général. LES FICHES PRATIQUES BRAILLENET Ces fiches ont pour but de faciliter le travail de conception ou de réparation d’un site Web et de le rendre le plus accessible aux personnes handicapées. Elles ont été rédigées à partir des recommandations de la WAI et de l’expérience du réseau BrailleNet sur un grand nombre de sites Web. Elles s’appuient également sur une approche ergonomique très large de l’accessibilité. Les sources auxquelles elles se réfèrent sont répertoriées au sein d’une bibliographie rassemblée à la fin de ce guide. Chaque fiche comporte : • • • • Un rappel de la ou des recommandations WAI correspondantes Une explication de cette recommandation Des indications sur la méthode à suivre pour appliquer la recommandation, illustrées d’exemples Des exemples relevés sur les sites évalués par BrailleNet, constituant soit des problèmes, soit de bonnes solutions. FICHE 1 : LES IMAGES 1. RAPPEL DE LA RECOMMANDATION 1 DES WCAG 1.0 : « Fournir du contenu qui, présenté à l’utilisateur, fournit essentiellement la même fonction ou raison d’être que le contenu auditif ou visuel ». Point de contrôle : 1.1 (Priorité 1) Raisons de cette recommandation : En fonction du type d’afficheur, du système d’exploitation, des conditions d’utilisation ou des options choisies, les images peuvent ne pas apparaître. Il est donc important que tous les éléments graphiques (images, animations, images map) soient commentés, qu'ils soient des liens ou non. L’absence d’image ne doit pas entraver la compréhension générale de l’information. Le visiteur handicapé visuel, qui navigue avec un dispositif de synthèse vocale et/ou un afficheur braille, peut s’appuyer sur l'alternative textuelle. 2. CE QU’IL FAUT FAIRE La règle générale Le langage HTML 4.01 propose principalement l'attribut alt pour insérer un commentaire textuel indiquant la fonction de l'image de la manière la plus courte, précise et explicite possible. Le commentaire doit porter sur la fonction de l’image et non sur son aspect. <IMG="fichier_image.jpg" alt="commentaire de l'image"> Images liens Il s’agit d’images permettant d’activer un lien. Remplir systématiquement l’attribut "alt" associé à la balise IMG. Exemple : <IMG="fleche.gif" alt="Page précédente"> Images à zones cliquables ou réactives (images map) Une image map est une image qui possède des "zones cliquables". Remplir systématiquement l’attribut « alt » associé à la balise qui contient l'attribut "usemap" (comme à chaque image). Chaque zone cliquable (attribut "area shape") doit être renseignée par l'attribut "alt" Exemple : <IMG src="welcome.gif" alt="Carte de la France" usemap="#map1"> <MAP name="map1"> <AREA shape="rect" coords="0,0,30,30" href="calvados.html" alt="Calvados"> <AREA shape="rect" coords="34,34,100,100" href="alsace.html" alt="Alsace"> </MAP> Textes au format image Il faut transcrire la totalité du texte inclus dans l’image. L’aspect visuel des caractères ou du fond ne doit pas apparaître dans le commentaire. <IMG="logo.gif" alt="W3C-Web Accessibility Initiative"> Remarque : s’il s’agit d’un titre, utiliser l’élément H. Cette indication pourra ainsi être utilisée par un logiciel de navigation textuel : <h1><img src="..." alt="..."></h1>. Images illustratives Ces images ne sont qu’un complément d'information au texte. (Ex : la photo d'une personnalité illustrant un article) Il faut les commenter explicitement grâce à l'attribut "alt". Images à usage typographique Souvent des images sont utilisées pour mettre le document en page (images transparentes) ou faire ressortir visuellement la structure du texte (bullets). Souvent il existe des balises HTML permettant d’obtenir le même effet. Dans ce cas elles correspondent à une utilisation erronée d’HTML. Utiliser les balises HTML destinées à la mise en forme, plutôt que les images. Notamment UL, LI (Liste à puces) ; OL, LI (Liste numérotée) ; - grâce aux feuilles de style, il est possible d'associer une image appropriée à chaque type de puce et/ou numéro (voir fiche CSS) - HR (Barres horizontales) Si malgré tout vous décidez d’utiliser des images pour la mise en forme du document : • Pour les images transparentes utilisées pour décaler la position d’un bloc de texte ou d’une autre image, le commentaire sera un espace : alt=" ". • Pour des images représentant les puces ou les numéros des listes, les commentaires doivent être du type : 500g de farine 6 œufs 250g de sucre Mélangez le sucre Battez jusqu’à ce que … Incorporez la farine… <IMG="puce.gif" alt="item:">500g de farine <IMG="puce.gif" alt="item:">6 œufs <IMG="puce.gif" alt="item:"> 250g de sucre <IMG="num1.gif" alt="item1:">Mélangez… <IMG="num2.gif" alt="item2:">Battez… <IMG="num3.gif" alt="item3:">Incorporez… Les puces et les tirets peuvent aussi être commentés avec des caractères du type : «*», «-». Cette solution permet d’alléger la lecture de la page, avec un synthétiseur vocal notamment. • Pour les barres de séparation commenter par des tirets Par exemple, l’image ci-dessous est en fait une barre de séparation : <img src="barre-arbres.gif" alt="— -"> Images de fond Ce sont des images servant de décoration qui ne doivent pas contenir d’information essentielle et ne doivent pas avoir pas de valeur informative. Pour que le navigateur puisse les filtrer, utiliser l'implémentation de l’image de fond dans les feuilles de style (voir fiche CSS) Images complexes Ce sont des images nécessitant une plus longue description. Il peut s’agir par exemple d’un tableau, d’un graphique, d’un plan, d’un dessin d’humour ou de toute autre image qui ajoute de l’information au document. Note : la recommandation WCAG 1.0 indique qu'il faut utiliser l'attribut "LONGDESC" mais à l'heure actuelle, les navigateurs ne le gèrent pas. Voir la page explicative sur www.cast.org (en anglais). Exemple : <IMG src="tourisme2000.gif" alt="Les chiffres du tourisme en 2000 en France" longdesc="tourisme2000.html"> Cas des images générées par un programme CGI Utiliser l'attribut "alt" comme pour toute autre image. <IMG src="http://www.site.fr/cgi-bin/creeimg.pl" alt="commentaire fonctionnel"> 3. APPLICATION A L’AIDE DES EDITEURS HTML !"avec FrontPage Le commentaire se place dans l'emplacement « Texte » de la boîte de dialogue « propriétés de l'image » (cliquer sur l'image avec le bouton droit pour la trouver). !"avec Dreamweaver (version 3) Dans le champ "sec" (comme "secondaire") dans "Insertion/image/fenêtre/propriété !"avec WebExpert Dans la boîte de dialogue « Insérer une image graphique », placer le commentaire dans la case « Alternative ». !"avec HotMetal Pro Lors de l’insertion de l’image, placer le commentaire dans la case « Alternate Text » de la boîte de dialogue « Image Properties ». Cette boîte de dialogue peut être retrouvée par la suite en cliquant sur l’image avec le bouton droit (en mode « TagsOn » ou « WYSIWYG »). 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES • Au sein des sites de l'Académie de Strasbourg (www.ac-strasbourg.fr) et de la Cour d'Appel de Paris (www.ca-paris.justice.fr), il y a du texte sous forme d'image dont la taille ne peut être changée (voir plan du site, moteur de recherche et titres des chapitres). • Au sein du site de la Direction Régionale de l'Industrie, de la Recherche et de l'Environnement de Picardie (www.picardie.drire.gouv.fr), par exemple, il y a des images de ce type dans le cadre principal. • Commentaires peu appropriés : sur plusieurs sites, les éditeurs HTML utilisés ajoutent par défaut un commentaire aux images. Ce commentaire est peu approprié car il est de la forme : <IMG SRC="nom de l'image.gif" alt="nom image.gif (poids en octets)">. Ce commentaire n'est pas explicite, il ne donne pas d'information sur la fonction de l'image. Pour un exemple, voir le site www.legifrance.gouv.fr Le commentaire alternatif de cette image n'est pas correct FICHE 2 : LES CADRES (OU « FRAMES ») 1. RAPPEL DE LA RECOMMANDATION 12 DES WCAG 1.0 : « Fournir des informations relatives au contexte et à l’orientation pour que les utilisateurs puissent comprendre les éléments et les mises en pages complexes. » Points de contrôle : 12.1 (Priorité 1) ; 12.2 (Priorité 2) Raisons de cette recommandation L'utilisation des cadres doit être appropriée et limitée à 2, voir 3 cadres. Leur trop grand nombre et leur mauvaise utilisation gêneront les internautes n'ayant pas une vue globale de l'écran. Les visiteurs aveugles, par exemple, seront perturbés, en particulier ceux qui utilisent des navigateurs textuels comme Lynx pour Windows ou Braillesurf. L'imbrication de cadres est déconseillée car la navigation est très fastidieuse pour ce public. Le principal avantage des cadres est de permettre l’affichage d’un menu du site sur chacune des pages du site. C'est pourquoi deux ou trois cadres judicieusement et correctement utilisés sont une structure appréciée par les personnes ayant des problèmes moteurs rendant difficile l’utilisation de la souris et qui y trouvent un confort de navigation appréciable. 2. CE QU’IL FAUT FAIRE Tous les navigateurs ne permettent pas d'afficher les cadres. Utiliser l'élément HTML <NOFRAME> pour donner un contenu alternatif. En l’absence de cet élément, un navigateur incapable d'afficher les cadres montre une page rigoureusement vide. IMPORTANT : éviter de construire un site alternatif dans le "NOFRAME" mais y placer un ou plusieurs liens vers les données des frames (sinon, il se pose rapidement la question de la mise à jour). D'autre part, certains navigateurs en mode texte, présentent la liste des cadres et permettent à l'utilisateur de basculer d'un cadre à l'autre. Une personne utilisant un navigateur de ce type se repère grâce à leur nom pour se diriger vers l'un d'entre eux. Il est donc nécessaire que le titre du cadre soit en rapport avec son contenu et non avec la géographie de la page. Donner aux cadres des noms et des titres significatifs grâce à attribut "name" de l'élément FRAME (éviter par exemple « cadre1 », « cadre2 », « haut », « bas »...). Donner un titre aux documents contenus dans chaque cadre grâce à l’élément TITLE de l'en-tête. 3. APPLICATION A L’AIDE DES EDITEURS HTML !"avec FrontPage Dans la boîte de dialogue " Propriétés du cadre ", placer le nom du cadre dans la case " nom ". Utiliser ensuite l'onglet " sans cadre " pour placer le contenu de la page Alternative. !"avec Dreamweaver Dans l'onglet Modifier/jeu de cadre/modifier le contenu sans cadre. Par défaut, le code HTML affiche : <noframe> <body bgcolor="FFFFFF"> </body> </noframe> !"avec WebExpert Lors de la création des cadres, le nom du cadre est appelé " Nom identificateur du cadre ". WebExpert place ensuite correctement les éléments NOFRAMES et BODY. Il vous reste à les remplir. !"avec HotMetal Pro En mode " TagsOn " ou en mode " WYSIWYG - frames ", les noms de cadres sont définis dans la boîte de dialogue " Frame Properties ", obtenue à l'aide du menu " Frameset " (une fois un cadre sélectionné) ou bien du menu contextuel. Pour la page alternative, se placer en mode " WYSIWYG - no frames ", " TagsOn " ou " HTML source ". 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES • Au sein du site du Ministère de la Défense ( www.defense.gouv.fr), nous avons détecté un nombre très élevé de cadres imbriqués qui gênent particulièrement la navigation. Le nom de chacun de ces cadres n'est pas assez explicite. • En ce qui concerne le site du Musée Guimet (www.museeguimet.fr), 9 cadres ont été dénombrés sur la page d'accueil. FICHE 3 : LES LIENS 1. RAPPEL DES RECOMMANDATIONS 1, 9 ET 13 DES WCAG 1.0 Recommandation 1 : "Fournir du contenu qui, présenté à l'utilisateur, convoie essentiellement la même fonction ou raison d'être que le contenu auditif ou visuel". Recommandation 9 : "Utiliser des fonctions permettant l'activation des éléments d'une page grâce à différentes interfaces d'entrée". Recommandation 13 : "Prévoir des mécanismes de navigation clairs et cohérents - information d'orientation, barres de navigation, carte du site etc. - de manière à ce qu'un utilisateur puisse trouver ce qu'il cherche sur le site". Points de contrôle : 1.2 (Priorité 1) ; 1.5 (Priorité 3) ; 9.5 (Priorité 3) ; 13.1 (priorité 2) ; 13.6 (Priorité 3) Raisons de ces recommandations Un lien doit être clair, précis et concis de façon à être lu hors contexte. Ces recommandations s’appliquent aux liens sous forme de texte ou sous forme d’images. Certains utilisateurs aveugles qui n'ont pas une vision globale de l'écran se déplacent de lien en lien, pour une navigation plus rapide dans la page. Ils peuvent avoir, dans leur navigateur, la possibilité de n’afficher que les liens d'une page. La concision et la clarté des liens sont donc très importantes. 2. CE QU’IL FAUT FAIRE La formulation Veiller à donner une formulation de lien explicite quant à l'information contenue dans la page auquel il renvoie. Par exemple : les liens « cliquez ici », « pour plus d’informations », « lire »… sont à éviter. Des liens comme « cliquez ici pour accéder au plan du site » ou mieux encore « plan du site » seront plus appropriés que « cliquez ici ». La présentation Eloigner les liens les uns des autres facilite la lecture pour les personnes malvoyantes et leur activation à l’aide de la souris pour les personnes handicapées motrices. L’utilisation de l’attribut TITLE L’utilisation de l’attribut « title » permet de clarifier la destination du lien. Eviter d’utiliser le même texte de lien pour pointer vers des documents différents dans la même page. Dans le cas où il est impossible de faire autrement, les « techniques » de WCAG indiquent que si les liens ont le même intitulé mais une destination différente, il faut utiliser un contenu différent dans l’attribut « title ». Exemple de syntaxe HTML : <A href="my-doc.html">Ce document est disponible en HTML</A>, <A href="my-doc.pdf" title="document en PDF">Lire l'article</A>, <A href="my-doc.txt" title="document en txt">Lire l'article</A> Lorsque l’on passe la souris sur le lien, on lira l’explicatif de l’attribut <title>, et celui-ci pourra également être lu par les synthèses vocales. 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES • Sur le site de l’Agence de Sûreté Nucléaire (www.asn.fr) on trouve des informations d’actualité suivies des liens « cliquez ici ». Comme ils pointent vers des pages différentes il n’est pas possible de savoir, lorsque l’on navigue de lien en lien, de quelle information il s’agit. Il serait préférable de mettre le lien sur le titre de la brève et non sur cliquez ici. Une autre solution serait d’utiliser l’attribut « title » évoqué précédemment. • Sur le site de l’Education Nationale (www.education.gouv.fr), on trouve des liens ayant le même nom menant vers des pages différentes. FICHE 4 : LES FEUILLES DE STYLE (CASCADING STYLE SHEETS) 1. RAPPEL DES RECOMMANDATIONS 3 ET 6 DES WCAG 1.0 Recommandation 3 : "Utiliser le balisage et les feuilles de style de manière appropriée." Point de contrôle : 3.3 (Priorité 2) « Utilisez les feuilles de style pour contrôler la présentation et la mise en page. » Point de contrôle : 3.4 (Priorité 2) « Utilisez des unités relatives plutôt qu'absolues dans les valeurs d'attributs du langage de balisage et les valeurs des propriétés des feuilles de style. » Recommandation 6 : "Veiller à ce que les pages qui utilisent les nouvelles technologies se transforment de façon élégante." Point de contrôle : 6.1 (Priorité 1) « Organisez les documents de façon à ce qu'ils puissent être lus sans feuilles de style. Par exemple, quand un document HTML est interprété sans les feuilles de style associées, il doit toujours être possible de lire le document. » Raisons de cette recommandation Chaque navigateur est libre d'utiliser ou non les indications de forme (taille des caractères, fontes, styles,...). Dans le cas des logiciels pour aveugles et malvoyants, ces indications sont le plus souvent inutiles. Il faut simplement veiller à ce que les documents soient utilisables par un navigateur ne supportant pas ces feuilles de styles (il suffit pour cela de placer la feuille de style dans un fichier «.css» ou bien de placer les styles dans un commentaire au début du document). 2. CE QU’IL FAUT FAIRE La règle générale L'utilisation de feuilles de style améliore efficacement l'accessibilité en séparant la forme du fond, tout en permettant de gagner du temps lors de la conception d'un site. La structure du document et sa forme doivent être traitées séparément. La structure est spécifiée grâce aux éléments et attributs HTML (titres, sous- titres, paragraphes, images,...), la mise en page à l'aide de feuilles de style (choix typographiques, couleurs, espacements...). Cette séparation nette de la forme et du fond permet aux navigateurs non visuels d'extraire plus facilement la structure logique du document. Elle offre aussi plus de liberté aux concepteurs de pages visuelles dans la mise en page (les feuilles de style offrent beaucoup plus de possibilités que HTML). En HTML, les feuilles de style peuvent être spécifiées de façon externe par l'élément LINK, dans l'entête du document par l'élément STYLE ou pour un élément spécifique par l'attribut style. Exemple : (styles définis de façon externe) Exemple : (styles définis de façon interne) <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html lang="fr"> <head> ... <link rel="stylesheet" type="text/css" href="style.css"> </head> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html lang="fr"> <head> ... <style type="text/css">< !-... Les propriétés de style sont définies ici. --></style> </head> Les propriétés de style sont définies dans le fichier ‘style.css’. Les feuilles de style permettent de contrôler les caractéristiques des polices : "fontfamily", "font-size", "font-size-adjust", "font-stretch", "font-style", "font-variant", et "font-weight" ; les couleurs : "color", pour la couleur de premier plan du texte, "background-color", pour les couleurs de fond, "border-color", "outline-color" pour les couleurs de bordure (pour les couleurs de liens, voir les pseudo classes : link, : visited, et : active) ; les images de fond : "background-image", "background-repeat" ; les marges : "margin-left", "margin-right", "margin-top", "margin-bottom" ; les images intégrées aux puces de listes : "list-style" ; et de très nombreuses autres propriétés... Exemple : P.important { font-weight: bold } P.moins-important { font-weight: lighter; font-size: smaller } H2.soussection { font-family: Helvetica, sans-serif } A.titre:link,A.titre:visited {COLOR: #FFFFFF; textdecoration:none; } A.titre:hover {text-decoration: underline; font-size: 2 em; color: #000000; background-color: #FFFFFF; } BODY {background-image: url(images/background.jpg); background-repeat: repeat-y; font-family: arial; } Le site http://www.w3.org donne la spécification complète des feuilles de styles5. 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES Le site de l'Agence Nationale pour l'Emploi (www.anpe.fr) et le site du Ministère de l'Environnement (www.environnement.gouv.fr) présentent deux bons exemples d'utilisation des feuilles de style. 5 http://www.w3.org/TR/REC-CSS2 FICHE 5 : LES TABLES 1. RAPPEL DES RECOMMANDATIONS 5 ET 10 DES WCAG 1.0 : Recommandation 5 : « Assurez-vous que vos tables possèdent les balises nécessaires pour être interprétées par les logiciels de consultation existants et autres agents utilisateurs. » Recommandation 10 : « Utiliser des solutions d'accessibilité intermédiaires, de manière à ce que les technologies d'assistance et les anciens navigateurs fonctionnent correctement. » Points de contrôle : 5.1 (Priorité 1) ; 5.2 (Priorité 1) ; 5.3 (Priorité 2) ; 5.4 (Priorité 2) ; 5.5 (Priorité 3) ; 5.6 (Priorité 3) ; 10.3 (Priorité 3) Raisons de ces recommandations On rencontre deux sortes de tableaux : les premiers sont utilisés à des fins de mise en forme du texte ; les deuxièmes sont utilisés pour présenter des données. Lorsqu’une page est construite à l’aide de tableaux, la façon dont ces tableaux sont agencés peut rendre la compréhension de la page difficile, voir impossible, pour une personne qui n’a pas une vue globale de cette page. C’est pourquoi certaines précautions doivent être prises lors de la construction de telles pages. D’autre part, certains tableaux sont complexes car ils représentent des statistiques, des données. Ils sont également longs à décoder lorsque l’internaute n’a pas de vision globale du tableau. Il faut donc s’assurer que ces tableaux sont linéarisables (lisibles ligne à ligne) ou il faut envisager une alternative afin d’en faciliter la lecture et l’extraction d’informations. 2. CE QU’IL FAUT FAIRE La règle générale Eviter d’utiliser des tables pour la mise en page sauf si nécessaire. Si c’est le cas, créez des sommaires pour les tables et n’utilisez pas de balises structurelles dans un but de formatage visuel. Tables utilisées pour la forme Si les tableaux sont nécessaires pour la mise en page, il faut qu’ils aient un sens lorsqu’ils sont déchiffrés en mode linéaire. Il faut utiliser les feuilles de style pour la mise en page et le positionnement des éléments de contenu. Toutefois, lorsqu’il faut utiliser un tableau pour la mise en page, les contenus du tableau doivent être faciles à comprendre lorsqu’ils se transforment en une série de paragraphes. Il faut recourir au balisage des feuilles de style pour la mise en page, le positionnement et le formatage du contenu des cellules. Ne pas utiliser d’éléments BRAILLENET 08/04/02 26 de tableau qui sont destinés à fournir une signification sémantique pour tout simplement accentuer un texte. L’utilisation inadéquate d’éléments de tableau, tels que l’élément <th>, peut entraîner des résultats tout à fait inattendus chez certains dispositifs Web. Les tableaux de données Il peut être utile de proposer un résumé du contenu du tableau. Ceci est possible à l’aide de l’attribut <summary>. L’attribut <title> de l’élément <table> permet également de donner une brève explication du contenu du tableau. Afin de permettre aux utilisateurs qui ne voient pas le tableau dans son ensemble de mieux se repérer, il faut identifier clairement les colonnes et les rangées du tableau. L’utilisation de balises spécifiques dans les tableaux permettra par exemple aux synthèses vocales de lire le titre de la colonne ou de la ligne associée à une cellule donnée. L’attribut « header » des éléments « td » et « th » permet de telles associations. Plusieurs exemples sont donnés par les techniques pour l’application des WCAG à propos des tableaux accessibles, et le curriculum sur le site de WAI. Utiliser des balises pour l’association des cellules de données avec les cellules d’entête (ex : utiliser THEAD, TFOOT, TBODY pour regrouper les lignes). Pour clarifier la signification des données dans les tableaux complexes (c’est-à-dire les tableaux qui ont deux niveaux logiques ou plus d’en-tête de colonne ou de ligne), utiliser des éléments de balisage pour associer les données des cellules individuelles avec les en-têtes de leur rangée et de leur colonne respectives. Si un tableau est bien construit, il est possible d’utiliser un outil qui permette de les linéariser. Le W3C propose un outil appelé Tablin que l’on trouve à l’adresse : http://www.w3.org/WAI/References/Tablin/ 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES • Au sein du site de la Préfecture du Rhône par exemple (www.rhone.pref.gouv.fr), les tableaux de données sont nombreux et pas très pratiques à consulter avec un navigateur non visuel. • En ce qui concerne le site de la Préfecture de la Manche (www.manche.pref.gouv.fr), l’adresse de la Préfecture se trouve au milieu des liens lorsque l’internaute utilise un navigateur non visuel. • Sur le site du Ministère de la culture (www.culture.gouv.fr), nous avons constaté l’existence de tableaux simples et faciles à lire linéairement (voir un exemple sur la page : http://www.culture.fr/culture/dep/mini_chiff_00/fr/disq.htm). BRAILLENET 08/04/02 27 FICHE 6 : LES FORMULAIRES 1. RAPPEL DE LA RECOMMANDATION DES WCAG 1.0 Il n’y a pas de recommandation spécifique aux formulaires dans les WCAG mais plusieurs points de contrôle traitent des formulaires. Points de contrôle : 10.2 (Priorité 2) ; 12.4 (Priorité 2) ; 9.4 (Priorité 3) ; 9.5 (Priorité 3) ; 10.4 (Priorité 3) Raisons de cette recommandation Un formulaire construit de façon incorrecte entraîne des difficultés de compréhension et de navigation. 2. CE QU’IL FAUT FAIRE La règle générale Veiller à organiser logiquement les éléments d'un formulaire, les identifier clairement et s'assurer que la technologie utilisée pour la validation est accessible avec tous les navigateurs. Accéder au formulaire grâce au clavier • Spécifier l’ordre de circulation avec la touche TABULATION Il est possible de spécifier l'ordre de tabulation au sein des éléments (par ordre, "champ2", "champ1", "submit") avec "tabindex". Exemple : <FORM action="submit" method="post"> <INPUT tabindex="2" type="text" name="champ1"> <INPUT tabindex="1" type="text" name="champ2"> <INPUT tabindex="3" type="submit" name="submit"> </FORM> Donner un nom explicite aux contrôles des formulaires Utiliser la balise "LABEL" (reliée aux champs correspondant grâce aux attributs "for" et "id", voir exemple ci-dessous). Exemple : <LABEL for="firstname">First name : </LABEL> <INPUT type="text" id="firstname" tabindex="1"> BRAILLENET 08/04/02 28 • Fournir des raccourcis clavier pour les formulaires L’exemple suivant spécifie "ALT + U" comme raccourci (utilisation d’"accesskey"). Ce raccourci amène directement au champ de saisie où l'utilisateur peut saisir le texte. Exemple : <FORM action="submit" method="post"> <LABEL for="user" accesskey="U">name</LABEL> <INPUT type="text" id="user"> </FORM> Grouper les contrôles des formulaires Grouper l'information lorsque c'est naturel et approprié. Quand les contrôles de formulaire peuvent être groupés en unités logiques, utiliser l'élément «FIELDSET » et donner un nom à ces unités avec l'élément « LEGEND » Exemple : <FORM action="http://somesite.com/adduser" method="post"> <FIELDSET> <LEGEND>Personal information</LEGEND> <LABEL for="firstname">First name: </LABEL> <INPUT type="text" id="firstname" tabindex="1"> <LABEL for="lastname">Last name: </LABEL> <INPUT type="text" id="lastname" tabindex="2"> ...more personal information... </FIELDSET> <FIELDSET> <LEGEND>Medical History</LEGEND> ...medical history information... </FIELDSET> </FORM> L'information est groupée grâce à l'élément "FIELDSET" BRAILLENET 08/04/02 29 Validation des formulaires Eviter la vérification ou la validation d'un ou plusieurs éléments d'un formulaire (champ de saisie ou bouton de validation par exemple) à l'aide de JavaScript. Il est préférable de mettre en place des mécanismes de vérification et de validation directement au niveau du serveur. Permettre la validation d’un champ de saisie par la touche entrée (focus sur le bouton de validation). • Formulaires validés côté client par JavaScript / Formulaires validés côté serveur par CGI (PHP, ASP…) Les formulaires permettent le plus souvent de récupérer des informations concernant les internautes, en vue de leur envoyer des e-mails ou des courriers postaux (exemple : formulaire d’inscription). Le rôle du script est de vérifier les informations saisies par l‘internaute afin de contrôler le format ou le contenu. Pour cela, il y a deux solutions : valider les champs de saisie sur le poste client ou les valider après soumission sur le serveur. Sur le poste client (l’ordinateur de l’internaute), le seul moyen de valider les champs est d’utiliser du JavaScript, car ce langage est interprété par les navigateurs les plus courants tels que Internet Explorer ou Netscape. L’avantage de cette solution est d'éviter les allers-retours avec le serveur, la surcharge de celui-ci. Elle permet à l’internaute de remplir correctement et rapidement un formulaire. Cependant, l’inconvénient principal de ce langage est qu'il n’est pas interprété par certains logiciels, les navigateurs textuels notamment (Lynx, Braillesurf…). Ces derniers sont souvent utilisés par les déficients visuels pour leur simplicité de navigation et de présentation de l’information. Donc, pour un internaute navigant avec ce type de logiciel, ces formulaires sont inaccessibles car le Javascript n’étant pas interprété, le formulaire ne peut être validé ce qui rend souvent l’inscription impossible. Côté serveur, on peut aussi vérifier la validité des champs de saisie et renvoyer la page avec les champs non ou mal, remplis ainsi que des indications afin de mieux remplir ces derniers. L’inconvénient est que cette méthode risque, en cas d’affluence sur le site, de faire ralentir le serveur (dans le cas où un grand nombre de personnes seraient connectées sur le même formulaire, et validant ce dernier au même instant). Le gros avantage de cette méthode est qu’elle ne pose aucun problème au navigateur puisqu’elle est exécutée sur le serveur. Ainsi, les informations transmises sont de simples pages HTML qui sont accessibles à tous. Conclusion : il faut faire les deux. Vérifier les informations sur le serveur même s'il y a une vérification en JavaScript. BRAILLENET 08/04/02 30 Exemple de code source : Source d’un formulaire validé côté serveur ( code source PHP). Seuls les champs mal remplis sont demandés à nouveau (dans l'exemple, on vérifie si le code postal est bien une suite de chiffres). <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML lang="fr"> <HEAD> <META http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <TITLE>Formulaire</TITLE> <LINK rel="stylesheet" type="text/css" href="my.css"> </HEAD> <BODY> <FORM action="formulaire.htm" method="POST" name="formulaire" enctype="multipart/form-data" title="Formulaire d'inscription"> <TABLE> <?php if (!$nom) {?> <TR> <TD>Nom :</TD> <TD><INPUT TYPE="TEXT" name="nom"></TD> </TR> <?php } else { echo "<INPUT TYPE=\"hidden\" name=\"nom\" value=\"$nom\">";}?> <?php if (!$prenom) {?> <TR> <TD>Prénom :</TD> <TD><INPUT TYPE="TEXT" name="prenom"></TD> </TR> <?php } else { echo "<INPUT TYPE=\"hidden\" name=\"prenom\" value=\"$prenom\">";}?> <?php if (!$email) {?> <TR> <TD>Email :</TD> <TD><INPUT TYPE="TEXT" name="email"></TD> </TR> <?php } else { echo "<INPUT TYPE=\"hidden\" name=\"email\" value=\"$email\">";}?> <?php if (!$adresse) {?> <TR> <TD>adresse :</TD> <TD><INPUT TYPE="TEXT" name="adresse"></TD> </TR> <?php } else { echo "<INPUT TYPE=\"hidden\" name=\"adresse\" value=\"$adresse\">";}?> <?php if (!$cp || !ereg("^[0-9]{5}$",$cp)) {?> <TR> <TD>CP <?php if ($cp!="" && !ereg("^[0-9]{5}$",$cp)) echo "Votre Code Postal doit être composé de 5 chiffres !!!" ?> : </TD> <TD><INPUT TYPE="TEXT" name="cp"></TD> </TR> <?php } else { echo "<INPUT TYPE=\"hidden\" name=\"cp\" value=\"$cp\">";}?> <?php if (!$ville) {?> <TR> <TD>Ville :</TD> <TD><INPUT TYPE="TEXT" name="ville"></TD> </TR> <?php } else { echo "<INPUT TYPE=\"hidden\" name=\"ville\" value=\"$ville\">";}?> </TABLE> <INPUT TYPE="SUBMIT" </FORM> value="Valider"> </BODY> </HTML> BRAILLENET 08/04/02 31 Résultat avec Internet Explorer : Le formulaire est renseigné. Il y a une erreur dans le champ "Code Postal" Le message d'erreur est une page HTML simple renvoyée par le serveur 3. APPLICATION A L’AIDE DES EDITEURS HTML A l'heure actuelle, des attributs HTML comme "legend", "label"… ne sont pas intégrés dans les éditeurs HTML les plus courants. Ils sont à implémenter manuellement, directement dans le code source des pages. !"Avec Frontpage Utiliser l'onglet approprié. !"Avec Dreamweaver F10 pour obtenir le code source de la page. 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES Le site de la Caisse des Allocations Familiales (www.caf.fr) fournit plusieurs bons exemples de formulaires accessibles aussi bien grâce à leur système de validation que dans leur conception visuelle. BRAILLENET 08/04/02 32 FICHE 7 : LES SCRIPTS 1. RAPPEL DES RECOMMANDATIONS 6 ET 8 DES WCAG 1.0 : Recommandation 6 : « S'assurer que les pages sont accessibles même lorsque les dernières technologies ne sont pas supportées ou sont désactivées. » Recommandation 8 : « S'assurer que l'interface utilisateur respecte les principes d'accessibilité : Accès aux fonctionnalités indépendant du type d'interface-utilisateur, accès depuis le clavier, commandes vocales etc. » Recommandation 9 : « Utiliser des fonctions permettant l'activation des éléments d'une page grâce à différentes interfaces d'entrée. » Points de contrôle : 6.3 (Priorité 1) ; 6.4 (Priorité 2) ; 8.1 (Priorité1) ; 9.3 (Priorité 2) Raisons de ces recommandations Certains éléments de navigation comme des liens, des listes déroulantes ou menus, des boutons de validation de formulaire sont gérés par des scripts s'exécutant dans le navigateur client. Rappelons que les navigateurs textuels ne les interprètent pas et que nombre d'utilisateurs désactivent cette fonction dans leur navigateur. Les scripts qui s'exécutent sur le serveur sont plus accessibles que les scripts qui s'exécutent dans le navigateur client (Javascript Vbscript....). Ces options techniques respectent la grande diversité des plates-formes et des interfaces utilisées ; elles permettent une grande interactivité des sites et de produire des pages HTML dynamiques tout en envoyant au logiciel du visiteur du HTML respectant les normes d'accessibilité du WAI. Les scripts exécutés du côté client entravent la navigation de certains internautes. Ils provoquent dans la majorité des cas une altération ou une perte d'informations préjudiciables à une bonne accessibilité, si une alternative n'est pas présente dans le même document. 2. CE QU’IL FAUT FAIRE La règle générale Veiller à ce que l’information soit présente, accessible même sans les scripts. Les scripts et applets BRAILLENET 08/04/02 33 !"Prévoir systématiquement une solution alternative utilisant le HTML, basée sur des scripts côté serveur. !"Utiliser l'élément « noscript » afin que l’information contenue dans le script soit accessible. !"Eviter la vérification ou la validation d'un ou plusieurs éléments d'un formulaire (champ de saisie ou bouton de validation par exemple) à l'aide de Javascript. Il est préférable de mettre en place des mécanismes de vérification et de validation directement au niveau du serveur. Note : S'assurer donc que tout élément de la page peut être activé d'une manière indépendante d'un matériel spécifique. Pour les scripts, il importe de spécifier des gestionnaires d'événements logiques plutôt que des gestionnaires dépendants du matériel. Exemple : Code HTML d'une liste déroulante gérée par du JavaScript. L'information contenue dans la balise "noscript" reprend exactement les éléments de la liste. Il n'y a pas de perte d'information. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html lang="fr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>Liste déroulante accessible</title> <link rel="stylesheet" type="text/css" href="my.css"> </head> <body> <center> <H1>Exemple de liste déroulante actionnée avec du JavaSsript</H1> navigateur : Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)<br> <SELECT ONCHANGE="window.open(this.options[this.selectedIndex].value,'_top')"> <OPTION value="http://www.voirplus.net">Voirplus.net</OPTION> <OPTION value="http://www.urbilog.fr">Urbilog.fr</OPTION> <OPTION value="http://www.yahoo.fr">Yahoo.fr</OPTION> </SELECT> <noscript> <BR><BR> Liste déroulante inactive<br> Voici les liens se trouvant dans la liste déroulante<BR> <A href="http://www.voirplus.net">Voirplus.net</A><BR> <A href="http:// www.urbilog.fr">Urbilog.fr </A><BR> <A href="http://www.yahoo.fr">Yahoo.fr</A><BR> </noscript> </center> </body> </html> name="liste" La liste déroulante gérée par un script JavaScript BRAILLENET 08/04/02 34 Le champ "noscript" reprend sous forme d'une liste de liens textuels, la liste des liens présents dans la liste déroulante : l'information est complètement restituée 3. APPLICATION A L’AIDE DES EDITEURS HTML A l'heure actuelle, les outils les plus utilisés comme FrontPage et Dreamweaver ne proposent pas encore dans leurs menus d'utiliser la balise alternative "noscript". 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES !"Des listes déroulantes gérées par un script sont présentes sur les sites de l’ANPE (www.anpe.fr), de l’Académie de Strasbourg (www.ac-strasbourg.fr), par exemple. !"Sur certains sites (www.cada.fr ; www.minefi.gouv.fr) nous avons aussi des liens activables par du javascript. !"Le site de la surêté nucléaire (www.asn.gouv.fr) présente des scripts qui permettent l’affichage d’information complémentaire sur un lien lorsque l’on passe la souris sur celui-ci. BRAILLENET 08/04/02 35 FICHE 8 : TECHNOLOGIE FLASH, APPLETS, OBJETS MULTIMEDIA 1. RAPPEL DE LA RECOMMANDATION 6 DES WCAG 1.0 « S'assurer que les pages sont accessibles même lorsque les dernières technologies ne sont pas supportées ou sont désactivées. » Cette formulation générale peut se traduire concrètement par la vérification que des technologies comme Flash et applets Java - censées améliorer l’attrait graphique du site – ne conduisent pas à des pertes d’information pour les personnes handicapées. Point de contrôle : 6.3 (priorité 1) On vérifiera en particulier que "les pages restent accessibles lorsque les dernières technologies ne sont pas gérées par le navigateur ou sont désactivées" Raisons de cette recommandation Les personnes ayant des atteintes motrices ou cognitives peuvent être perturbées par les versions flash, car celles-ci provoquent une gêne et une grande fatigue visuelle (trop rapides, trop de mouvements, trop de clignotements, etc.). Pour une consultation non visuelle, et pour les aveugles en particulier, une page ou a fortiori un site, développés en Flash, sont complètement inaccessibles. 2. CE QU’IL FAUT FAIRE La règle générale Mettre en place une solution alternative basée sur des éléments HTML standards et accessibles à tous. Faire en sorte que les deux versions HTML et Flash soient identiques dans leur contenu et mises à jour simultanément. Pour les animations Flash • Si une page contient une animation flash Mettre en place une solution alternative accessible. Le fichier Flash peut être introduit entre les balises <OBJECT>...</OBJECT>, le contenu alternatif doit alors se situer entre ces deux balises. Le fichier Flash peut être introduit entre des balises <EMBED>...</EMBED>, l'alternative doit être située entre les balises <NOEMBED>...</NOEMBED>. Pour être compatible avec les navigateurs Netscape, la balise <EMBED> doit elle-même être introduite par la balise <OBJECT>. • Si le site est entièrement en flash Il faut prévoir une version HTML accessible et veiller à sa mise à jour simultanée. L'accès à la version "sans flash" doit se faire sous forme de lien explicite utilisable par tous. BRAILLENET 08/04/02 36 • Si seule la page d'accueil est en flash Prévoir une page d’accueil en HTML et un lien explicite, facile d'accès vers celle-ci dans la page flash. Exemple : <OBJECT classid="clsid:A12BCD3F-GH4I-56JK-xyz" codebase="http://example.com/content.cab" width=100 height=80> <PARAM name="Movie" value="moviename.swf"> <EMBED src="moviename.swf" width=100 height=80 pluginspage="http://example.com/shockwave/download/"> </EMBED> <NOEMBED> <IMG alt="Still from Movie" src="moviename.gif" width=100 height=80> </NOEMBED> </OBJECT> Pour les applets Java Si les balises <OBJECT>...</OBJECT> sont utilisées, fournir un équivalent textuel dans le contenu de l'élément. Exemple : <OBJECT classid="java:Press.class" width="500" height="500"> As temperature increases, the molecules in the balloon... </OBJECT> Si la balise <APPLET> est utilisée, fournir un équivalent textuel avec l'attribut "alt" et dans le contenu de l'élément APPLET. Ceci permet au contenu de se transformer aisément pour les logiciels qui ne gèrent que l'un des deux mécanismes ("alt" ou contenu). Exemple : <APPLET code="Press.class" width="500" height="500" alt="Java applet: how temperature affects pressure"> As temperature increases, the molecules in the balloon... </APPLET> Il est important de distinguer deux cas : • Le cas d'un applet comme celui qui est montré en exemple ici avec un simple commentaire. BRAILLENET 08/04/02 37 • Le cas d'un applet qui a un rôle précis et qui doit être remplacé de façon alternative. Exemple : <OBJECT classid="java:sommaire.class" width="200" height="500"> <h2>Sommaire</h2> <ul> <li><a href="index.html">Page d'accueil</a> <li><a href="actu.php">Actualités</a> ... </ul> </OBJECT> 3. APPLICATION A L’AIDE DES EDITEURS HTML Pour le flash : Très peu d’éditeurs HTML proposent de gérer les balises alternatives au Flash. Il faut alors implémenter ces balises à la main. Pour les applet : !"avec Frontpage Dans Insertion/Avancées/Applet Java/ Remplir le champ /Message pour les navigateurs qui ne gèrent pas les applets/. Donner un résumé ou la liste des éléments contenus dans l'applet. !"avec Dreamweaver (version 3) Dans Insertion/Médias/appliquette/propriété. Puis le champ "sec". Donner un résumé ou la liste des éléments contenus dans l'applet. 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES • Au sein du site de l'Agence pour la Sûreté Nucléaire (www.asn.gouv.fr), certaines pages du site contiennent du Flash sans alternative. • Sur les sites de l'Institut National de la Propriété Industrielle (www.inpi.fr) et du Conseil Supérieur de l'Audiovisuel (www.csa.fr), il y a des animations en Flash sans alternative sur la page d'accueil. • Le site de la Préfecture de la Manche (www.manche.pref.gouv.fr) utilise des applets Java, sans alternative, pour afficher son menu. Il n'est donc accessible ni aux utilisateurs ayant désactivé les scripts dans leur navigateur ni aux personnes handicapées visuelles. BRAILLENET 08/04/02 38 FICHE 9 : PRESENTATION VISUELLE 1. RAPPEL DES RECOMMANDATIONS 2, 3, 6 ET 7 DES WCAG 1.0 Recommandation 2 : « S'assurer que les textes et graphiques sont compréhensibles quand on les visualise sans couleur. » Recommandation 3 : « Baliser les documents avec les éléments structurants appropriés. Contrôler la présentation avec des feuilles de style plutôt qu'avec des éléments et des attributs de présentation. » Recommandation 6 : « S'assurer que les pages sont accessibles même lorsque les dernières technologies ne sont pas supportées ou sont désactivées. » Recommandation 7 : « S'assurer que les fonctions permettant de faire bouger, clignoter, défiler ou mettre à jour automatiquement des objets ou des pages puissent être mises en pause ou stoppées. » Points de contrôle : 2.1 (Priorité 1) ; 2.2 (Priorité 2) ; 6.1 (Priorité 1) ; 7.2 (Priorité 2) ; 3.4 (Priorité 2) Raisons de ces recommandations Les personnes souffrant de troubles de perception des couleurs et celles utilisant un écran noir et blanc doivent accéder à toute l’information sur le site Web. Ceci inclut notamment le texte, les images et les outils pour la navigation. 2. CE QU’IL FAUT FAIRE La règle générale Il faut vérifier la présentation du contenu à l’écran c’est-à-dire voir si le contenu est bien lisible sous certaines conditions, si le contenu apparaît en entier sur l’écran, si l’on peut accéder à toute l’information de la page, … Contrastes Vérifier que les contrastes sont suffisants entre le premier plan et l’arrière plan. Les contrastes doivent être bien marqués pour une bonne lisibilité des liens ou de l’information. Trop peu de contraste aboutit rapidement à une fatigue visuelle. BRAILLENET 08/04/02 39 Information transmise Vérifier que l’information transmise par les couleurs est également accessible sans couleur, et que le site est toujours lisible en noir et blanc. Ne pas surcharger une page. Trop d’information nuit à l’information. Taille des images Vérifier la taille des images car suivant la taille, le poids des images, elles peuvent alourdir le téléchargement. Eviter de mettre l'information textuelle sous forme d'images dont on ne peut pas régler la taille des caractères. Points à vérifier !"Vérifier la présentation en utilisant la plus petite résolution. !"Veiller à ce que les pages soient lisibles sans les feuilles de style CSS (Avec IE : outils – options internet – accessibilité – cocher les cases « Mise en forme »). Certains navigateurs ne peuvent utiliser les feuilles de style (CSS). Les développeurs de contenus doivent donc vérifier les styles des CSS avec un outil tel que le CSS Validator (système de validation des CSS) de W3C et s’assurer que les utilisateurs peuvent avoir accès aux caractéristiques des documents et des présentations lorsque les feuilles de style sont désactivées ou non supportées. !"Eviter la présence de contenus clignotants. !"Vérifier que le grossissement des caractères est possible (Avec IE : affichage – taille du texte). De manière générale, il est déconseillé d’utiliser des polices trop petites pour garder une qualité de lissage suffisant. !"Veiller à l’utilisation de valeurs relatives en pourcentage plutôt que de valeurs absolues en pixels pour dimensionner un élément. Lorsqu’un document ou une feuille de style utilise des pourcentages et des tailles de police ‘em’ pour établir les unités de mesure, les utilisateurs peuvent changer facilement les unités à l’aide de leur navigateur. !"Vérifier l’homogénéité, la cohérence du site (respect de la charte graphique sur tout le site). !"Vérifier que les tableaux gardent leurs contours lors de la suppression des couleurs de fond. !"Eviter de rendre nécessaire l’utilisation d’une barre de défilement horizontal. Eviter également les ascenseurs au milieu des pages. BRAILLENET 08/04/02 40 !"Vérifier les menus « Javascript » transparents (risque de superposition de texte). 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES • Sur le site de la Cour d’Appel de Paris (www.ca-paris.justice.fr), à la rubrique actualités, le contraste est insuffisant (texte gris clair, sur fond blanc). Le site de l’Académie de Strasbourg (www.ac-strasbourg.fr) manque également de contrastes. • Le site de l’Agence pour la Sûreté Nucléaire (www.asn.gouv.fr) utilise un gif animé qui affiche une information difficilement accessible. Cette image est perturbante pour les personnes ayant des difficultés de concentration. BRAILLENET 08/04/02 41 FICHE 10 : LES ELEMENTS SONORES 1. RAPPEL DE LA RECOMMANDATION 1 DES WCAG 1.0 : « Fournir du contenu qui, présenté à l’utilisateur, convoie essentiellement la même fonction ou raison que le contenu auditif ou visuel. » Points de contrôle : 1.1 (Priorité 1) Raisons de cette recommandation De même que pour les images, les contenus auditifs doivent être commentés textuellement afin que les personnes déficientes auditives (mal entendantes et sourdes) puissent accéder à l'information contenue dans ces versions phoniques. Les équivalents textuels des présentations multimédias basées sur le temps doivent être synchronisés avec la présentation. 2. CE QU’IL FAUT FAIRE La règle générale Commenter les contenus auditifs (ex : une interview sur un site de radio). Lorsqu’un lien mène vers un fichier son, il est possible de commenter ce lien en rajoutant une image commentée avec l’attribut « alt ». Dans cet attribut, il pourrait y avoir le contenu de ce fichier son. Si le contenu du fichier son est long, il est possible d’ajouter une description longue à l’aide de l’attribut « longdesc ». Longedesc permet à l’utilisateur de cliquer sur un lien menant vers une page alternative qui expliquera le contenu du fichier son. « alt » et « longdesc » permettent une description statique de la bande son d'une vidéo. Elles ne sont pas adaptées à une alternative textuelle défilant en même temps qu’un contenu audio. Pour cela, il faut utiliser une fonctionnalité de l'outil de création du contenu audio lui-même. 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES • Sur le site du Musée National des Arts Asiatiques – Guimet (www.museeguimet.fr), des extraits sonores sont présents dans la visite virtuelle du musée. BRAILLENET 08/04/02 42 FICHE 11 : CONTROLE DE CHANGEMENTS DU CONTENU L'UTILISATEUR SUR LES 1. RAPPEL DE LA RECOMMANDATION 7 DES WCAG 1.0 « S'assurer que les fonctions permettant de faire bouger, clignoter, défiler ou mettre à jour automatiquement des objets ou des pages puissent être mises en pause ou stoppées. » Points de contrôle : 7.1 (Priorité 1) ; 7.2 (Priorité 2) ; 7.3 (Priorité 2) ; 7.4 (Priorité 2) ; 7.5 (Priorité 2) Raisons de cette recommandation Les animations perturbent la lecture : par réflexe, l’œil est attiré ce qui entraîne une gêne et une fatigue visuelle dans l’exploration des pages et du site. A l’extrême, certaines personnes souffrant d’épilepsie causée par une sensibilité particulière à la lumière peuvent avoir des crises déclenchées par des scintillations ou des clignotements. Certaines personnes ont des difficultés à lire un texte lorsqu'il bouge. Les mouvements peuvent causer une telle distraction que le reste de la page peut devenir illisible pour des gens souffrant d’un handicap cognitif. Les logiciels de lecture d'écran ne peuvent lire un texte en mouvement. Certaines personnes souffrant d’un handicap physique pourraient ne pas être en mesure de bouger suffisamment vite ou précisément pour interagir avec des objets en mouvement. 2. CE QU’IL FAUT FAIRE La règle générale Il doit être possible de stopper ou mettre en pause les animations clignotantes, les textes défilants, etc. Gifs animés Un gif animé est une image contenant des informations en mouvement. Technique : http://www.w3.org/TR/WCAG10-HTML-TECHS/#animated-images Clignotements (mot ou dessin) et mouvements (texte défilant) Textes défilants ou clignotant (ex : nouveau), auto-rafraichissements sont à proscrire. Il perturbe le champ visuel de l’internaute et provoque une gêne pour la prise de connaissance des autres informations. BRAILLENET 08/04/02 43 Techniques à consulter : http://www.w3.org/TR/WCAG10-CORE-TECHS/#video-information Pour les effets de style de texte : http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-text Pour obtenir des applets accessibles : http://www.w3.org/TR/WCAG10-HTML-TECHS/#accessible-applets Pour les scripts engendrants mouvement et clignotement : http://www.w3.org/TR/WCAG10-HTML-TECHS/#scripts-movement-blinking Pour créer le mouvement à l'aide de feuilles de style : http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-movement 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES • Sur le site du Ministère de l’agriculture (www.agriculture.gouv.fr) l’actualité défile en continu. Cette information n’est pas accessible aux navigateurs ne traitant pas les scripts ou aux personnes ne pouvant pas lire les textes défilants. • Sur le site de la Préfecture d’Eure-et-Loir (www.eure-et-loir.pref.gouv.fr), nous trouvons sur plusieurs pages des gifs animés. Une solution serait de proposer une alternative textuelle à ce gif (voir fiche Images). • La page d’accueil du site du Centre Français du Commerce Extérieur (www.cfce.fr) s’auto-rafraîchit régulièrement. Il serait préférable de supprimer cette fonction et de laisser l’utilisateur réactualiser cette page. BRAILLENET 08/04/02 44 FICHE 12 : LES BALISES 1. RAPPEL DES RECOMMANDATIONS 3 ET 4 DES WCAG 1.0 : Recommandation 3 : « Baliser les documents avec les éléments structurants appropriés. Contrôler la présentation avec des feuilles de style plutôt qu'avec des éléments et des attributs de présentation. » Recommandation 4 : « Utiliser un balisage facilitant la prononciation ou l’interprétation du texte abrégé ou en langue étrangère. » Points de contrôle : 3.1 (Priorité 2) ; 3.2 (Priorité 2) ; 3.5 (Priorité 2) ; 3.6 (Priorité 2) ; 3.7 (Priorité 2) ; 4.1 (Priorité 1) ; 4.3 (Priorité 3) Raisons de ces recommandations Les balises sont des éléments nécessaires pour la bonne structuration du code html. L'utilisation inappropriée du balisage restreint l'accessibilité. Le fait de détourner une balise pour créer un effet de présentation complique la tâche des utilisateurs de logiciels spécialisés quand ils essayent de comprendre l'organisation de la page ou d'y naviguer. Une page bien structurée, au contraire, facilitera la compréhension de tous. Le balisage permet aux textes d’être lus correctement par les terminaux braille, les synthèses vocales et les dispositifs de traduction automatique. 2. CE QU’IL FAUT FAIRE La règle générale Utiliser le balisage uniquement pour la structure de la page, du site. Le type de document Pour chaque document il est nécessaire d’indiquer son type : HTML, XML etc. Si ce type n’est pas indiqué, il se peut que les navigateurs ne sachent pas comment afficher le document. Cela peut aussi perturber les logiciels de lecture d’écran. Pour un document conforme au HTML 4.01 transitional, utiliser la syntaxe : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> en début de document. Une liste des grammaires valides est disponible sur le site de l’outil de validation HTML du W3C. Les éléments en-tête Les éléments en-tête doivent être utilisés en accord avec les spécifications et uniquement pour définir la structure du document. BRAILLENET 08/04/02 45 L’utilisation adéquate des en-têtes aide à séparer le contenu de la structure, l’une des techniques fondamentales de l’accessibilité au Web. Les éléments d’en-têtes ne doivent pas servir uniquement à créer des effets de formatage. Les niveaux d’entêtes doivent être utilisés correctement, dans un ordre logique. La consultation d’une liste des en-têtes de la page permettra aux utilisateurs d’obtenir une vue d’ensemble de la structure de la page. Cela permettra d’atteindre plus rapidement et plus aisément un paragraphe donné. Si les en-têtes sont utilisées de façon incorrecte, la page pourra être illisible. Exemple : il faudra utiliser H2 pour indiquer une sous section de H1 Les listes et éléments de listes Les listes et les éléments de listes doivent être aussi correctement balisés. Pour une structure logique du contenu, il faut recourir aux éléments de liste HTML ‘dl’, ‘ul’ et ‘ol’ uniquement pour la création de listes, et non pas pour la création d’effets de formatage tels que la mise en retrait du texte. Des listes ordonnées et des indices contextuels tels que l’utilisation de nombres composés (ex.1, 1.1, 1.2, 1.2.1) empêchent que l’utilisateur ne se perde dans les listes. Le balisage des citations Utiliser le balisage des citations correctement. La balise <blockquote> ne doit pas être utilisée pour réaliser des effets visuels tels que la mise en retrait du texte. Un lecteur d’écran, par exemple, interprète la balise <blockquote> comme une citation, ce qui risque une mauvaise interprétation du texte par l’utilisateur. L’attribut « lang » Les changements de la langue naturelle du texte d’un document et de tout équivalent textuel doivent être identifiés clairement. La spécification de langue peut être utile pour les traducteurs automatiques et cela simplifie le travail de recensement des moteurs de recherche. Exemple : - en HTML utiliser l’attribut ‘lang’ : <HTML lang=«fr»> - en XML, utiliser ‘xml:lang’ L‘attribut « title » Utiliser l’attribut « title » pour spécifier la forme complète de toutes les abréviations ou acronymes. BRAILLENET 08/04/02 46 Exemple : L’interprétation des abréviations avec les synthèses vocales peut varier et s’avérer difficilement compréhensible. Il est possible d’utiliser l’attribut : <ACRONYM title= « journal officiel »>JO</ACRONYM> Ainsi, au lieu de prononcer « jo », la synthèse vocale prononcera « journal officiel ». Avec des navigateurs comme Internet Explorer, la signification des initiales JO apparaîtra en infobulle lorsque la souris est passée sur le mot. 3. APPLICATION A L’AIDE DES EDITEURS HTML !"avec Dreamweaver Dreamweaver ne permet pas directement d’insérer le type de document, l’attribut lang, etc… Cependant, Macromedia propose sur son site des extensions à Dreamweaver 4 permettant d’améliorer l’accessibilité d’un site. (voir www.macromedia.com/accessibility). 4. EXEMPLES RENCONTRES SUR LES SITES EVALUES • Le site portail du Service Public (www.service-public.fr) possède un doctype au début de ses pages. Cela permet de déterminer que le site est au format HTML 4.01. • Il en est de même pour le site de l’environnement et de l’aménagement du territoire (www.environnement.gouv.fr) • Au sein du site de la Caisse des Allocations Familiales (www.caf.fr) ou du site du Ministère de la culture (www.culture.gouv.fr), nous pouvons constater la présence d’abréviations comme « JO », « DRAC ». • En ce qui concerne le site du Ministère de la Jeunesse et des Sports (www.jeunesse-sports.gouv.fr) par exemple, la langue utilisée n’est pas désignée dans le code source par la balise « lang ». Cependant, sur le site www.afssa.fr on trouve : <p><br><a href="langue.asp?langue=FR"> mais pas d’attribut « lang ». De même que sur le site de la fonction publique (www.fonction-publique.gouv.fr), nous trouvons : <meta http-equiv="Content-Language" content="fr"> ou encore : <meta NAME="language" CONTENT="French, Francais"> sur le site de l’Institut National de la Propriété Intellectuelle (www.inpi.fr). Ces derniers exemples sont utiles aux moteurs de recherche mais n’entrent pas dans un codage HTML valide. BRAILLENET 08/04/02 47 FICHE 13 : POINTS SUPPLEMENTAIRES A EVITER 1. CE QU’IL FAUT FAIRE !"Eviter les changements brusques de luminosité. Certaines personnes souffrant d'épilepsie causée par une sensibilité particulière à la lumière peuvent avoir des crises déclenchées par des clignotements dans la zone des 4 à 59 flashs par seconde (Hertz). La sensibilité maximale est atteinte à 20 flashs par seconde (W3C, 1999). !"Eviter les redirections de page (point de contrôle 7.5, Priorité 2). Le serveur devrait être configuré pour une redirection automatique au lieu d’utiliser le balisage pour rediriger automatiquement les pages. L’auto-rafraîchissement des pages peut désorienter les utilisateurs. Des solutions de rechange sont possibles. Entre autres, configurer le serveur pour qu’il génère les codes de redirection appropriés HTTP ou fournir une page statique qui informe les utilisateurs qu’ils devraient rafraîchir la page souvent et utiliser l’URL de la page ainsi réactualisée. !"Eviter les pop-ups (ouvertures de nouvelles fenêtres) sans prévenir l’utilisateur (points de contrôle : 7.5 et 10.1, Priorité 2). Il est important de signaler l'ouverture d'une nouvelle fenêtre : s'il n'est pas prévenu, l'utilisateur se trouve en présence de plusieurs fenêtres de navigateur qui peuvent gêner sa navigation et sa compréhension. !"Eviter les sigles dans les liens Eviter l'emploi de sigles même s'ils sont connus des visiteurs. Leurs prononciations par les synthétiseurs vocaux peuvent se révéler bien éloignées de leur orthographe. Le visiteur aveugle sera contraint de faire épeler lettre à lettre la chaîne de caractères ou de charger la page. Cette manipulation supplémentaire ralentira d'autant sa navigation. Une solution intermédiaire peut être de séparer les lettres du sigle par un point ".". La solution idéale est simple : on inscrira dans le texte du lien la signification du sigle avec éventuellement le sigle entre parenthèse, si celui-ci est plus connu que sa signification littérale. !"Eviter les éléments et les attributs des technologies du W3C qui ne sont plus valables (point de contrôle 11.2, Priorité 2). Les techniques et les attributs qui ne sont plus supportés (qui sont périmés), comme l’attribut <font>, peuvent causer des problèmes d’accessibilité aux nouveaux utilisateurs. 2. EXEMPLES RENCONTRES SUR LES SITES EVALUES • Les sites du Ministère de l’agriculture (www.agriculture.gouv.fr) et du Ministère de la Santé (www.sante.gouv.fr) proposent des redirections automatiques vers leurs pages d’accueil. Ces redirections sont gérées par des scripts. Une redirection gérée par un lien HTML est préférable. • Au sein des sites de la Caisse des Allocations Familiales (www.caf.fr) et de l'Institut National de la Propriété Industrielle (www.inpi.fr), par exemple, de nouvelles fenêtres s'ouvrent lorsqu'un un lien est sélectionné. BRAILLENET 08/04/02 48 FICHE 14 : INFORMATION DE CONTEXTE ET D'ORIENTATION 1. RAPPEL DES RECOMMANDATIONS 12 ET 13 DES WCAG 1.0 Recommandation 12 : "Fournir des informations relatives au contexte et à l'orientation pour que les utilisateurs puissent comprendre les éléments et les mises en pages complexes". Recommandation 13 : "Prévoir des mécanismes de navigation clairs et cohérents - information d'orientation, barres de navigation, carte du site etc. - de manière à ce qu'un utilisateur puisse trouver ce qu'il cherche sur le site". Points de contrôle : 12.1 (Priorité 2) ; 12.2 (Priorité 2) ; 12.3 (Priorité 2) ; 12.4 (Priorité 2) ; 13.2 (Priorité 2) ; 13.8 (Priorité 3) ; 13.9 (Priorité 3) ; 13.10 (Priorité 3) Raisons de cette recommandation Les relations complexes entre éléments d'une page peuvent être difficiles à interpréter pour les personnes ayant des difficultés de compréhension ou ayant un handicap visuel. Il est possible d’aider l’utilisateur en groupant les éléments et en fournissant des informations contextuelles sur les relations entre éléments. 2. CE QU’IL FAUT FAIRE La règle générale Fournir des informations relatives au contexte et à l'orientation pour que l’utilisateur puisse comprendre l’organisation d’ensemble et la mise en page. Titre aux pages L’utilisation d’un titre sur une page aide les personnes qui naviguent à l’aide d’une synthèse vocale ou d’un terminal braille. En effet, lorsque ces personnes naviguent sur un site composé de plusieurs cadres, elles ne peuvent pas savoir directement qu’elles ont changé de page. Le changement du titre d’une page, annoncé par la synthèse vocale ou affiché en braille, leur permet de savoir qu’elles ont bien changé de page. D’autre part, les pages avec titres permettent une meilleure indexation par les moteurs de recherche. Chaque document HTML doit comporter un élément "title" dans la section <HEAD> Exemple : <HTML> <HEAD <TITLE>Le Débat National sur les Risques Industriels</TITLE> … </HEAD> BRAILLENET 08/04/02 49 Cadres Donner un titre à chaque cadre afin de faciliter l’identification et la navigation entre les cadres (voir fiche Cadres). Blocs d'information Diviser les grands blocs d’information en groupes plus petits et plus facilement maniables. Utiliser la technique dite "structural grouping" : (http://www.w3.org/TR/WCAG10HTML-TECHS/#grouping). Cette technique permet de regrouper les éléments de formulaire en groupes sémantiques Utiliser OPTGROUP pour formater de longues listes d’options en petits groupes. Donner des titres structurés avec la balise "h1-h6" et diviser les textes en paragraphes avec la balise "p". Méta-données Prévoir des méta-données pour ajouter des informations d’ordre sémantique aux pages et aux sites, selon la technique décrite par WAI : http://www.w3.org/TR/WCAG10-HTML-TECHS/#document-meta Parmi les méta données, on compte : - le titre de la page, (élément title vu précédemment), - l’élément "adress" donne des informations sur le créateur de la page, - et les éléments "meta". Les méta-données sont notamment utiles aux moteurs de recherche pour mieux indexer les pages. Informations sur les regroupements de documents Fournir des informations sur les regroupements de documents (ex : utiliser LINK, rev, rel). On pourra se reporter aux techniques sur « bundled documents » : http://www.w3.org/TR/WCAG10-CORE-TECHS/#bundled-documents et sur « link element and navigation tool » http://www.w3.org/TR/WCAG10-HTML-TECHS/#linkmetadata Informations distinctives Placer des informations distinctives au début des en-têtes, des paragraphes, des listes (ex : utiliser front-loading). Art ASCII Prévoir des moyens de s’affranchir de l’art ASCII. Voir la technique correspondant à l’art ascii http://www.w3.org/TR/WCAG10-HTML-TECHS/#ascii-art BRAILLENET 08/04/02 50 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES • Le site du Ministère de la Jeunesse et des Sports (www.jeunesse-sports.gouv.fr) propose toujours le même titre à ses pages. • Un bon exemple : le site du Ministère de l’Environnement (www.environnement.gouv.fr) donne un titre explicite à la plupart de ses pages. BRAILLENET 08/04/02 51 FICHE 15 : MECANISMES D'AIDE A LA NAVIGATION 1. RAPPEL DE LA RECOMMANDATION 13 DES WCAG 1.0 « Fourniture de mécanismes de navigation clairs et cohérents (information d'orientation, barres de navigation, carte du site etc. » Points de contrôle : 13.1 (Priorité 2) ; 13.3 (Priorité 2) ; 13.4 (Priorité 2) ; 13.5 (Priorité 3) ; 13.6 (Priorité 3) ; 13.7 (Priorité 3) Raisons de cette recommandation Certains outils peuvent améliorer grandement la consultation d'un site web. Le plan du site permet à l'internaute de prendre connaissance rapidement de l'architecture du site et d'avoir une idée précise des informations qu'il contient. Un moteur de recherche permet un accès précis et rapide à l'information. Une page d’aide à la navigation permet aux utilisateurs novices du site de se retrouver dans les pages. L’utilisation du site en sera meilleure pour tous les utilisateurs. 2. CE QU’IL FAUT FAIRE La règle générale Les outils de navigation doivent être accessibles facilement à partir de toutes les pages du site. Dans chacune d'entre elles, ils doivent être aisément repérables et si possible, placés toujours au même endroit. Leur construction doit naturellement respecter les normes d'accessibilité. Plan du site Il doit être constitué d'un ensemble de liens hypertextes concis, précis et lisibles hors contexte (liens textuels ou liens images bien commentés). Ceux-ci peuvent être agencés sous forme d'une table des matières. Classés par niveaux et/ou par thèmes, ils donneront un aperçu utile de l'apparence générale de l'arborescence du site. Une numérotation appropriée des différents liens est un plus non négligeable. Un plan du site bien conçu et couplé à un moteur de recherche favorise l'accès rapide à l'information. Moteur de recherche Le formulaire de recherche doit être facilement repérable dans chaque page par exemple par un titre explicite. Il doit être composé d'éléments HTML standards et accessibles (voir fiche formulaire). La validation du formulaire et l'affichage de la page de recherche ne doivent pas être exécutés par des scripts côté client type Javascript. Les informations contenues dans celle-ci doivent être exploitables par tous. Page d'aide Un ensemble d'explications claires et concises rédigées dans un langage simple améliore la facilité d’utilisation du site. Elle a pour rôle de décrire la structure du site et de certaines pages. Certains éléments complexes doivent faire l'objet d'explications : descriptions, mode d'emploi. Des conseils de navigation doivent être prodigués aux internautes pour améliorer la lisibilité et la consultation du site. BRAILLENET 08/04/02 52 Liens Regrouper les liens de même nature et proposer un moyen de passer ce groupe de liens. Se référer à la technique « grouping and bypassing links » http://www.w3.org/TR/WCAG10-HTML-TECHS/#group-bypass Barres de navigation Les barres de navigation sont très utiles pour se repérer sur un site et savoir où l’on se trouve. Quand on les rencontre sur toutes les pages, il est possible d’atteindre rapidement une partie du site. Cette répétition de liens sur chaque page peut gêner les utilisateurs de synthèses vocales ou de braille, qui doivent lire toutes ces barres de navigation avant d’accéder au contenu de la page. Il existe plusieurs méthodes pour « passer » ces liens : 1. Inclure un lien pour passer cette barre de navigation 2. Proposer une feuille de style permettant à l’utilisateur de cacher la barre de navigation. 3. Utiliser l’élément « map » pour regrouper une série de liens. Le premier lien de cette série devra comporter une ancre vers l’information principale de la page : Exemple : <BODY> <MAP title="Navigation Bar"> <P> [<A href="#how">Bypass navigation bar</A>] [<A href="home.html">Home</A>] [<A href="search.html">Search</A>] [<A href="new.html">New and highlighted</A>] [<A href="sitemap.html">Site map</A>] </P> </MAP> <H1><A name="how">How to use our site</A></H1> <!-- content of page --> </BODY> Pages et nombre de clics Les pages ne doivent pas être trop longues afin d’éviter un scrolling écran trop important. Le nombre de clics doit être limité afin de préserver la personne de la fatigue occasionnée. 3. EXEMPLES SUR LES SITES EVALUES • • • Le site du Premier Ministre (www.premier-ministre.gouv.fr) fournit un bon exemple. Sur sa version texte, un lien permet de passer la barre de navigation pour accéder directement à l’information principale de la page. En revanche, le plan du site du Ministère de l’environnement (www.environnement.gouv.fr) comporte plus de 1000 liens et n’est pas très exploitable. Sur le site de l’Agence Nationale pour l’Emploi (www.anpe.fr - relativement accessible), le plan du site propose des rubriques sous forme de listes déroulantes validées par des scripts, et ne peut donc pas être lu. BRAILLENET 08/04/02 53 FICHE 16 : UTILISATION DES FORMATS DE FICHIER 1. RAPPEL DE LA RECOMMANDATION 11 DES WCAG 1.0 « Utiliser les technologies préconisées par le W3C (selon les spécifications), et respecter les Recommandations d'accessibilité. Lorsqu’on ne peut utiliser une technologie du W3C ou si en le faisant, on ne peut obtenir un résultat qui se transforme de façon élégante, il faut prévoir une version alternative pour présenter le contenu. » Point de contrôle : 11.3 (Priorité 3) Raisons de cette recommandation Sur certaines pages de sites, on trouve des documents de format différent (ex : format pdf, PostScrip, RTF) qui ne peuvent s’ouvrir dans le navigateur qu’à l’aide d’un logiciel séparé (ex : acrobat reader) ou d’un plug-ins. Le choix du format à proposer est important pour un bon accès à l’information. 2. CE QU’IL FAUT FAIRE Il faut concevoir les documents pour qu’ils soient compatibles et accessibles. Choisir des technologies approuvées par le W3C, utiliser les langages selon les spécifications et mettre en application des conventions de logiciels normalisées pour contrôler le comportement et l’activation des composants de l’interface utilisateur. Le balisage doit être utilisé en accord avec les spécifications pour assurer la consistance, la compatibilité et l’accessibilité de l’information, et pour maximiser l’efficacité des outils d’indexation, des moteurs de recherche et des outils de navigation. Ne pas proposer uniquement des documents au format de fichier PDF. Le format PDF est lisible pour les aveugles sous certaines conditions mais nécessite d'importantes manipulations et configurations logicielles. Ce format est surtout destiné pour l’impression et ne peut pas aisément être lu en ligne, sur un écran. S’ils ne respectent pas des règles précises d’indexation, les documents en PDF ne pourront pas être facilement repérés par les moteurs de recherche. Pour aplanir ces difficultés, proposer d’autres formats de documents : texte seul, HTML... Les liens vers ces documents doivent être explicites. Ne pas mettre un lien intitulé « format pdf » sans préciser de quel document il s’agit (se reporter à la fiche liens pour plus de détails). Il est possible d'utiliser un convertisseur en ligne, PDFtohtml Converter, développé par Adobe, pour convertir un fichier PDF en HTML. Il suffit d’entrer l’url du fichier PDF dans le formulaire et de valider : http://access.adobe.com/francais_2.html Le filtre Office 2000 HTML Filter 2.0 permet d’épurer les documents enregistrés avec Office 2000 au format HTML. Il supprime les balises propriétaires ajoutées automatiquement par Microsoft Word et Excel 2000, afin d’obtenir un format HTML plus léger, réduisant ainsi la taille des documents : http://office.microsoft.com/downloads/2000/Msohtmf2.aspx BRAILLENET 08/04/02 54 Pour que la conversion soit plus aisée, il est recommandé, lors de l’édition de documents Word, d’utiliser les styles propres à Word et de ne pas se servir de mise en forme non standard. Remarque : Il est recommandé de vérifier la conformité du HTML obtenu et éventuellement, de corriger quelques erreurs à la main. 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES Beaucoup proposent des documents PDF à télécharger sans aucune alternative : le site de l'Agence Française de Sécurité Sanitaire des Aliments(www.afssa.fr) et le site de l'Agence National pour l'Emploi (www.anpe.fr), par exemple. BRAILLENET 08/04/02 55 FICHE 17 : UTILISATION DE VERSIONS ALTERNATIVES 1. RAPPEL DE LA RECOMMANDATION 11 WAI Point de contrôle : 11.4 (Priorité 1) « Si, malgré vos efforts vous ne parvenez pas à produire une page accessible, créez un lien vers une autre page accessible, qui utilise les technologies du W3C, et qui présente une information (ou fonctionnalité) équivalente, et est mise à jour aussi régulièrement que la page (originale) inaccessible. Note : Les développeurs de contenu ne devraient se résoudre à utiliser cette technique des pages alternatives qu'en dernier ressort, car ces pages sont généralement remises à jour moins souvent que les pages d'origine. Une page qui n'est plus à jour peut être aussi frustrante qu'une page inaccessible, puisque, dans les deux cas, l'information présente sur la page d'origine est inaccessible. La génération automatique de pages alternatives permet des mises à jour plus fréquentes, mais les développeurs de contenu doivent cependant veiller à ce que les pages générées de cette manière soient lisibles, et à ce qu'un utilisateur puisse visiter le site en utilisant les pages principales, les pages alternatives ou les deux. Avant de vous résoudre à utiliser des pages alternatives, repensez la conception de la page d'origine. En la rendant accessible, vous l'améliorerez probablement pour tous les utilisateurs. » 2. CE QU’IL FAUT FAIRE La règle générale Les versions alternatives ne doivent être utilisées que si le concepteur ne peut faire autrement. Elles doivent être mises à jour aussi fréquemment que la version originale, et contenir les mêmes informations. Version alternative Elle doit apporter la même information que la version originale. Il n’est pas nécessaire que cette version soit sans images, pour que les personnes aveugles puissent la lire. Mais les images doivent être commentées, afin que tous puissent y accéder. En pratique une version complète du site, générée de manière dynamique et totalement accessible est possible. Jusqu’à présent, la création de versions alternatives, souvent appelées "versions texte", n’était pas encouragée, car elle entraînait le risque de ne pas être actualisée aussi souvent que la version dite "graphique". Avec l’utilisation de plus en plus fréquente de la gestion de sites en dynamique, le problème d’actualisation se pose moins. Cependant, une version texte se doit de proposer les mêmes fonctionnalités que les versions originales. Il est préférable, dans la mesure du possible, de créer une version mixte, utilisable par tous, plutôt qu’une version dite texte, et une version originale. Le choix de la BRAILLENET 08/04/02 56 version alternative, ne devra être fait, que si rien d’autre n’est possible pour rendre le site accessible. 3. EXEMPLES RENCONTRES SUR LES SITES EVALUES Le site du Premier Ministre (www.premier-ministre.gouv.fr) propose l’intégralité du site en version texte. Cette version est accessible, mais le moteur de recherche dans le site, longtemps, n’a pas été opérationnel. BRAILLENET 08/04/02 57 LES OUTILS POUR L’EVALUATION DE L’ACCESSIBILITÉ D’UN SITE Un certain nombre d’outils permettent de se faire une première idée de l’accessibilité d’un site. Ils sont soit disponibles en ligne, en téléchargement ou disponibles dans les options de Windows et de paramétrage de l’affichage. VERIFICATIONS SIMPLES Tout d’abord, un site accessible doit pouvoir être consulté à l’aide de différents navigateurs. Même si Internet Explorer est largement utilisé, il est déconseillé de concevoir un site en fonction uniquement de ce navigateur. Les internautes ne peuvent pas toujours utiliser les navigateurs les plus récents et doivent pouvoir accéder au site même s’ils se servent de Netscape, d’Opéra ou de navigateurs textuels tel Lynx. Consulter le site avec plusieurs navigateurs graphiques, de versions différentes, et avec un navigateur textuel. Les navigateurs n’ont pas tous la même interprétation du code HTML. L’information graphique peut ne pas être affichée de la même façon par Internet Explorer ou Netscape. L’ordre des informations peut être considérablement modifié lorsque le site est visualisé avec un navigateur textuel. Vérifier que la taille de la police d’affichage peut être modifiée grâce aux options de personnalisation du navigateur. Il est également instructif de naviguer sur le site en ne se servant que du clavier (déplacement à l’aide de la tabulation, activation des liens par la touche entrée). Visualiser les pages en noir et blanc : Il est possible d'effectuer ces réglages sur certains écrans. Dans Internet Explorer ces modifications peuvent être faites en allant dans : Outils, Options Internet, puis cliquer sur "accessibilité", cocher les 3 cases concernant les couleurs et la taille des polices spécifiées par le site Web. Valider par ok. Tester les pages sans afficher ni images, ni scripts, ni applets : Dans Internet Explorer : Choisir "options Internet", "avancées", et décocher les cases correspondantes. Avec Netscape : Choisir Edit, préférences, avancées, et décocher les cases concernant l'affichage de ces éléments. Appliquer Lynx Viewer (http://www.delorie.com/web/lynxview.html). Cet utilitaire en ligne permet de visualiser la page telle qu'elle serait présentée par un navigateur en mode texte seulement (comme Lynx). Il suffit de donner l'adresse de la page à tester. BRAILLENET 08/04/02 58 OUTILS D’EVALUATION AUTOMATIQUE DES SITES Une liste d’outils de vérification automatique est disponible sur le site de WAI à l’adresse : http://www.w3.org/WAI/ER/existingtools.html . Ces outils analysent le code HTML (ex : l’attribut « alt= » doit être inclus dans l’élément <IMG SRC=…>). Ils sont une aide précieuse mais l’évaluation doit être complétée par l’expertise d’un opérateur humain. • BOBBY WorldWide (http://www.cast.org/bobby) BOBBY est un outil très utilisé. Cet outil a été créé par CAST (Centre of Applied Special Technology). Il permet une évaluation des problèmes d’accessibilité d’une page ou d’un groupe de pages. Il propose un logo « Bobby approved » qu’utilisent de nombreux Webmestres, si le site passe correctement l’examen Bobby. Bobby identifie de nombreux problèmes dans un site et peut fournir une liste de vérifications manuelles à effectuer. Bobby permet de tester la compatibilité des pages web avec diverses versions des navigateurs. Bobby est disponible en ligne. Une version exécutable en local peut être téléchargée. • W3C HTML validation service (http://validator.w3.org/) « W3C HTML validation service » est un service en ligne du W3C. Il contrôle les documents HTML et XHTML selon leur conformité aux recommandations émises par le W3C et par d’autres standards. Il suffit d’entrer l’adresse url puis de sélectionner le codage de caractères (ex : iso-8859-1 (Western Europe), le type de document (ex : HTML 4.0 strict) et de cocher les options souhaitées (ex : afficher le code source). • CSS validator (http://www.jigsaw.w3.org/css-validator) « CSS validator » est un validateur des feuilles de style « Cascading Style Sheets » niveau 2. Ce service de validation est accessible sur le site du W3C. On a le choix entre trois types d’analyses : 1. valider sa feuille de style CSS en indiquant l’url de la ressource, 2. valider sa feuille de style CSS en utilisant une zone en texte, 3. valider le fichier contenant la feuille de style en le téléchargeant. La validation de la feuille de style CSS s’effectue en général après celle de la page HTML. • WebMetrics Tool Suite (http://zing.ncsl.nist.gov/~webmet/) Il s’agit de quatre outils prototypes développés et testés par the National Institute of Standards and Technology (NIST) : le Web Static Analyzer Tool (WebSAT), le Web Category Analysis Tool (WebCAT), le Web Visual Instrumenter Program (WebVIP), et le WebVIP Visualization Tool (outil de visualisation de WEBVIp, WebVISVIP). Les trois derniers outils nécessitent la présence d’utilisateurs. Seul le premier outil est décrit ici. Le WebSAT évalue non seulement l’accessibilité des pages web, mais les performances, la facilité à maintenir le site, sa navigabilité et sa lisibilité (readability). Par exemple, pour évaluer les performances, WebSAT calcule la taille totale des BRAILLENET 08/04/02 59 images sur une page (qui ne devrait pas dépasser 30 Ko), vérifie si la hauteur et la largeur de chacune des images sont spécifiées. Quant à la navigation, l’évaluation de WebSAT porte essentiellement sur l’emploi approprié des liens. L’utilisation de ce logiciel nécessite une inscription préliminaire par e-mail. OUTILS DE REPARATION • A-PROMPT (http://www.aprompt.ca) A-prompt est un outil développé par the Adaptative Technology Resource Centre (ATRC) et the TRACE Center. Il identifie les problèmes d’accessibilité potentiels et offre des dialogues d’édition permettant de les corriger. Cet outil ne peut s’utiliser qu’en local et doit être téléchargé et installé sur l’ordinateur. Une version française est disponible à l’adresse : http://aprompt.ca/french/demo.html. • HTML Tidy (http://www.w3.org/People/Raggett/tidy/) Tidy est un produit du W3C qui permet de détecter automatiquement les erreurs présentes dans le code HTML. Il permet d’identifier facilement et rapidement les endroits du code ou les détails auxquels il faut porter une attention particulière afin que les pages soient accessibles à tous. HTML Tidy est une application multi-plateforme très efficace qui offre une quarantaine d'options de réglage. Chaque item trouvé est listé avec le numéro de ligne et de colonne afin de le repérer au sein du fichier HTML. Tidy ne génère pas de version corrigée lorsqu’il hésite sur certains problèmes. Dans ce cas, il le notifie par « errors » plutôt que « warnings » dans son rapport. Un exemple du travail réalisé par cet outil est disponible à l’adresse ci-dessus. OUTILS DE FILTRAGE Ils permettent de visualiser et/ou de reformater des pages selon les besoins spécifiés par les utilisateurs. Certains de ces outils peuvent être utilisés pour convertir des documents dans des formats plus accessibles. Deux d’entre eux sont présentés ci-dessous. Ils permettent de reformater des documents dans des formats plus lisibles. • Office 2000 HTML Filter 2.0 (http://office.microsoft.com/downloads/2000/Msohtmf2.aspx) Si vous disposez de documents au format Word 2000, il vous est possible, avec la fonction « enregistrer sous », de les convertir au format HTML. Le format HTML peut être interprété par un plus grand nombre de logiciels que le format Word. L’outil « office 2000 HTML filter » permet d’épurer les documents au format HTML produits avec Office 2000. Il supprime les balises propriétaires ajoutées automatiquement par Microsoft Word et Excel 2000, afin d’obtenir un format HTML plus léger, réduisant ainsi la taille des documents. BRAILLENET 08/04/02 60 Remarques : Il est cependant recommandé de vérifier la conformité du HTML obtenu avec des outils tels que Tidy (voir outils de réparation), et éventuellement, de corriger quelques erreurs à la main. Pour que la conversion soit plus aisée, utiliser lors de l’édition de documents Word, les styles propres à Word. Eviter les mise en forme non standard. • PDFtohtml Converter (http://access.adobe.com/francais_2.html) Si votre site propose des documents au format PDF, vous pouvez, en plus de mettre un lien vers le logiciel Acrobat Reader d’Adobe, faire un lien vers le convertisseur « pdf vers html ». Cet outil en ligne, développé par Adobe, permet de convertir un fichier PDF en HTML. Il suffit d’entrer l’url du fichier PDF dans le formulaire et de valider. Remarque : Les fichiers PDF doivent être faits à partir de texte. S’ils sont la reproduction d’une image, ils ne peuvent pas être convertis dans d’autres formats. BRAILLENET 08/04/02 61 REFERENCES SUR L’ACCESSIBILITÉ BASTIEN, JMC. ; LEULIER, C. & SCAPIN, DL. (1998). L’ergonomie des sites web, INRIA, Rocquencourt. BASTIEN, JMC. (2001). Quelques recommandations pour la rédaction de contenus Web. http://www.lergonome.com/dev/pages/article_11.asp#TOP BURGER, D. (2001). Les Nouvelles Technologies et l'accès à l’information pour les personnes handicapées visuelles. Intervention de Dominique Burger au XXIXème entretien de Médecine Physique et de Réadaptation de Montpellier. http://www.snv.jussieu.fr/inova/publi/mtp01.htm COST 219bis (1999). The current situation concerning potential alleviations to identified barriers. http://www.stakes.Fi/cost219/COSD420.HTML D'AMOUR, J.M. (février 2001). L'accessibilité au web pour les personnes handicapées. Québec. http://www.camo.qc.ca W3C (MIT, INRIA, Keio - 1999). Directives pour l’accessibilité aux contenus Web (version 1.0). Recommandations du W3C du 5 mai 1999. http://www.w3.org/TR/WAI-WEBCONTENT W3C Working Draft (janvier 2001). How people with disabilities use the web. http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/Overview.html Secrétariat du Conseil du Trésor du Canada (2001). Guide d’auto-évaluation de la conformité à la normalisation des sites internet. http://www.cio-dpi.gc.ca/clf-upe/guide/guide_f.asp Site de références sur l’ergonomie : http://www.lergonome.com RECOMMANDATIONS Recommandations WAI (en anglais) : http://www.w3.org/TR/WAI-WEBCONTENT/ Recommandations WAI sous forme http://www.w3.org/WAI/wcag-curric/ de transparents (en anglais) : Traduction en français des recommandations WAI sur le site Internet du gouvernement : http://www.internet.gouv.fr/francais/guide/w3c/w3c.html BRAILLENET 08/04/02 62 Techniques for Web Content Accessibility Guidelines 1.0 : http://www.w3.org/TR/WCAG10-TECHS/ Traduction en français des techniques pour appliquer les WCAG 1.0 : http://www.la-grange.net/w3c/WAI-WEBCONTENT-TECHS/ Livre Blanc BrailleNet (synthèse des recommandations, en français, en anglais, en allemand et en espagnol) : http://www.braillenet.jussieu.fr/accessibilite/livreblanc/ LABELS Quelques labels sont mis à disposition des responsables de sites Internet : - Web Accessibility http://www.w3.org/WAI/WCAG1-Conformance.html - Lynx Optimized http://www.crl.com/~subir/lynx/enhanced_pages.html - Bobby Approved http://www.cast.org/bobby N.B. L'apposition sur les sites d'un label qui garantit l’accessibilité aux personnes non voyantes (en l'absence d'organisme officiel) s'appuie sur la bonne foi des webmestres. BrailleNet attribue et vérifie le label ACCESSIWEB : www.braillenet.org/accessibilite BRAILLENET 08/04/02 63 INTITULE DES LIENS HYPERTEXTES PRESENTS DANS LES FICHES FICHE 1 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/tech-text-equivalent contrôle 1.1 - Priorité 1) (Point de FICHE 2 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-frame-titles (Point de contrôle 12.1 – Priorité 1) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-frame-longdesc (Point de contrôle 12.2 – Priorité 2) FICHE 3 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-redundant-server-links (Point de contrôle 1.2 – Priorité 1) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-redundant-client-links (Point de contrôle 1.5 – Priorité 3) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-keyboard-shortcuts (Point de contrôle 9.5 – Priorité3) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-meaningful-links (Point de contrôle 13.1 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-group-links (Point de contrôle 13.6 – Priorité 3) FICHE 4 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-style-sheets (Point de contrôle 3.3 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-relative-units (Point de contrôle 3.4 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-order-style-sheets (Point de contrôle 6.1 – Priorité 1) FICHE 5 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-table-headers (Point de contrôle 5.1 – Priorité 1) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-table-structure (Point de contrôle 5.2 – Priorité 1) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-avoid-table-for-layout (Point de contrôle 5.3 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-table-layout (Point de contrôle 5.4 – Priorité 2) BRAILLENET 08/04/02 64 http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-table-summaries (Point de contrôle 5.5 – Priorité 3) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-abbreviate-labels (Point de contrôle 5.6 – Priorité 3) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-linear-tables (Point de contrôle 10.3 – Priorité 3) TABLIN : http://www.w3.org/WAI/References/Tablin/ Exemples de techniques pour des tableaux accessibles : http://www.w3.org/TR/WCAG10-HTML-TECHS/#tables Exemple du curriculum pour des tableaux accessibles : http://www.w3.org/WAI/wcag-curric/sam44-0.htm FICHE 6 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-tab-order (Point de contrôle 9.4 – Priorité 3) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-keyboard-shortcuts (Point de contrôle 9.5 – Priorité 3) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-unassociated-labels (Point de contrôle 10.2 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-place-holders (Point de contrôle 10.4 – Priorité 3) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-associate-labels (Point de contrôle 12.4 – Priorité 2) FICHE 7 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-scripts (Point de contrôle 6.3 – Priorité 1) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-keyboard-operable-scripts (Point de contrôle 6.4 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-directly-accessible (Point de contrôle 8.1 – Priorité 1) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-device-independentevents (Point de contrôle 9.3 – Priorité 2) FICHE 8 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-scripts (Point de contrôle 6.3 – Priorité 1) FICHE 9 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-color-convey (Point contrôle 2.1 – Priorité 1) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-color-contrast (Point contrôle 2.2 – Priorité 2) BRAILLENET de de 08/04/02 65 http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-relative-units (Point de contrôle 3.4 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-order-style-sheets (Point de contrôle 6.1 – Priorité 1) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-avoid-blinking (Point de contrôle 7.2 – Priorité 2) FICHE 10 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/tech-text-equivalent contrôle 1.1 - Priorité 1) (Point de FICHE 11 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-avoid-flicker (Point de contrôle 7.1 – Priorité 1) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-avoid-blinking (Point de contrôle 7.2 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-avoid-movement (Point de contrôle 7.3 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-no-periodic-refresh (Point de contrôle 7.4 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-no-auto-forward (Point de contrôle 7.5 – Priorité 2) FICHE 12 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-use-markup (Point de contrôle 3.1 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-identify-grammar (Point de contrôle 3.2 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-logical-headings (Point de contrôle 3.5 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-list-structure (Point de contrôle 3.6 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-quotes (Point de contrôle 3.7 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-identify-changes (Point de contrôle 4.1 – Priorité 1) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-identify-lang (Point de contrôle 4.3 – Priorité 3) Liste des grammaires valides : http://validator.w3.org/sgml-lib/catalog FICHE 13 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-no-auto-forward (Point de contrôle 7.5 – Priorité 2) BRAILLENET 08/04/02 66 http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-avoid-pop-ups (Point de contrôle 10.1 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-avoid-deprecated (Point de contrôle 11.2 – Priorité 2) FICHE 14 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-frame-titles (Point de contrôle 12.1 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-frame-longdesc (Point de contrôle 12.2 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-group-information (Point de contrôle 12.3 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-associate-labels (Point de contrôle 12.4 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-use-metadata (Point de contrôle 13.2 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-front-loading (Point de contrôle 13.8 – Priorité 3) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-bundled-version (Point de contrôle 13.9 – Priorité 3) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-skip-over-ascii (Point de contrôle 13.10 – Priorité 3) FICHE 15 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-meaningful-links (Point de contrôle 13.1 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-site-description (Point de contrôle 13.3 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-clear-nav-mechanism (Point de contrôle 13.4 – Priorité 2) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-nav-bar (Point de contrôle 13.5 – Priorité 3) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-group-links (Point de contrôle 13.6 – Priorité 3) http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-searches (Point de contrôle 13.7 - Priorité 3) FICHE 16 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-content-preferences (Point de contrôle 11.3 – Priorité 3) FICHE 17 : http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-alt-pages contrôle 11.4 – Priorité 1) BRAILLENET (Point de 08/04/02 67 INTITULE DES LIENS HYPERTEXTES PRESENTS DANS : • « Outils d’évaluation automatique des sites » CAST : http://www.cast.org/about W3C : http://www.w3.org/consortium NIST : http://www.nist.gov/public_affairs/nandyou.htm • « Outils de réparation » ATRC : http://www.utoronto.ca/atrc The TRACE Center : http://trace.wisc.edu/ BRAILLENET 08/04/02 68 INDEX A Accesskey (raccourcis clavier) (fiche 6) ACRONYM pour les abréviations (fiche 12) ALT (fiches 1 et 10) Animations (fiche 11) Applets Java (fiche 8) Area shape (fiche 1) Art ASCII (fiche 14) Attribut summary (fiche 5) Autorafraîchissements (fiches 1 et 11) B Balise (Fiche 12) Barre de navigation (fiches 14 et 15) Bloc d’information (fiche 14) BLOCKQUOTE pour le balisage des citations (fiche 12) C Cadre (fiches 1 et 14) Caractères (fiche 9) Changement de luminosité (fiche 13) Clics (fiche 15) Clignotements (fiche 11) Cohérence du site (fiche 9) Contenus auditifs (Fiche 10) Contenus clignotants (Fiche 9) Contrastes (Fiche 9) Couleurs (Fiche 4 et 9) CSS (Fiche 4) D DL (Fiche 12) DOCTYPE pour définir le type de document (Fiche 12) BRAILLENET 08/04/02 69 E Eléments de liste (Fiche 12) Eléments en-tête (Fiche 12) Eléments et attributs périmés (fiche 13) EMBED pour la technologie Flash (Fiche 8) Equivalent textuel (fiches 1, 10) F Feuilles de style (Fiche 4 et 5) Fieldset (fiche 6) Flash (fiche 8) Format de fichier (fiche 16) G Gif animé (fiche 11), H H (1-6) titres (fiches 1, 12 et 14) Header (attribut dans TD et TR d'un tableau) (fiche 5) I Images (fiche 1) Images de fond ( Fiche 1 et 4) Images map ou cliquables ou à zones réactives (fiche 1) Images transparentes (fiche 1 et 4) Img (fiche 1) Information distinctive (fiche 14) J BRAILLENET 08/04/02 70 Javascript (fiches 6 et 7) L Label (fiche 6) LANG pour définir la langue (fiche 12) Legend (fiche 6) Link (fiche 4) Liste (fiche 1 et 12), LONGDESC (fiche 1 et 10) M Méta-données (fiche 14) Mise en page (fiche 14) Moteur de recherche (fiche 15) N Name (titre aux cadres) (fiche 2) Navigation simple (fiches 14 et 15) Noembed (fiche 8) Noframe (fiche 2) Noscript (fiche 7) Nouvelle fenêtre (pop-up) (fiche 13) O OBJECT pour la technologie Flash et Applet java (fiche 8) OL (éléments de liste HTML) (fiche 12) Orientation (fiche 14) Outils de navigation (fiche 15) P P (paragraphe) (fiche 14) Page d’aide (fiche 15) PDF (fiche 16) Plan du site (fiche 15) BRAILLENET 08/04/02 71 Polices ou fonts (fiche 4) Pop up (nouvelle fenêtre) (fiche 13) Puces (fiche 1) Q Quantité d’information (fiche 9) R Redirection automatique (fiche 13) Regroupement de documents (fiche 14) Regroupement de liens (fiche 15) S Sigles, abréviations (fiches 12 et 13) Style (élément et attribut) (fiche 4) Styles ( Fiche 4) T Tabindex (fiche 6) Tableaux de données (fiche 5 et 9) Tableaux pour la mise en forme (fiche 5) Tablin (outil de linéarisation de tableaux) (fiche 5) Taille de l’image (fiche 9) Taille des caractères (fiche 4) Texte défilant (fiche 11) Textes au format image (fiche 1) TH pour les tableaux (fiche 5) Title (attribut à ajouter aux éléments A, pour les liens, aux cadres…) (fiches 2 et 3) Title (élément de l'en-tête head en HTML) (fiches 2 et 14) U UL éléments de liste HTML (fiche 12) Usemap (fiche 1) BRAILLENET 08/04/02 72 V Version alternative (fiche 17) Version mixte (fiche 17) BRAILLENET 08/04/02 73 ANNEXE 1 : TRAVAIL ET AUTORITE DE LA WAI Les recommandations de la Web Accessibility Initiative sont aujourd’hui universellement reconnues. Elles sont de quatre types : 1. Web Content Accessibility Guidelines pour la création de contenus sur le Web 2. Authoring Tool Accessibility Guidelines sur les outils de création de ces contenus 3. User Agent Accessibility Guidelines sur les logiciels de lecture 4. XML Accessibility Guidelines sur les applications du langage XML Ces recommandations sont reprises par de nombreux organismes nationaux, voire gouvernementaux. La Commission Européenne devrait les adopter officiellement très prochainement. Ces recommandations évoluent régulièrement grâce à des groupes de travail composés d'experts de nombreux pays. Le travail de la WAI est décrit sur son site Web, sur lequel on trouve également l’ensemble de ses publications : http://www.w3.org/WAI/ En Europe, le travail de la WAI est relayé par des projets tel que IST WAI-DA (Web Accessibility Initiative Design for All IST 13470 – source : http://www.w3.org/WAI/WAIDA/) dont un objectif majeur est de diffuser des informations sur les recommandations existantes, afin d'améliorer l'accessibilité du Web en Europe. L’Association BrailleNet est partenaire associé du projet WAI-DA. Ces recommandations WAI pour la création de contenus sur le Web (WCAG) sont au nombre de 14. Elles constituent la base sur laquelle devrait reposer toute conception de site Web. A chaque recommandation sont associés des points de contrôle (checkpoints) affectés d’un niveau de priorité : • Priorité I : le site doit satisfaire le point. Il est très important que ce niveau soit pris en compte. Si les priorités de niveau I ne sont pas respectées, l’accès au site est complètement impossible. • Priorité II : le site devrait satisfaire le point. La non-conformité, à ce niveau de priorité, aura un effet non négligeable sur l’accès des personnes handicapées. • Priorité III : il est recommandé d’appliquer le point. L’accès sera facilité. Les 14 Recommandations en français : 1. 2. 3. 4. Fournir des alternatives équivalentes au contenu auditif et visuel. Ne pas s'en remettre uniquement aux couleurs. Utiliser le balisage et les feuilles de style, et cela de façon appropriée. Clarifier l'utilisation du langage naturel BRAILLENET 08/04/02 74 5. Créer des tableaux qui se transforment de façon élégante. 6. S'assurer que les pages qui contiennent de nouvelles technologies se transforment de façon élégante. 7. Assurer à l'utilisateur le contrôle des changements du contenu lorsque ce dernier varie dans le temps. 8. Assurer un accès direct aux interfaces utilisateur intégrées. 9. Conception respectant l'indépendance par rapport au périphérique. 10. Utilisation de solutions intermédiaires. 11. Utilisation des technologies et directives du W3C. 12. Fourniture d'informations de contexte et d'orientation. 13. Fourniture de mécanismes de navigation clairs. 14. S'assurer que les documents sont clairs et simples. En anglais : 1. Provide equivalent alternatives to auditory and visual content. 2. Don't rely on color alone. 3. Use markup and style sheets and do so properly. 4. Clarify natural language usage 5. Create tables that transform gracefully. 6. Ensure that pages featuring new technologies transform gracefully. 7. Ensure user control of time-sensitive content changes. 8. Ensure direct accessibility of embedded user interfaces. 9. Design for device-independence. 10. Use interim solutions. 11. Use W3C technologies and guidelines. 12. Provide context and orientation information. 13. Provide clear navigation mechanisms. 14. Ensure that documents are clear and simple. BRAILLENET 08/04/02 75 ANNEXE 2 : LES 30 SITES EVALUES PAR BRAILLENET Ces sites ont été évalués par l’association BrailleNet et son réseau d’experts en septembre et octobre 2001 : 1. ministère de la fonction-publique et de la réforme de l'État 2. ministère de la culture et de la communication 3. ministère de l'éducation nationale 4. ministère de la jeunesse et des sports 5. ministère de l'économie, des finances et de l'industrie 6. ministère de l'emploi et de la solidarité (santé) 7. préfecture de l'Eure et Loir 8. préfecture de la Manche 9. préfecture du Rhône 10. académie de Strasbourg 11. portail de l'administration française 12. portail officiel du droit français 13. agence nationale pour l'emploi 14. ministère de l'environnement 15. site du Premier-ministre 16. mission interministérielle de lutte contre les drogues et les toxicomanies 17. direction régionale de l'industrie, de la recherche et de l'environnement de Picardie 18. direction départementale de l'équipement de Haute-Savoie 19. commission d'accès aux documents administratifs 20. caisse des allocations familiales 21. ministère de l'agriculture dont quelques pages de la partie "ESB Info" 22. conseil supérieur de l'audiovisuel 23. ambassade de France en République Tchèque 24. agence française de sécurité sanitaire des aliments 25. ministère de la défense 26. cour d'appel de Paris 27. institut national de la propriété industrielle 28. musée Guimet 29. autorité de sûreté nucléaire 30. centre français du commerce extérieur BRAILLENET 08/04/02 76 ANNEXE 3 : LE RESEAU ACCESSIWEB 1. LES PARTENAIRES Association Braillenet 12 bis rue de Picpus 75012 PARIS e-mail : [email protected] Tel : 01 44 27 34 35 – Fax : 01 44 27 34 38 Web : http://www.braillenet.jussieu.fr http://www.braillenet.org URBILOG 42, rue Fénelon 59000 LILLE e-mail : [email protected] Tel : 03 28 55 21 30 - Fax : 03 28 55 21 31 Web : http://www.urbilog.fr/ Association Paul Guinot pour les aveugles et les malvoyants reconnue d'utilité publique - Décret du 21 janvier 1928 39, rue Balard - 75015 Paris Tél. 01 53 98 74 97 - Fax 01 53 98 74 98 Web : http://www.guinot.asso.fr/accueil.htm Centre de Rééducation pour Déficients Visuels 30 rue Sainte-Rose 63038 CLERMONT-FERRAND Cedex 1 e-mail : [email protected] Tel : 04 73 31 80 00 - Fax : 04 73 31 80 08 Web : http://ica.inetech.fr/crdv EO - E.D.P.S. 69, rue Gorge de Loup – 69009 Lyon e-mail : [email protected] Tél. 04 72 53 98 26 - Fax. 04 72 53 98 14 Web : http://handy.univ-lyon1.fr/access/edps-eo/ Institut Montéclair 51, rue du vallon 49000 Angers e-mail: [email protected] Tel : 02 41 73 38 18..--...Fax 02 41 72 09 96 Web : http://www.monteclair.fr Pierre Reynaud Tel : 02 62 49 91 68 e-mail: [email protected] Web : http://www.pierre-reynaud.com/ BRAILLENET 08/04/02 77 2. LE LABEL ACCESSIWEB 1. Qu’est-ce qu’AccessiWeb ? Le label AccessiWeb est attribué à un site Web dont l’accessibilité aux personnes handicapées a été vérifiée. Dès lors, ce site peut afficher le logo Accessiweb sur sa page d’accueil. En contrepartie, les concepteurs s’engagent à ne pas modifier les principes de présentation (au niveau de la structure, de la technique ou du graphisme) sans en avertir BrailleNet. 2. Conditions d’attribution Pour obtenir le label AccessiWeb, le site doit : • Satisfaire aux recommandations internationales de la Web Accessibility Initiative (WAI) (niveaux de priorité 1 et 2 ) ; • Etre compatible avec les différentes plates-formes techniques (ordinateur, système d’exploitation, navigateur…) • Etre facile d’utilisation avec diverses aides techniques utilisées par les personnes handicapées. 3. Qui attribue le label AccessiWeb ? BrailleNet s’appuie sur un réseau d’experts agréés, formés à une méthode d’évaluation déposée (méthode INOVA). Les experts appartiennent aux organismes suivants : N. B. : Accessiweb est une propriété de l'association BrailleNet 12bis, rue Picpus - 75012 Paris BRAILLENET 08/04/02 78
