Checklist pour l'accessibilité

[Denis]

Bonjour tout le monde,

Je me demandais si certains d'entre vous connaissaient un document sur le Web qui faisait état d'un checklist pour respecter l'eccessibilité sur le Web, genre les recommandations de la WCAG ou de DiveintoAccessibility, mais bonifiés d'exemples conrets en terme de code afin d'aider les développeurs à les intégrer facilement à leur pratique.

Je me prépare à commencer la rédaction d'un tel document et j'aimerais m'inspirer de queque chose d'existant, si une telle chose existe bien sûr.

[Clair de Lune]

bonjour denis

va voir ici, c'est peut-être ce que tu cherches ?

[Denis]

Merci mais non, ça je connais bien, c'est la traduction par Karl Dubost de DiveIntoAccessibility. C'est excellent, mais je cherche plus que ça.

Je veux quand même faire un document dans cet esprit là, mais non pas orienté weblogs propulsés par une solution de CMS quelconque (dans ce cas-ci, MT, Blogger ou Radio), mais bien un document qui prendrait chacun des points pertinents aux trois niveaux du WCAG et qui les expliciteraient de manière cohérente pour le développeur soucieux d'appliquer une recette qui fonctionnerait à tout coup pour faire un site accesible sans trop se prendre la tête... et à ma connaissance, curieusement, il n'y en a pas encore.

[Clair de Lune]

ça tu as raison, il n'y a pas encore beaucoup de ressources détaillées et aisément assimilables pour les nouveaux venus dans ce sujet, et ça fait défaut, j'en bave pour trouver des réponses simples et non équivoques

ça sera cool quand tu auras fini, j'en profiterai pour essayer de comprendre, je suis sûr que tu seras meilleur pédagogue

bon courage

[Denis]

Merci, c'est gentil. Je vous tiendrai au courant bien évidemment, par l'intermédiaire de mon carnet web et de cet excellent forum auquel je prends de plus en plus goût.

Qui plus est, un document comme celui-là, ça se fête !

[Steph. K.]

Bonjour,

Je ne sais pas si tu connais déjà www.acces-pour-tous.net mais c'est le même constat qui m'a amené à monter ce site il y a un peu plus d'un an.

De toutes façons je t'encourage vivement à monter un nouveau site car je suis persuadé que de redire les mêmes choses avec un langage différent ne peut être que bénéfique pour l'accessibilité des sites internet.

[Denis]

Stéphane, tu me demandes à moi si je connais ton site ?

J'en ai parlé à plusieurs reprises par le passé ! Et moi qui croyait que tu me lisais. Je suis dévasté !

[Steph. K.]

Au temps pour moi... cybercodeur fait partie des blogs que je consulte régulièrement.

Je peux même te dire qu'il faisait partie du panel de sites me permettant de détecter les faux-positifs au cours du développement du validateur.

[Denis]

Tiens, c'est flatteur ça... merci beaucoup

[LaurentDenis]

Denis, tu te souviens du doc IBM sur l'accessibilité dont j'avais commencé la traduction l'année dernière (projet abandonné pour des raisons de droits d'exploitation) ?

Je crois que c'est exactement ce que tu cherches.

[Denis]

Ça me dit vaguement quelque chose... tu te rappelles de l'URL ?

[LaurentDenis]

http://www-306.ibm.com/able/guidelines/web/accessweb.html

[Denis]

Super ! Merci. Je le note et l'ajoute à ma liste de ressources pour le grand jour !

[Mado]

Cahier de charges Accessibilité

BlindSurfer Décembre 2003

Conditions nécessaires à loctroi du label BlindSurfer (Priorité 1):

Eléments graphiques:

1a. Tout élément graphique (jpeg, gif, animated gif, images de mise en page, etc...) doit être pourvu, via un attribut alt, dune alternative textuelle significative (pas de nom de fichier).

1b. Pour tout graphique complexe (plan de villes, organigramme, diagramme, ...) un lien doit être ajouté à lattribut alt, lien vers une page de texte qui décrit lélément.

1c. Pour tout élément graphique porteur dun texte, lattribut alt doit contenir la totalité de ce texte.

Tableaux de données:

2a. Veillez à ce que les tableaux de données puissent être lus ligne par ligne par des personnes qui ne peuvent en avoir une vue densemble.

2b. Pour des tableaux complexes, il faut prévoir un lien vers une page de texte qui décrit ce que le tableau contient.

2c. Evitez de laisser des cellules vides dans des tableaux de données.

2d. Définissez par les balises adéquates les en-têtes de ligne et de colonnes.

2e. Pour faciliter lidentification de la position dune cellule dun tableau de données, utilisez les balises HTML prévues dans ce but.

Eléments Multimédia:

3a. Pour toute information parlée (wav, mp3,...), prévoyez une page alternative contenant une description textuelle.

3b. Pour tout segment vidéo (avi, webcam, QuickTime,...), prévoyez une page alternative contenant une description textuelle tant de la bande son que de la bande image.

3c. Faites en sorte que toute séquence audio audible en arrière-plan puisse être désactivée par le visiteur.

Codage des couleurs:

4. Evitez de coder des informations en nutilisant que des couleurs (où il est donc nécessaire de reconnaître la couleur pour comprendre le contenu). Prévoyez une alternative textuelle visuelle et en attribut.

Pages complexes:

5a. Pour toute page qui, pour une raison quelconque (technique, structurelle et/ou interne), est tellement complexe quelle ne peut être rendue accessible, il faudra fournir une alternative textuelle.

5b. Pour tout fichier PDF complexe ou protégé, il faudra fournir une alternative textuelle en Word ou en HTML.

Langue:

6a. Si le site contient des fragments de texte en langues diverses, il est indispensable que la langue naturelle de chaque page sensible soit indiquée via la balise adéquate.

6b. De plus, tout changement de langue au sein dune page doit être indiqué via les balises adéquates.

Hyperliens:

7a. Tout élément graphique auquel est couplé un hyperlien doit être pourvu dun attribut alt qui définit clairement la destination du lien.

7b. Tout hyperlien textuel doit être tel quil définit clairement la destination du lien. Il doit être compréhensible indépendamment de son contexte. Des liens tels que « cliquez ici » ou « plus dinfo » sont inadéquats.

Navigation:

8a. La totalité du site doit être utilisable (avec toute sa fonctionnalité, p.ex. le remplissage et lenvoi de formulaires) sans employer la souris. En dautres mots, la navigation doit être totalement réalisable au moyen de raccourcis clavier.

8b. Lusage de lattribut On Change dans les fenêtres déroulantes est à exclure.

Cadres (Frames):

9a. Chaque cadre doit avoir un nom et un titre significatifs, tous deux choisis dans la langue naturelle du site.

9b. Pour assurer une navigation aisée, il nest pas permis dutiliser plus que deux niveaux de cadres.

9c. Le fait quun cadre vide (dummy frame) soit éventuellement présent doit être explicitement mentionné dans le nom et le titre du cadre.

9d. Faites en sorte que la taille de chaque cadre puisse être modifiée et/ou munissez-le dune barre de défilement.

Images cliquables (Image-maps):

10a. Pour les images client-side, des alternatives visuelles seront prévues par le biais dattributs alt tant pour limage elle-même que pour les zones cliquables; dans ce dernier cas, les alternatives textuelles définiront la destination de chaque lien.

10b. Pour les images server-side, limage doit être pourvue dune alternative textuelle définissant la fonction de limage par le biais dun attribut alt. Comme pour les zones, un attribut alt nest pas possible, il faudra prévoir un texte alternatif reprenant tous les hyperliens de limage.

Objets programmatiques:

11a. Pour tout Javascript, veillez à fournir un texte alternatif (p.ex. via la balise noscript) pour le contenu et la fonctionnalité offerts par le script.

11b. Pour tout Javascript, veillez à fournir un texte alternatif (p.ex. via la balise noscript ou via un sitemap) pour tous les liens générés par le script.

11c. Pour toute applet, veillez à fournir un texte alternatif (p.ex. via la balise noscript) pour le contenu et la fonctionnalité offerts par lapplet.

11d. Pour toute applet, veillez à fournir un texte alternatif (p.ex. via un sitemap) pour tous les liens générés par lapplet.

11e. Pour toute animation Flash, veillez à fournir un texte alternatif.

11f. Pour toute animation Flash, veillez à fournir un texte alternatif (p.ex. via un sitemap) pour tous les liens offerts par les éléments Flash.

11g. Faites en sorte que le contenu dynamique quun objet programmatique crée soit accessible par des fragments de texte de fonctionnalité équivalente. Veillez à ce que ces équivalents textuels soient modifiés en synchronisme avec le contenu dynamique.

11h. Veillez à ce que le clignotement ou le mouvement (dailleurs à éviter si possible) quun objet programmatique créerait puisse être désactivé.

Réglages du Browser:

12a. Veillez à ce que toutes les pages du site soient telles que les réglages suivants des browsers graphiques restent en tout cas utilisables : choix des polices et de leur taille, choix de la couleur du texte et du fond.

12b. Veillez à ce que la fonction zoom que certains browsers offrent soit pleinement utilisable.

Mise en forme:

13a. Faites en sorte que la mise en page réalisée par des tableaux reste logique après linéarisation des pages (qui ne permet plus au lecteur davoir une vue globale de la page).

13b. Veillez à éviter les changements brutaux de luminosité et de couleur.

13c. Assurez-vous que les pages restent lisibles si le browser ne supporte pas les CSS.

13d. Evitez les animations gif dont la fréquence, la taille ou la couleur peuvent perturber les lecteurs malvoyants ou dyslexiques.

Fenêtres:

14a. Toute fenêtre popup ou fenêtre complète nouvellement ouverte doit être pourvue dun bouton de fermeture accessible et activable via le clavier.

Formulaires:

15a. Le remplissage et lenvoi dun formulaire doivent être réalisables sans utiliser la souris. En dautres mots, tout formulaire doit être totalement utilisable via les raccourcis-clavier.

15b. Un ordre de tabulation bien conçu est indispensable pour permettre un remplissage facile dun formulaire via le clavier.

15c. Pour des formulaires très complexes, il faudra prévoir une version textuelle (HTML ou Word) qui pourra être remplie séparément et renvoyée par courriel ou par Fax.

Compatibilité avec les Browsers:

16a. La totalité du site doit être accessible et utilisable avec un browser textuel tel que Lynx.

Mesures daccessibilité complémentaires (non obligatoires pour le label BS : Priorité 2):

Eléments graphiques:

1a. Evitez demployer des éléments graphiques pour représenter du texte, des lignes de séparation ou des symboles dénumération ; privilégiez lusage des possibilités offertes par HTML.

Tableaux de données:

2a. p.m.

Pages complexes:

5a. Pour chaque fichier PDF non protégé, prévoyez une alternative accessible (HTML ou Word).

5b. Pour chaque document Excel ou Powerpoint, prévoyez une alternative accessible (HTML ou Word).

Langues:

6a. Même pour les sites unilingues il est utile dindiquer la langue naturelle de chaque page via la balise adéquate.

Hyperliens:

7a. Un hyperlien couplé à un fragment de texte est préférable à un hyperlien couple à un élément graphique.

Navigation:

8a. Faites en sorte que la structure de navigation soit uniforme sur la totalité du site.

8b. Offrez une table de matières pour toute page longue.

8c. Choisissez un ordre de tabulation logique.

8d. Offrez une information sur la structure du site via un sitemap.

8e. Limitez le nombre dhyperliens par page à une valeur raisonnable (évitez de dépasser 20 liens par page).

8f. Si le nombre de liens doit, malgré tout, être important, utilisez efficacement les techniques suivantes : regroupement logique des liens, niveaux de liens avec expansion, possibilités de court-circuitage des liens.

8g. Evitez dutiliser sur une même page des liens synonymes (pointant vers le même lien).

8h. Evitez dutiliser sur une même page des liens homonymes (ayant le même nom mais pointant vers des cibles distinctes).

8i. Sur chaque page du site, prévoyez un lien vers la page daccueil.

8j. Prévoyez des caractères de séparation entre deux liens adjacents.

8k. Offrez des alternatives par raccourcis clavier pour des liens importants et répétitifs.

8l. Si un lien est dirigé vers un site externe, signalez-le explicitement; si ce site externe n'est pas accessible, on avertira le lecteur.

Cadres (Frames):

9a. Restreignez lusage des cadres..

9b. Si, néanmoins, des cadres sont indispensables, prenez les mesures suivantes :

· Nemployez pas de cadres vides (dummy frames),

· Employez la balise noframes pour offrir une version sans cadres de même fonctionnalité

Images cliquables (Image-maps):

10a. Préférez toujours lusage dimages cliquables du type client-side.

Objets programmatiques:

11a. Si vous utilisez Flash MX, suivez les recommandations daccessibilité de Flash MX.

Mise en page:

13a. Choisissez une mise en page uniforme sur tout le site.

13b. Séparez clairement contenu, structure et mise en page. Définissez la présentation par des feuilles de style CSS et placez celles-ci dans un fichier séparé.

13c. Utilisez un langage de markup spécifique tel que MathML plutôt que des éléments graphiques pour le contenu.

13d. Choisissez une présentation lisible pour le texte:

· utilisez des polices sans serif et évitez litalique,

· évitez les écarts trop marqués dans la taille des caractères,

· utilisez des unités de taille relative pour le format de fragments de texte,

· utilisez les balises de titres pour structurer le contenu et pas pour formatter le texte,

· évitez de présenter des informations clignotantes ou défilantes (proscrivez les attributs « blink » et « marquee » !),

· employez les textes soulignés pour les liens et rien que pour eux.

13e. Veillez à un bon contraste et à des couleurs nettes pour les éléments graphiques.

13f. Evitez les pages à autorafraîchissement périodique.

Fenêtres:

14a. Essayez déviter totalement lusage de fenêtre popup ou louverture de nouvelles fenêtres dans le navigateur.

14b. Si, néanmoins, vous utilisez des fenêtres popup ou de nouvelles fenêtres, signalez clairement dans le texte du lien quune nouvelle fenêtre va souvrir.

Formulaires:

15a. Attribuez à chaque champ une alternative textuelle adéquate via lattribut titre et, ceci, surtout si létiquette dun champ ne peut pour quelque raison que ce soit être placée directement à côté du champ correspondant.

15b. Placer les noms de champ directement à côté de chaque champ et employez de préférence une ligne par champ.

15c. En début de page, placez directement le curseur dans le premier champ par usage de lattribut tabindex.

15d. Prévoyez pour chaque formulaire un bouton de reset.

Compatibilité avec les Browsers:

16a. Veillez à ce que la totalité du site soit accessible et utilisable avec une majorité de browsers textuels et graphiques.

Philippe van Bastelaer

ONA-Blindsurfer

par exemple c'est ca que tu chercher?

[Denis]

Oh oui

J'en ai trouvé une autre version hier alors que j'ai suivi une formation en accessibilité, mais je te remercie pour celle-ci je vais les comparer. Essentiellement, ce sont les 65 points de contrôles issus des 14 règles du Web Content Accessibility Guideline... mais je veux les présenter d'une manière plus intéressante et surtout moins technique pour les développeurs. Ça va très certainement aider. Merci beaucoup pour le temps que tu a pris pour les rechercher.

[yobiwan]

http://www.braillenet.org/accessibilite/guide/

GUIDE BRAILLENET à l'usage des webmestres pour une meilleure accessibilité des sites publics aux personnes handicapées

C'est le guide que nous avions rédigé en 2002 pour la direction interminesterielle à la réforme de l'état. Il est un peu viellot mais encore d'acutalité sur pas mal de choses.

Sinon les techniques de WAI sont bein faites pour aides les gens à developper accessible

Nous sommes entrain de créer une nouvelle version de ce guide.

[Monique]

Denis, connais-tu ce site (en anglais) web accessibility learning modules ?

Il me semble particulièrement fouillé, avec de nombreux exemples pratiques.

[Denis]

Denis, connais-tu ce site (en anglais) web accessibility learning modules ?

Il me semble particulièrement fouillé, avec de nombreux exemples pratiques.

Non, je ne le connaissais pas du tout, c'est la première fois que j'en entends parler... merci beaucoup, ça a l'air vachement intéressant (j'ai le droit de dire vachement ? Pour le québécois que je suis, ça sonne un peu faux )

Je vais le fouiller et j'en sortirai très certainement quelque chose.

[Monique]

Non, je ne le connaissais pas du tout, c'est la première fois que j'en entends parler...

Bonjour Denis,

Ce site a fait du chemin avant de te parvenir...

parti des Etats-Unis, listé sur un site belge d'origine flamande (BlindSurfer qui attribue les labels en Belgique), trouvé par une belge wallonne et renseigné sur un site français... à l'intention d'un québécois

Mais il faudrait peut-être que les responsables viennent prendre quelques leçons de référencement sur le Hub... il n'est pas normal que tu n'en aies pas eu connaissance

[Denis]

Double lol !!!

D'une part pour le trajet, c'est vrai qu'on ne peut nier l'internationalisation du Web en de pareilles circonstances.

Deuxièment pour le référencement. C'est vrai que pour ne l'avoir jamais vu, c'est qu'il y a un problème. Je fouille le sujet tous les jours depuis plus de deux ans et jamais je n'en ai eu connaissance... Si j'étais pas si occupé, je regarderai le code... ça doit pas être tip top au niveau optimisation (même si le contenu lui semble excellent).

Quoi qu'il en soit, maintenant que je l'ai trouvé, je ne le lâche plus... Parce que sinon Dieu seul sait quand je le retrouverai.

[Monique]

Roberto Ortelli (weblogger.ch) vient t'annoncer la publication d'une Grille d'analyse de sites du point de vue de leur accessibilité.

Cette liste a été établie par une association australienne, Royal Blind Society's Adaptive Technology Consultants.

J'y ai trouvé le préalable qui manque désespérément dans les critères d'évaluation de site et d'attribution de label : que le code et les feuilles de style soient valides !

Before you start

Whilst the following will not confirm a website is accessible, the following checks should quickly be made on any site.

• Does the HTML / XHTML etc validate on World Wide Web Consortium (W3C; http://validator.w3.org)?
  
  
  
  
  
• Does the style-sheet validate (http://jigsaw.w3.org/css)?
  

Un exemple à suivre !!!

[Denis]

J'y ai trouvé le préalable qui manque désespérément dans les critères d'évaluation de site et d'attribution de label : que le code et les feuilles de style soient valides !

Venant de Russ Weakly et de sa bande (le Web standards Group), on ne pouvait s'attendre à moins comme influence.

[Gilbert Paquet]

Bonsoir Denis,

Bien que ça ne corresponde pas exactement à ce que tu recherches comme document, une source/inspiration de plus à mettre en signet, des fois que tu ne l'aurais pas déjà fait. Différentes moutures à télécharger, en prime. À +.

http://www.cio-dpi.gc.ca/clf-nsi/guide/guide_f.asp

[Denis]

He, he.... tiens, un autre copain ! Salut Gilbert, bienvenue dans le Hub ! Merci pour ce lien, c'est vraiment très intéressant et ça tombe réellement très bien. Je vais suivre ça avec beaucoup d'intérêt.

[LaurentDenis]

Pour mémoire, tu connais sûrement le Référentiel accessibilité des services Internet de l’administration française.

Il y a quelques points criticables, mais c'est une bonne approche "réaliste" de l'accessibilité, par opposition à l'approche purement théorique des standards.

D'autre part, il est l'un des rares à lier/articuler explicitement accessibilité et utilisabilité (ergonomie si vous préférez).