|
|
Centre de ressources et de recherche sur l'accessibilité du web | |
||||
|
|
|
|||||
|
|
|
|
|
|
|
|
 |
Vous êtes ici : Accueil > Label AccessiWeb > Critères AccessiWeb > 23 critères AccessiWeb d'Argent (version linéaire) |  |
 |
|
|
23 critères AccessiWeb d'Argent (version linéaire)En-tête du document:Ce document a été créé le 19 décembre 2003 en français. Les seuls documents officiels et valides des critères AccessiWeb sont ceux mis en ligne sur le site www.accessiweb.org et correspondant à la date du 19 décembre 2003. Contenu du document:Ce document contient la liste des 23 critères du label AccessiWeb d'Argent affichés linéairement. Plusieurs critères sont accompagnés de commentaires destinés à fournir des indications supplémentaires.
1. Eléments graphiques.1.6 : Les zones de chacune des images MAP sont-elles ordonnées de manière logique ? Commentaire :
Pour la liste des départements français, par exemple, il est préférable de les classer par ordre alphabétique. Avec certaines aides techniques, les zones réactives d'une "image MAP" se lisent linéairement. Si les zones réactivent d'une image MAP représentent une liste non ordonnée (les départements français par exemple), certains utilisateurs ne pourront pas choisir un élément d'une telle liste aisément. 1.7 : Pour chacune des images MAP, les zones de l'image MAP sont-elles définies juste après la déclaration de l'image MAP ? Commentaire :
Lorsque les zones réactives d'une image MAP ne sont pas codées immédiatement après la déclaration de l'image MAP, un utilisateur parcourant linéairement la page lira le commentaire général de l'image (image possédant l'attribut USEMAP), puis il lira le contenu de la page et lira enfin les commentaires associés aux zones réactives (AREA SHAPE) si celles-ci sont codées en fin de page. Dans cet exemple, l'accès linéaire à l'information ne correspond pas à sa présentation visuelle. 1.9 : Il convient de remplacer un texte sous forme d'image par un texte mis en forme. Cette règle est-elle respectée ? Commentaire :
Il est très souvent aisé de mettre du texte en forme par l'intermédiaire d'une feuille de style plutôt que de mettre du texte sous forme d'image, tout en gardant le même aspect graphique. A part le cas de contraintes graphiques strictes où il ne sera pas possible de transformer de façon équivalente le texte mis sous forme d'image, l'application de cette recommandation va permettre à un utilisateur malvoyant, par exemple, d'interagir avec la taille des caractères pour lire plus aisément les informations. Un texte dans une image empêchera cette option. 2. Cadres.2.7 : L'attribut LONGDESC est-il présent pour expliquer l'interaction entre les cadres ? Commentaire :
L'attribut LONGDESC permet de définir dans un fichier annexe l'interaction des cadres les uns par rapport aux autres par exemple. 2.8 : L'attribut LONGDESC est-il pertinent ? Commentaire :
Pour les aides techniques reconnaissant cet attribut LONGDESC, sa présence permet à un utilisateur navigant de cadres en cadres indépendamment des autres de comprendre plus facilement comment naviguer de cadres en cadres. 3. Couleurs.Aucun critère d'Argent n'appartient à cette thématique.
4. Multimédia.Aucun critère d'Argent n'appartient à cette thématique.
5. Tableaux.5.5 : Dans un tableau de données, lorsqu'un titre de colonne dépasse 15 caractères, l'attribut ABBR est-il utilisé ? Commentaire :
Un titre de colonne (TH) est long lorsqu'il dépasse 15 caractères. L'attribut ABBR permet à certaines aides techniques de reprendre l'abréviation du titre de colonne pour l'associer à la cellule qui lui fait référence. Il faut veiller à ce que le contenu de l'attribut ABBR soit pertinent et soit en rapport avec le contenu de l'en-tête de colonne auquel il se réfère. Lorsqu'un tableau de données est correctement construit, une synthèse vocale est capable d'indiquer à l'utilisateur à quel titre de colonne se réfère une cellule. Quand le titre de colonne est long (exemple : Marque du véhicule), l'attribut ABBR va obliger la synthèse vocale à n'annoncer que le mot "marque". L'utilisation de l'attribut ABBR permet un confort de lecture supplémentaire pour les utilisateurs de synthèses vocales. 6. Liens.Aucun critère d'Argent n'appartient à cette thématique.
7. Scripts.Aucun critère d'Argent n'appartient à cette thématique. 8. Eléments obligatoires.8.3 : Des éléments de description de la page sont-ils présentes en début de code source ? Commentaire :
Les balises de description de page sont les suivants : META, CHARSET... Par exemple, si vous développez un site en Europe de l'ouest, il faut utiliser l'attribut CHARSET suivant : ISO-8859-1. Si la balise CHARSET est absente (ou mal renseignée), la table des caractères utilisée dans la page pourra être mal interprétée par certains navigateurs. 9. Structuration de l'information.9.3 : Y a-t-il un plan du site ? Commentaire :
Le plan du site 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. Le plan du site doit pouvoir être consultable de manière équivalente sur toutes les pages du site. 9.4 : Y a-t-il une page d'aide expliquant les principes de navigation à l'intérieur du site ? Commentaire :
Cette page est utile pour tout utilisateur qui désire connaître la façon dont a été pensé le site Web. Elle est obligatoire pour prévenir les utilisateurs des aménagements réalisés sur le site : raccourcis claviers, barre de navigation internes ... 9.5 : A partir de n'importe quelle page du site, la page d'aide est-elle atteignable de manière identique ? Commentaire :
La page d'aide peut être atteignable grâce à un raccourci clavier, la répétition du lien vers la page d'aide en haut et bas de page ... 9.6 : Y a-t-il un moteur de recherche interne au site ? Commentaire :
La présence d'un moteur de recherche indexant les pages du site permet aux utilisateurs de trouver plus aisément les informations qu'ils recherchent. 9.7 : A partir de n'importe quelle page du site, le moteur de recherche est-il atteignable de manière identique ? Commentaire :
Le moteur de recherche peut être atteignable grâce à un raccourci clavier, la répétition du lien vers la page de moteur de recherche en haut et bas de page ... 10. Présentation de l'information.10.4 : Des valeurs relatives sont-elles utilisées pour dimensionner les tableaux et définir la taille des polices de caractère ? Commentaire :
Il est conseillé d'utiliser des valeurs en pourcentages pour dimensionner les tableaux d'un site Web. Il est également conseiller d'utiliser des valeurs en pourcentages, "em", "SMALL", "MEDIUM", "LARGE", "XX-LARGE"... pour dimensionner les tailles de caractères dans les feuilles de style. 10.5 : Si des valeurs absolues sont utilisées, le sont-elles sans conséquence sur l'affichage de l'information ? Commentaire :
En utilisant des valeurs absolues dans une page, il faut veiller à ce que l'information affichée dans la page soit toujours disponible, lors de changements de résolution d'écran, d'élargissements de tailles de polices de caractères par exemple. Exemple : Une page optimisée en 1024*768 avec une taille de caractère de 12 points par défaut doit pouvoir être lue sans perte d'information par un utilisateur dont la résolution d'écran est de 800*600 et qui décide d'agrandir ses caractères en désactivant les styles imposés dans la page. 10.6 : Est-ce que les polices de caractères présentes sur la page appartiennent à la famille de polices de caractères sans sérif ? Commentaire :
Il convient d'utiliser des polices de caractères sans sérif (sans empattement) qui soient compatibles avec tous les systèmes d'exploitation (Windows, Mac, Linux...). Pour cela, il faut indiquer au navigateur au moins un nom de police. Si cette police n'est pas trouvée dans le système d'exploitation, la police par défaut est alors utilisée. Cette police est "Times New Roman" sur un PC, et "Times Roman" sur un Mac... C'est pourquoi il est recommandé de spécifier plusieurs noms de polices, ainsi que la famille de polices sans sérif. Dans la feuille de style par exemple, placer la police préférentielle en premier puis une police plus généralement répandue, éventuellement d'autres choix de polices et enfin, la famille de polices sans sérif. 11. Formulaires.11.2 : Les textes associés aux champs de formulaires donnent-ils leur fonction exacte ? Commentaire :
Il faut éviter, par exemple, d'écrire "faites votre choix" répété plusieurs fois pour des listes déroulantes figurant sur la même page. Lors d'une lecture hors contexte le texte "faites votre choix" ne renseigne pas l'utilisateur sur la nature des informations à saisir. 11.3 : Est-ce que la disposition des champs de formulaire par rapport aux textes qui leur sont associés ne pose aucune ambiguïté ? Commentaire :
Dans le cas d'un formulaire classique associant horizontalement un texte à son champ de saisie, des études ergonomiques précisent que la distance entre le champ de saisie et le texte associé ne doit pas être supérieur à deux espaces. Si l'espace est trop grand entre ces deux éléments, les personnes qui utilisent un zoom d'écran , par exemple, ne savent plus à quel texte est destiné le champ de saisie. 11.4 : La balise FIELDSET est-elle présente pour encadrer des blocs d'information de même nature ? Commentaire :
Dans un même formulaire, plusieurs champs de saisie de même nature (les champs "nom", "prénom", "date" et "lieu de naissance" constituent le groupe de champs "Etat civil") peuvent être regroupés par l'intermédiaire de la balise FIELDSET (dans le cas d'une page en HTML). 11.5 : La balise LEGEND est-elle présente pour donner un titre au bloc d'informations encadré par la balise FIELDSET ? Commentaire :
Dans le cas d'une page en HTML, l'utilisation de la balise LEGEND (associée à la balise FIELDSET) permet de donner un titre à chaque bloc d'information. 11.8 : Les informations sont-elles organisées dans un ordre logique dans les listes de choix ? Commentaire :
Les listes de choix doivent être organisées de manière logique pour que tout utilisateur puisse l'interpréter correctement et aisément. Par exemple, la liste des départements français est plus facile à consulter si elle est proposée selon un classement alphabétique. 12. Aide à la navigation.12.1 : La navigation dans l'ensemble des pages du site est-elle cohérente ? Commentaire :
L'accessibilité d'un site se mesure aussi par l'homogénéité et la cohérence de construction et de structuration des pages les unes avec les autres. Les efforts liés à la structuration des pages auront un impact direct avec la facilité de navigation et de lecture à travers les pages du site. 12.4 : Y a-t-il des liens facilitant la navigation dans la page ? Commentaire :
Il est important de donner la possibilité à l'utilisateur de "passer" le menu, souvent composé de nombreux liens, pour accéder directement au contenu de la page (lien "invisible" en haut de page par exemple). Proposer aussi des liens de retour vers le haut de page lorsque les pages sont longues... 13. Contenus accessibles.13.8 : La présentation de la page est-elle réalisée sans détourner certaines balises de leur fonction d'origine ? Commentaire :
Les recommandations WAI recommandent d'utiliser le HTML à bon escient. Ex : Il ne faut pas : - utiliser la balise BLOCKQUOTE, prévue à l'origine pour les citations, uniquement pour créer un décalage du texte. - utiliser la balise UL, prévue à l'origine pour créer des listes, uniquement pour créer un décalage du texte. De manière générale, ne pas utiliser les balises (B, CENTER, BASEFONT, APPLET, DIR, FONT, ISINDEX, MENU, S, STRIKE et U) et les attributs (ALIGN, BGCOLOR, HEIGHT...) qui sont définis comme non valide dans la dernière version du HTML. |
||
 |
Aide - Plan du site - FAQ - Contact - Partenariats - Mentions légales |