Il y aurait vraisemblablement plus d’une bonne méthode pour donner un atelier de formation sur l’accessibilité.

Une approche basée sur l’étude de cas et la résolution de problèmes me semblerait convenir pour les raisons suivantes:

• plus pratique que théorique
• ressemblera plus à un atelier qu’à un cours magistral
• intérêt suscité dès le départ
• sensibilisation faite à partir de mises en situation
• outillage en fonction des besoins
• etc.

JMD: Je ne l’ai jamais donné avec cette approche, mais je trouve ça plus intéressant même si on risque d’oublier certains aspects, ce qui est par ailleurs inévitable en seulement 6 heures. Il faudrait minimalement présenter nos sources, expliquer les niveaux de priorité et l’organisation (désorganisation) des points de contrôle.

Pour éviter l’impression de prescrire un «livre de recettes», il faudra suivre une séquence qui pourrait ressembler à ceci:

• mise en situation (vous allez tenter d’accomplir la tâche suivante…)
• simulation (les participants se heurtent à des difficultés et les expérimentent)
• problématisation (le site est inaccessible pour telles et telles raisons)
• énoncé de la solution (voici comment on fait pour éviter ce genre de problème)
• conséquences de la solution (on fait revivre l’expérience une fois le problème résolu)

JMD: Il faudrait penser comment on peut faire les simulations. Travaille-t-on avec JAWS ou ZoomText ou les deux? JAWS est disponible en version démo de 40 minutes autant de fois que nécessaire à condition de redémarrer la machine. ZoomText a une version démo de 30 jours seulement. Si on travaille avec JAWS, il faut prévoir des écouteurs. On peut aussi utiliser la visionneuse braille qui s’affiche au haut de l’écran et reproduit le contenu de l’afficheur braille. Peut-on imaginer cacher le bas de l’écran avec un carton pour simuler davantage l’expérience d’un utilisateur?

Cette séquence pourrait être répétée pour présenter chacun des problèmes d’accessibilité qu’on voudra traiter pendant l’atelier.

Contenu

Pour ce qui est du contenu il faudra bien faire un choix (et par conséquent se limiter), mais voici quelques problèmes qui pourraient être présentés:

• polices de caractère trop petites et impossible à agrandir
• texte inaudible lorsqu’interprété par un lecteur d’écran (je ne sais pas ce que tu veux dire)
• menu inutilisable parce qu’il repose sur des cadres, du Flash, du JavaScript, des images…
• historique brisé parce qu’une page s’est ouverte dans une autre fenêtre à notre insu
• image nécessaire à la compréhension du texte environnant, mais définie sans attribut ALT (surtout les images liens)
• formulaire sans LABEL impossible à remplir
• tableau incompréhensible une fois linéarisé
• libellé de lien incompréhensible hors contexte
• liens inutilisables lorsque le JavaScript est désactivé
• site où rien ne s’affiche parce que la page d’accueil est toute en Flash
• etc.
• structure de la page avec H1 à H6
• tableaux de données complexes mal défini.

JMD: Je les prendrais dans l’ordre des priorités présenté sur AccessibilitéWeb.

Même les notions théoriques pourraient (et gagneraient à) être présentées à partir d’un descriptif de situations rencontrées dans la pratique du Web.

Ressources

Je mets volontairement l’accent sur les ressources francophones.

JMD: Qu’entends-tu par ressources?

Documentation

Quelques documents m’apparaissent incontournables:

JMD: J’ai modifié l’URL des 65 points de contrôle.

Outils et conseils

Il faudra aussi présenter quelques outils de développement et de vérification, et ne pas avoir peur d’y aller de quelques conseils; par exemple:

• choisir le bon DOCTYPE et s’y tenir (prérequis, mais à rappeler)
• déclarer la langue principale au début du documentet signaler tout changement de langue dans le contenu
• soigner la rédaction des titres et des libellés de liens
• produire du (X)HTML conforme et sémantiquement correct (prérequis, mais à rappeler)
• valider son code via le validateur en ligne du W3C (http://validator.w3.org/)
• coder ses CSS pour tous les navigateurs d’abord, corriger pour Internet Explorer ensuite
• utiliser la barre de développement Web de Chris Pederick (http://smilissimo.free.fr/WebDeveloper.php?for=ff)
• valider ses CSS via le validateur CSS du W3C (http://jigsaw.w3.org/css-validator/)
• définir ses tailles de police avec des unités de mesure relatives
• renseigner l’attribut ALT des images significatives
• prévoir une alternative textuelle à tout contenu non textuel
• tester la validité des liens avec le vérificateur de liens du W3C (http://validator.w3.org/checklink)
• tester ses assortiments de couleurs avec Vischeck (http://www.vischeck.com/vischeck/vischeckURL.php) ou Juicystudio (http://www.juicystudio.com/services/colourcontrast.asp)
• tester ses pages avec le validateur d’accessibilité d’accès-pour-tous (http://www.acces-pour-tous.net/validateur/validateur.php) ou le validateur A-Prompt (http://aprompt.snow.utoronto.ca/french/index.html)
• utiliser d’autres outils d’accessibilité tels: Wave (http://www.wave.webaim.org/index.jsp), Bobby (http://bobby.watchfire.com/bobby/html/en/index.jsp) ou Cynthia (http://www.cynthiasays.com/)

JMD: Il faudrait comparer la barre de développement Web dans Firefox et la Barre d’accessibilité (http://www.snapfiles.com/dlnow/rdir.dll?id=108312) malheureusement seulement dans IE.

Souhaits

Quelque part en cours de route, il faudrait en profiter pour rappeler l’esprit originel du Web et du HTML: rendre les documents interopérables, c’est-à-dire lisibles et utilisables par quiconque depuis n’importe où, indépendamment de toute limitation matérielle ou logicielle.

Suivant cette démarche, une bonne définition de l’accessibilité viendrait [car il faudra bien en présenter une], mais en fin de journée plutôt qu’au début. Et cette notion, du moins je le souhaite, viendra briser l’idée réductrice voulant que l’accessibilité ne profite qu’aux personnes handicapées.

Normand Lamoureux