<C²: webløg />

Courriel - email address

Avatar Denis

mardi 19 août 2003
par Denis Boudreau

Accessibilité en 32 points

La semaine dernière au boulot, j'ai eu à rédiger une liste de conseils à mettre en pratique pour développer un site Web accessible pour une importante compagnie pharmaceutique canado-américaine qui souhaite refaire son site Web et en profiter pour le rendre complètement utilisable pour sa clientèle, fortement composée de personnes handicapés ou agées. On ne parle même pas ici de réaliser un site conforme aux normes (quoi je n'ai pas manqué l'occasion d'appuyer là-dessus), mais simplement de rendre l'éventuel site accessible aux personnes agées, aux gens atteints de limitations physiques ou fonctionnelles de tout type ou encore, plus simplement, de limitations technologiques...

Voici la liste de points que j'ai alors soulevé en l'espace d'une dizaine de minutes, en m'appuyant fortement sur des références comme "DiveIntoAccessibility" et "Building Accessible Websites". D'après vous, j'en ai oublié ? C'est un joyeux mélange de principes d'accessibilité, de respect de la sémantique et de validité du document, mais dans l'ensemble cela me semble des points dignes de mention :

  1. Sélection d'un doctype XHTML transitionnel
  2. Validité du code par rapport aux validateurs du W3C
  3. Utiliser un balisage sémantique
  4. Créer une séparation nette entre structure et présentation
  5. Avoir recours au maximum aux CSS afin de limiter le tagSoup
  6. Identification de la langue par défaut du texte
  7. Identification de tous changements de langue à l'agent utilisateur
  8. Définition de titres de pages significatifs
  9. Aide supplémentaire à la navigation par méta-information
  10. Créer des sauts de navigations pour accéder rapidement aux contenus
  11. Priorisation des contenus sur la navigation dans la structure du code
  12. Utilisation réfléchie des couleurs, contrastes
  13. Utilisation d'hyperliens réels, pas de liens en javascript
  14. Utilisation modérée de javascript, toujours assurer alternative
  15. Ajout d'attributs titre aux hyperliens et autres éléments HTML
  16. Instaurer une fonctionnalité de raccourcis claviers
  17. Ne pas ouvrir de nouvelles fenêtres, pas de pop up (surtout pas en javascript)
  18. Donner de véritables titres aux tableaux HTML, des sommaires, etc.
  19. Utiliser les tableaux pour l'affichage tabulaire
  20. Créer des alternatives aux flash (équivalences texte ou longdesc)
  21. Assurer que toutes les images possèdent des ALT
  22. Ne pas demander de dextérité fine pour naviguer dans les menus
  23. Ne pas forcer le recours à une police de caractère trop petite
  24. Utiliser seulement des polices en taille relative, pas absolues
  25. Permettre l'ajustement du texte à l'utilisateur final (styleSwitching)
  26. Tester les gabarits sous un screen reader, sans une souris, etc.
  27. Comparer la sortie des pages sous LynxViewer ou autre navigateur texte
  28. Ne pas utiliser de spacer.gif ou autre images transparentes pour créer de l'espace
  29. Créer une politique d'accessibilité expliquant l'effort soutenu
  30. Valider le site sous un service de validation d'accessibilité comme Cynthia Says
  31. Utiliser les listes HTML à leur plein rendement (éviter les <br />)
  32. Définir les acronymes et abbréviations dans les textes

Si vous voyez des choses auxquelles j'aurais oublié de faire mention, ne vous gênez pas et ajoutez-les à ma liste par le biais des commentaires. À terme, toute cette documentation se retrouvera archivée ici, pour le plus grand bénéfice de tous et chacun.

Denis Boudreau | 2003.08.19 @ 17:45

Alors, qu'en pensez-vous ?

Voici ce que vous aviez à en dire... vos impressions, recueillies à vif.

2003.08.20 @ 03:17 par BenLeTibetain

Bonjour, est-ce que le point 21 ne fait pas partie du 2 ?

Sinon, comme je viens de me mettre aux 'nouveaux standards', je trouve ça bien qu'il y ai une communauté francophone bien développée sur ce sujet.

Bon courage pour ton site.

PS : il y a toujours le numero de version 3.11 sur la plupart des pages...

Haut retour au début de la page

2003.08.20 @ 03:20 par Dam

Bonjour, est-ce que le point 21 ne fait pas partie du 2 ?<br /><br />Sinon, comme je viens de me mettre aux 'nouveaux standards', je trouve ça bien qu'il y ai une communauté francophone bien développée sur ce sujet.<br /><br />Bon courage pour ton site.<br /><br />PS : il y a toujours le numero de version 3.11 sur la plupart des pages...

Haut retour au début de la page

2003.08.20 @ 05:27 par Eric Daspet

1. Pourquoi xhtml ? coté accessibilité html est presque mieux placé. Pourquoi transitionnel ? accepter le transitionnel je ne vois pas de raisons de ne pas laisser choisir le strict si le développeur le veut, au contraire.

12. Une référence vers les daltoniens et les différentes formes de problèmes face aux couleurs serait bien. Ca concerne peu de monde mais c'est si simple à vérifier ...

17. C'est nettement contestable et contesté, surtout pour les popups. L'important est d'avoir un lien réel et accessible sans javascript. Déclencher une popup pour des choses précises n'est pas contre l'assessibilité (vu qu ele lien existe et marche) et peut même se révéler plus utilisable.

23. Je changerai en 'ne pas forcer le recours à une taille de texte spécifique'. Parce que 'trop petite' est largement subjectif, et c'est bien tout le problème (sinon on n'aurait pas besoin de mettre ce conseil). Ce qui est trop petit pour l'un peu etre trop gros pour l'autre.

23 24 et 25 ne me semblent faire qu'un. Le 25 est contestable AMHA car la lisibilité du site ne devrait dépendre d'un switcher CSS mais plus de la configuration par défaut.


Dans l'ensemble le tout me parait un peu vague. Quelques liens, quelques explications seraient les bien venues.
Et .. un classement plus ordonné permettrait d'éviter les doublon ou l'impression de fouilli (le fait de ne pas utiliser les <br> au 31 est finalement un sous point de la sémantique du 3 par exemple)

Haut retour au début de la page

2003.08.20 @ 15:48 par CYBERcodeur

Tout d'abord, milles excuses à toi Dam, qui a tenté de commenter ce carnet et qui, par la faute d'un php.ini manquant, s'est vu attribué le carnet d'un autre (en l'occurence, celui de BenLeTibétain). Le problème est maintenant réglé, de sorte que si tu repasses par ces pages et que tu as envie de reprendre ton commentaire, je serais très heureux de te lire.

Maintenant, pour répondre à Ben :

Effectivement, on pourrait t'accorder que l'un implique forcément l'autre, mais d'un point de vue striceement d'accessibilité, la pertinence de spécifier le recours au ALT ne saurait être surfaite. C'est effectivement vrai, autant en strict qu'en transitionnel qu'une image ne comportant pas de ALT ne passerait pas le test du validateur, mais le fait de traiter la problématique des images séparément me semblait une bonne marche à suivre, ne serait-ce que pour ancrer cette pratique dans la mentalité des développeurs avec qui je travaillerai sur ce compte (si nous le gagnons bien sûr).

Autrement, bien content de te retrouver parmi nous ! Et pour ce qui est des pages qui trainent encore une version 3.11, il faut mettre le blâme sur la paresse ou les horaires démentiels... Je vais bien finir par les modifier lorsque je trouverai un peu de temps :)

Haut retour au début de la page

2003.08.20 @ 16:51 par CYBERcodeur

Quant au message d'Eric :

HTML ou XHTML; lequel choisir ? AMHA, le débat entre HTML et XHTML devient aussi stérile que celui entre les PC et les MAC. Il est vrai que tant et aussi longtemps que les navigateurs principaux ( comprendre MSIE ) ne supporteront pas du vrai XHTML par le mime type approprié, il peut être discutable de vouloir coder en XHTML. Cependant, c'est à mon sens une attitude puriste qui, bien qu'elle soit noble, ne justifie en rien le fait de ne pas commencer tout de suite à coder avec ce que je considère être le langage de balisage du futur ( mis à part XML, mais tu comprends ce que je veux dire :).

On assiste en fait à une guerre philosophique entre deux camps, desquels nous ne sommes que de misérables représentants sans envergure : d'un côté, Mark Pilgrim et Ian Hickson qui jureront par HTML tant et aussi longtemps que les navigateurs ne supporteront pas tous application/xhtml+xml et d'un autre côté, les supporteurs de Jeffrey Zeldman qui veulent commencer aujourd'hui à travailler avec les technologies de demain, même si celles-ci ne sont pas entièrement supportées en date d'aujourd'hui.

La raison pour laquelle je proposais la direction de XHTML transitionnel dans une approche de Web accessible est assez simple; je sais pertinemment bien que le site en question sera construit avec des tableaux HTML et des CSS fusionnés dans le code avec un minimum de sémantique. Pourquoi ? Parce que les compétences ne seront tout simplement pas au rendez-vous pour assurer ce que j'aurais aimé être un site tout en XHTML 1.0 Strict ou 1.1, avec une structure sémantisée solide et une séparation comlète entre la balisage des pages et l'aspect de présentation. Je connais l'équipe avec laquelle je travaillerai sur ce projet ( si on le gagne ) et je sais d'avance où les cartes vont se brouiller. Avec une approche transitionnelle, j'obtiens alors le meileur des deux mondes ; une flexibilité accrue pour permettre à mon équipe de s'adapter et d'évoluer, tout en assurant la réalisation d'un site dûment accessible par l'application des règles du WCAG.

Maintenant, il est vrai que la mention d'une 'clause' pour les daltoniens mériterait de faire partie de ma liste. En étant un moi-même, c'est une réalité que je connais bien ( du moins, dans le cadre de mes propres limitations chromatiques ) et il est clair que ma propre expérience avec la déficience sera mise au test pour évaluer les choix de couleurs. Cependant, l'utilisation des outils appropriés ( faudra que je retrouve les bookmarks ) nous permettra de juger de la netteté des contrastes et de trancher à savoir s'il y a problème ou non. L'important dans toute cette histoire demeure de ne pas se fier seulement sur des indicatifs de couleurs pour assurer des points cruciaux d'utilisation ou de navigation.

Pour ce qui est du débat entourant les pop ups, encore là, nous faisons face à deux camps s'opposant. Sauf que dans ce cas-ci, c'est moi qui suis dans le camp des puristes ( à chacun son tour ;). Mon seul référant consiste à penser à l'utilisateur inexpérimenté qui navigue en full screen en 800x600 et qui ne se rend pas compte qu'une nouvelle fenêtre vient de remplacer la précédente. Du coup, son bouton BACK ne fonctionne plus et il est complètement déboussolé. Par contre, on s'entend à merveille pour ce qui est des liens simulés par JavaScript; cette manière de coder une linéarité dans le site est exclusive et devrait en tout temps être évitée.

Pour le point 23, je t'accorde totalement raison. Je viens tout juste de le faire changer dans la proposition d'ailleurs. La libre interprétation de ce qui est trop petit ou trop gros est un autre beau terrain de mésentente entre les utilisateurs. Nous en savons tous quelque chose... :)

Il en va de même pour ton commentaire sur les points 23, 24 et 25... Effectivement, l'utilisateur devrait toujours être en mesure de paramétrer tout un site selon ses besoins et de remanier les tailles de police selon son bon vouloir ( styleSwitcher ou non ) -- d'ailleurs, le jour où tous les navigateurs pourront se vanter d'être de vrais navigateurs, le styleSwitcher n'aura plus sa raison d'être... la vérité repose dans un support irréprochable du alternate stylesheet.

Sur ce, merci pour le commentaire, c'est constructif comme toujours et ça alimente la réflexion ! :)

Pour conclure, je dois ajouter que la liste est vague volontairement, puisqu'elle s'adressait à priori à un comité qui n'a jamais vu une ligne de code de sa vie. L'idée était de sortir rapidement des points de référence, sans pour autant les développer afin de ne pas trop les perdre ( mais en leur démontrant que c'était quand même quelque chose qui n'était pas ridiculement facile à intégrer ). Et pour ce qui est du fouillis, ben ça, c'est moi en dix minutes ! ;)

Haut retour au début de la page

2003.08.21 @ 02:10 par Dam

c'est encore moi :)

Je souhaitais donc dire que en lisant

'Sélection d'un doctype XHTML transitionnel
...
Créer une séparation nette entre structure et présentation'

le point 1 pouvait donc etre XHTML strict, mais Eric y a fait allusion apres mon passage et tu y as répondu en parti.
Il reste que la séparation entre le contenu et la forme fait a priori parti du cahier des charge donc pour tes petit camarades il leur sera plus facile de codé en strict (a force de se faire jetter par le validateur on progresse vite :) et repondre eficacement au point 4 du cahier des charges

Dam

Haut retour au début de la page

2005.06.07 @ 06:33 par Nicolas

Je voudrai faire un commentaire sur les tailles relatives pour les polices de caractères.

J'ai appliqué le système en choisissant des tailles de police en équivalent ('em'). La taille varie selon les préférences du navigateur.

MAIS le nombre de personnes ne connaissant pas cette préférence m'a l'air beaucoup plus élevé que le nombre de ceux qui pourraient l'utiliser. Depuis que j'ai placé le système, j'ai eu plusieurs plaintes de visiteurs parce que les caractères devenaient illisibles (car trop petit). Et ce, malgré une information (bannière vers une page d'aide) soutenue.
Par contre, je n'ai eu personne qui aie trouvé ça bien.

De plus, Firefox et Netscape peuvent agrandir les caractères plus facilement (touches de raccourci Ctrl et + ou -), et s'en foutent de savoir si la taille de texte est relative ou fixe.

Donc, si j'étais malvoyant, je choisirait plutôt Firefox que de ne regarder que des sites en taille relative.

Quelqu'un a un autre avis ?

Haut retour au début de la page

2005.06.16 @ 05:10 par DenisB.

En fait, si j'étais non voyant, en fait, je préfèrerais le navigateur de Microsoft car c'est le seul qui fonctionne avec Jaws (car Jaws repose sur la technologie MSAA - Microsoft Active Accessibility).

Si j'étais semi-voyant, je choisirais Opera, qui permet de nombreuses fonctionnalités pour supporter l'accessibilité que d'autres navigateurs ne proposent pas, comme le zoom dans la page (et les images), les feuilles de style utilisateurs, l'affichage en écran fermé et plus encore...

Si je préfère le navigateur FireFox au-dessus de tous les autres, c'est uniquement parce que j'ai le luxe de pouvoir le préférer... ;)

Haut retour au début de la page

Les commentaires et trackbacks sont désormais fermés. Pour toute remarque, vous pouvez toujours nous contacter.

Pisteur (Trackback)