Sebastien Posté 17 Juin 2004 Partager Posté 17 Juin 2004 Afin de travailler sur l'accessibilité efficacement, j'ai essayé de rediger une petite check list (2pages) accessibilité, plus digeste que les specifications du W3C. Ce document est essentiellement a destination des developpeurs. Les étoiles entre parenthèses correspondent aux priorités du W3C Qu'en pensez vous? des erreurs, des omissions? Mini Check-list accessibilité 1. Fournir des alternatives aux contenus visuels. -Attributs "alt" systématiques sur les images, puces, maps. (*) -Eventuellement Attribut "longdesc" quand longue description (rare). 2. Ne pas s'en remettre aux seules couleurs. -L'info doit être compréhensible en l'absence de couleur ainsi un lien ne doit pas se différencier que par la couleur, mais aussi par des enrichissement (gras, souligné etc) (*) -S'assurer d'un contraste suffisant entre fond et texte. (**) 3. Utiliser balisage et CSS de façon appropriée. -Autant que possible utiliser du texte mis en forme via CSS plutôt que des images. Sinon, utiliser l'attribut Alt. (**) -Abandonner les <font>, utiliser CSS pour le mise en forme du texte. (**) -Utiliser les balises selon leur sens sémantique, <h1> à <h6> pour les titres, <p> pour les paragraphes, <strong> pour mettre en gras, <ul> pour les listes et menus (<ol> quand nécessaire), quitte a redéfinir l'apparence via CSS (ex : italique). (**) -Créer des documents valides avec une DTD (Doctype). (**) -Utiliser des unités relatives (% ou em). 4. Utilisation du langage naturel. -Spécifier la forme complète des abréviations et acronymes lors de la première utilisation, soit dans le texte soit avec les attributs "abbr", "acronym", soit directement dans le contenu. (***) -Identifier le langage du document avec l'attribut "lang" appliqué à <html>. (*) 5. Tableaux accessibles. -Pour les tableaux de données, identifier entêtes de lignes et colonnes avec <th>, créer des sommaires avec l'attribut "summary", ajouter un "title". (*) -S'assurer que les tableaux peuvent être linéarisés, càd pouvant être lus logiquement dans un navigateur en mode texte. (**) -Eviter les tableaux imbriqués. 6. S'assurer que les pages "technologiques" se dégradent bien. -Un document sans sa CSS doit rester lisible. (*) -S'assurer que les pages soient lisibles quand les scripts, applets, et artefacts programmables sont désactivés ou non supportés. Dans le cas contraire proposer une alternative : <noscript>, <noembed>, <noframe> etc. (*) 7. Contenu variant dans le temps. -Eviter de faire clignoter ou bouger un contenu. Le cas échéant, permettre de figer le contenu (pause), ou fournier un contenu alternatif. (*) -Eviter les "refresh" automatiques (**) -Eviter les redirections automatiques coté client. Privilégier celles coté serveur. (**) 8. Assurer un accès aux interfaces intégrés. -L'utilisateur doit toujours conserver le contrôle de son interface, même si le site web a le sien. Pas de sites full screen. (**) 9. Indépendance par rapport au périphérique. -Développer un ordre logique de tabulation, avec l'attribut "tabindex", ou garder une conception de page logique. (***) -Prévoir des raccourcis clavier pour les liens les plus importants avec "accesskey". (***) 10. Utilisation des solutions intermédiaires -Ne pas produire de fenêtres successives ou à ouverture automatiques (ex : pop-ups), ne pas modifier la fenêtre active sans avertir l'utilisateur. (**) -Pour les formulaires, s'assurer que les étiquettes sont correctement positionnées par rapport aux contrôles. (**) -Placer du texte pour occuper l'espace dans les champs vides des formulaires (car vide mal supporté par certains interfaces). (***) -insérer entre les liens adjacents des caractères imprimables non hypertextes. (***) 11. Utilisation des technologies W3C -Eviter les technologies plus supportées, comme les "font". (**) -Prévoir un contenu alternatif quand on utilise une technologie non standard (ex : version HTML d'un doc word ou pdf). 12. Informations de contexte et d'orientation. -Donner un "title" à chaque frame. (*) 13. Mécanismes de navigation clairs. -Navigation cohérente. (**) -Faire des liens explicites, utilisant le cas échéant l'attribut "title". Eviter les "cliquez ici". (**) -Faire un plan du site. (**) -Faire une déclaration d'accessibilité, listant notamment les accesskey. (***) -Titre et balises metas pour chaque page. (**) 14. Documents clairs et simples. -Langage simple et clair. (*) D'autre part je comprend pas trop le point 1.3 : "Tant que les agents utilisateurs ne peuvent pas lire à voix haute le texte équivalent d'une piste visuelle, fournissez une desciption auditive des informations importantes de la piste visuelle d'une présentation multimédia. " Lien vers le commentaire Partager sur d’autres sites More sharing options...
Ganf Posté 17 Juin 2004 Partager Posté 17 Juin 2004 Qu'en pensez vous? des erreurs, des omissions? Je me permet de commenter en détail pour améliorer 1. Fournir des alternatives aux contenus visuels.-Attributs "alt" systématiques sur les images, puces, maps. (*) -Eventuellement Attribut "longdesc" quand longue description (rare). La formulation laisse entendre que : alt et longdesc servent à la même chose mais on ne doit mettre que du court dans le premier et du long dans le second on doit mettre des alt pour les puces et autres choses, j'ai peur qu'on comprenne qu'il faut mettre alt="puce" ou quelque chose du genre Abandonner les <font>, utiliser CSS pour le mise en forme du texte. (**) Pourquoi ? J'ai beau être totalement en faveur des CSS il ne faut pas se tromper de cible. Les <font> HTML sont autant accessibles que les color: et font-size: CSS, peut etre même plus. Celui qui ne les comprend pas ou qui ne sait pas les interpréter peut tout à fait les ignorer. C'est moins élégant, moins pratique, mais ça n'a rien à voir avec l'accessibilité à mon avis. -Pour les formulaires, s'assurer que les étiquettes sont correctement positionnées par rapport aux contrôles. (**) J'ai peur que ne comprenne que quelqu'un qui sait déjà ce qu'est <label> et à quoi ça sert. Nommer la balise pourrait être plus utile. -Eviter les technologies plus supportées, comme les "font". (**) cf plus haut. Le support HTML 4 est toujours là, il est largement plus répandu que CSS. Même si je ne le considère pas comme "à privilégier" <font> n'a rien à faire dans "plus supportés". XHTML n'a jamais remplacé HTML. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Monique Posté 17 Juin 2004 Partager Posté 17 Juin 2004 Bonjour, 1. Fournir des alternatives aux contenus visuels.-Attributs "alt" systématiques sur les images, puces, maps. (*) Si l'attribut alt est obligatoire, il est tout aussi important que son contenu soit significatif et adapté au contexte. Dans la mjorité des cas, l'attribut alt d'une image décorative devra être vide. 3.-Abandonner les <font>, utiliser CSS pour le mise en forme du texte. (**) La formulation prête à confusion et pourrait faire croire que la page n'est pas accessible du tout... elle l'est de niveau 1 3.<strong> pour mettre en gras strong ne sert pas à mettre en gras (même si c'est le comportement de la plupart des navigateurs graphiques) mais à marquer l'importance d'un texte. 3.-Créer des documents valides avec une DTD (Doctype). (**) Pas très clair... le doctype doit être renseigné et la structure de la page doit correspondre à celui qui est choisi. 4.-Identifier le langage du document avec l'attribut "lang" appliqué à <html>. (*) Le terme "langue" me semble plus approprié. 5. Tableaux accessibles. Pour les tableaux de données, il est important d'utiliser l'attribut headers (trop peu connu). 10.-Pour les formulaires, s'assurer que les étiquettes sont correctement positionnées par rapport aux contrôles. (**) Préciser l'usage de la balise label et des attributs id et for. 13.-Faire des liens explicites, utilisant le cas échéant l'attribut "title". Eviter les "cliquez ici". (**) Important aussi : ne pas placer de liens vers des cibles différentes sur le même texte. PS : plutôt que "technologies non supportées", parler de "balises dépréciées" C'est un excellent exercice que tu as fait... ça aide à mieux cerner les problèmes soulevés Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sebastien Posté 18 Juin 2004 Auteur Partager Posté 18 Juin 2004 Merci de vos conseils avisés qui m'ont permis d'ameliorer mon document alt et longdesc servent à la même chose mais on ne doit mettre que du court dans le premier et du long dans le second Tout à fait. Ca je comptais l'expliquer directement aux developpeur, pour ne pas encombrer le document, et dans la pratique longdesc sera amha tres peu utilisé. j'ai peur qu'on comprenne qu'il faut mettre alt="puce" ou quelque chose du genre Pour les puces, je vais preciser qu'il faut mettre une étoile (*) en attribut alt. Les images purement decoratives ne seront pas à commenter. Les <font> HTML sont autant accessibles que les color Oui (de niveau 1 comme le dit Monique) mais le W3C le conseille alors autant prendre le pli. strong ne sert pas à mettre en gras Effectivement, strong est une balise d'emphase (semantique) et non de présentation. Mais je me suis mis dans la tete des developpeurs et clients. Eux raisonnent en matière de "mise en gras" et non "de mise en emphase". Quand ils mettent un texte en gras dans un paragraphe, c'est pour lui donner de l'emphase généralement. Pour les tableaux de données, il est important d'utiliser l'attribut headers C'est noté C'est un excellent exercice que tu as fait Ca prend un peu de temps mais au moins ca force a comprendre, on apprend des balises (je suis pas developpeur), et surtout on y voit plus clair. Autant connaitre les divers points d'accessibilité des le depart que de rebidouiller sa page un grand nombre de fois... Lien vers le commentaire Partager sur d’autres sites More sharing options...
Ganf Posté 18 Juin 2004 Partager Posté 18 Juin 2004 Pour les puces, je vais preciser qu'il faut mettre une étoile (*) en attribut alt. Bonne question tiens. Je n'en suis pas sûr et j'en entendu les deux écoles. Pour : - c'est effectivement l'équivalent textuel Contre : - normalement le <li> suffit à repérer une liste et l'étoile risque de faire double emploi (surtout qu'à l'oral ça risque de ne pas être parfait) Mais de toutes façons ... une image de liste ne devrait-elle pas être en CSS ? mais le W3C le conseille Gaffe, le W3C conseille aussi des trucs idiots, et même des trucs négatifs (qu'il vaut mieux ne pas faire). Les WAI sont en train d'être réécrite, si tu veux te baser dessus regardes plutot les drafts de la 2.0 (bon, maintenant peut être que ce point précis est aussi dans la 2.0, je ne suis pas forcément du même avec que le W3C sur tout) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Monique Posté 18 Juin 2004 Partager Posté 18 Juin 2004 Bonjour, Pour l'attribut alt d'une puce, il vaut mieux le renseigner comme vide. Il faut penser au confort de l'utilisateur. Dans le cas d'une liste par exemple, le navigateur vocal dirait : item - texte utile Si on indique alt="*" il dira : étoile - item - texte utile Pour la balise strong, je ne suis pas de ton avis : pourquoi enseigner une erreur ? Ta liste est quand même destinée à ceux qui veulent rendre leur site accessible... il me semble aussi simple de parler de "l'importance" d'une partie de texte, quitte à expliquer oralement que celle-ci sera rendue en gras dans un navigateur graphique et par un ton de voix différent dans un navigateur vocal. Lien vers le commentaire Partager sur d’autres sites More sharing options...
finidori Posté 29 Juillet 2004 Partager Posté 29 Juillet 2004 Ne pas oublier tout de même de faire lire par différentes personnes. J'ai du changer une fois les couleurs de fond/de texte. Plusieurs lecteurs retraités ne distinguaient pas le texte à cause du ton sur ton, ni le texte clair sur fond sombre. Résultat: Texte sombre sur fond clair est ce qui passe le mieux. Il y a sûrement un tas de petits trucs comme ça. Mais rien ne vaut le test. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant