Les WCAG 2.0 sont de retours
samedi 26 mai 2007 à 14:50 :: Accessibilité
Depuis le 17 mai, une nouvelle version des WCAG 2.0 vient d'être soumise à commentaire public.
De ce que j'ai pu en lire, de très nets progrès ont été apportés au document.
Structure du document
Le langage utilisé est devenu beaucoup plus compréhensible. L'organisation du document a été revue pour en faciliter l'utilisation et en réduire sensiblement la taille, même si celle-ci reste très conséquente. Des efforts plus que significatifs ont été consentis sur ce point et c'est là une des grandes évolutions de cette version.
Après le "HD ready" le "Accessibility Supported"
Le concept tant décrié de "baseline" a été revu au profit du concept de "Accessibility Supported" qui signifie qu'une technologie est compatible avec les aides techniques et les fonctions d'accessibilité des agents utilisateurs. Des "Documented lists of Web technologies that have accessibility support" listent les fameuses technologies "Accessibility Supported" et permettront donc de savoir qu'elles sont les technologies utilisables pour rendre un contenu accessible.
Dans tout les cas, le contenu devra être disponible dans au moins une technologie considérée comme "Accessibility Supported". Si j'utilise une technologie non "Accessibility Supported" celle-ci ne devra pas bloquer l'utilisateur lors d'une navigation au clavier, ne pas déclencher de flash lumineux pouvant provoquer des crises d'épilepsie et permettre d'avoir accès à l'information sous un format accessible lorsque cette technologie est activée, désactivée ou non supportée. Jusque là tout va bien.
Voici, les critères permettant qu'une technologie soit considérée comme une "Accessibility Supported" :
- la technologie doit être supportée par les aides techniques
- la technologie doit être utilisable dans des agents utilisateurs "Accessibility Supported" dans au moins une des situations suivantes :
- la technologie est nativement supportée par des agents utilisateurs eux-même "Accessibility Supported" et largement diffusés
- la technologie est supportée par le biais d'un plugin largement diffusé et lui-mêmes "Accessibility Supported"
- le contenu est disponible dans un environnement fermé (comme un intranet ou une université) où l'agent utilisateur nécessaire pour le bon fonctionnement de la technologie est celui utilisé et est "Accessibility Supported"
- l'agent utilisateur nécessaire pour le bon fonctionnement de la technologie est disponible au téléchargement ou à l'achat dans des conditions qui ne désavantagent pas les personnes handicapées.
On peut déjà voir ici de nombreux problèmes potentiels :
- supporté par combien d'aides techniques, sur quelle plateforme ?
- qu'est ce qu'un plugin ou un agent utilisateur largement diffusés ?
Je peux donc dans de nombreuses situations considérer les technologies comme "Accessibility Supported" et ne leur prévoir aucune alternative, par exemple : faire des sites qui ne fonctionnent que pour internet explorer (voir pour une version particulière d'internet explorer), faire des sites entièrement en Flash, demander à tous d'avoir un navigateur (ou plus largement le système d'exploitation permettant de le faire tourner) vendu à un prix astronomique.
Il est explicitement indiqué dans le document que le groupe de travail n'a pas et ne spécifiera pas le nombre d'aides techniques ou de plateformes qui doivent être supportées. Je pense réellement qu'avoir Loretta Guarino Reid (ancienne de chez Abode et maintenant chez google) comme co-chef du groupe de travail a dû fortement influencer le sens pris par les WCAG 2.0 sur ce point.
Ce n'est pas fini, en plus de ces définitions plus que floues, les fameuses listes indiquant les technologies "Accessibility Supported" ne seront pas non plus, pour la plupart, établies par le W3C qui se contentera d'une liste sur les technologies issues du W3C. Vous pouvez donc faire confiance à Adobe pour déclarer Flash, PDF, appolo et consort pleinement "Accessibility Supported". La bonne nouvelle c'est aussi que grâce à tout cela on pourra dire qu' Ajax est accessible puisque sur IE7, winXP, Jaws8, c'est accessible.
Le seul cas où tout cela est vraiment effectivement bénéfique c'est lorsque le contenu est disponible dans une environnement fermé (comme un intranet ou une université) où l'agent utilisateur nécessaire pour le bon fonctionnement de la technologie est celui utilisé et est "Accessibility Supported" mais ça ne me semble pas la majorité des cas.
Tout cela me rappelle fortement cette mode marketing du "HD Ready" qui n'avait de "Ready" que le nom.
du côté de la conformité du code
Rien de neuf de ce côté mais pour une fois je ne leur donne pas tort, la conformité HTML n'est pas une garantie de l'accessibilité et non conformité n'est pas forcement synonyme de non accessibilité. C'est d'ailleurs la position qui a également été retenue pour le RGAA.
toujours des problèmes de mise en oeuvre
Contrairement à la version précédente, il est désormais nécessaire de satisfaire à tous les points de contrôle de niveau AAA pour satisfaire au AAA. Le groupe de travail nous averti donc d'ores et déjà qu'il sera quasiment impossible de se déclarer conforme AAA tant certain critères sont difficilement atteignables.
la déclaration de conformité
Sur ce point les propositions faites dans les scénarios de déploiements du RGAA sont très proches des évolutions qui ont été apportées dans cette version de WCAG 2.0. La principale différence est qu'avec WCAG 2.0, je ne déclare conforme que ce que je veux (par exemple juste la page d'accueil) alors que dans le RGAA par défaut tout doit être conforme et je ne peux exclure des contenus que dans des cas bien particuliers et justifiés.
les évolutions du contenu
Au niveau des directives en elles-même, rien n'a bougé par contre il y a quelques nouveautés intéressantes au niveau des points de contrôle mais toujours quelques bizarreries ou imprécisions dans les techniques et le document "Understanding WCAG 2.0".
Pour ma part, j'ai noté :
- la nécessite d'avoir des sous-titres pour les vidéos diffusées en direct sur le web en AA, je pense que AAA serait plus adapté vu la difficulté et le coût de mise en oeuvre.
- bizarrement l'absence de demande d'audio description pour ces mêmes éléments
- l'interdiction d'avoir des liens différenciés uniquement par la couleur (même le soulignement en hover ou focus ne valide pas le critère) donc tous les liens devront être soit soulignés, soit en gras, soit les deux.
- pour le contraste des textes ayant comme fond une image, il est demandé de vérifier lettre à lettre que le contraste est suffisant, une interdiction aurait été beaucoup plus simple, en l'état c'est parfaitement intestable.
- la possibilité de faire des liens hors contexte tout en étant conforme AA
le meilleur pour la fin, un nouveau critère demande désormais de pouvoir augmenter la taille des caractères à 200% ou de la diminuer à 50% sans perte d'information. Très bien me direz-vous, oui mais, il ne faut pas regarder les conditions demandées pour satisfaire le critère parce que c'est du grand n'importe quoi :
(précision une seule de ces techniques suffit pour valider le critère)
- utiliser une technologie (ici HTML) pour laquelle les agents utilisateurs ont une fonction de zoom (ouf on est sauvé IE7 ou Opera en a une donc j'ai rien à faire car pour qu'un site s'affiche mal avec un zoom natif faut vraiment le vouloir)
- utiliser le dimensionnent relatif des blocs et de la typo (l'effet produit étant alors identique à un zoom, je ne risque évidemment pas d'avoir de problème)
- utiliser un script gadget pour grossir/diminuer la taille (sans javascript point de salut)
- proposer des css alternatives (ah enfin une bonne idée)
Donc en gros pour résumer, vous pouvez continuer à faire vos sites avec des tailles de typo en pixels, pour ne pas passer le critère faudra vraiment le faire exprès.
Plus globalement, à mon sens les critères 3.2.1, 3.2.2, 3.2.5, toute la directive 3.3, et le critère 4.1.2 nécessitent encore beaucoup de travail, les cas d'erreurs, les exemples et les techniques suffisantes pour valider les critères sont bien trop flous, se contredisent parfois ou ne correspondent pas.
et la bonne nouvelle dans tout cela ?
La bonne nouvelle c'est que globalement l'évolution qui a été faite a été dans le bon sens. Malgré cela je pense que c'est encore loin d'être pleinement satisfaisant. L'autre bonne nouvelle, c'est que si jamais vous aviez du temps en trop après les commentaires sur le RGAA, vous avez jusqu'au 29 juin pour faire vos commentaires sur WCAG 2.0.
Le Référentiel Général d'Accessibilité des Administrations (RGAA) pour une accessibilité réelle et durable
mercredi 9 mai 2007 à 22:12 :: Accessibilité
Aujourd'hui se concrétise une partie du pourquoi je tiens ce blog depuis maintenant un peu plus d'un an. Ce blog permet de promouvoir l'accessibilité des sites et des services web et essaye de vous aider dans cette démarche. Depuis la loi du le 11 février 2005 et son article 47 imposant l'accessibilité des services de communication publique en ligne, nombres de responsables de sites ont commencé à s'intéresser à l'accessibilité et cela sans attendre le décret d'application de la loi.
Faute de documents officiels permettant de répondre avec précisions sur ce qui doit être fait , pourquoi et comment cela doit être fait mais surtout comment vérifier que cela a bien été fait, ils rencontrent bien des difficultés pour avancer convenablement dans leur démarche .
C'est pour répondre à ces questions que j'ai contribué à développer, pour le compte de la société dans laquelle je travaille et en collaboration avec Temesis, un nouveau document officiel : le RGAA, Référentiel Général d'accessibilité pour les Administrations.
Ce document produit sous l'égide de la DGME vient aujourd'hui de voir le jour et entre désormais dans une phase d'appel à commentaire public après 6 mois de travail et d'intense réflexion.
Dans ce document, nous avons abordé l'accessibilité sous un angle très pragmatique pour permettre à un maximum de personnes de rentrer dans une démarche d'accessibilité . Nous souhaitons amener le maximum de sites à un niveau minimum le plus rapidement possible. La démarche consistant à dire voilà l'objectif, débrouillez vous pour y arriver, je n'y crois pas, cela ne marche pas. Les personnes ne sachant pas par quelle face aborder le sujet renoncent souvent à s'y investir. A l'heure actuelle 97% des sites publics européens sont totalement inaccessibles bien que de nombreux pays aient déjà légiféré pour rendre obligatoire l'accessibilité au niveau AA WCAG 1.0.
Plus précisément, sur la base du contenu des WCAG 1.0 et 2.0 et de UWEM, nous avons établi, pour chaque point de contrôle WCAG 1.0, le pourquoi, le quoi, le comment et une liste de 194 tests unitaires permettant de vérifier la mise en oeuvre du quoi. Nous avons été plus loin que la sacro-sainte retranscription littérale des WCAG, devenu inadaptée et datée sur certains aspects, plus loin que UWEM en couvrant le niveau AAA.
Heureusement je n'ai pas effectué ce travail seul. Elie Sloïm a travaillé sur la méthode générale de déploiement, la structure du référentiel et des tests . Laurent Denis expert à tout faire du web que vous connaissez sans doute m'a prêté main forte pour la rédaction du contenu et des tests ainsi que sur pour le portage de tout cela dans dans un site qui tant qu'à faire, se veut respectueux du RGAA et de l'accessibilité.
Je penses que désormais l'administration et les concepteurs de site ont un document fiable et solide techniquement pour lancer ou poursuivre leur démarche. J'espère que le RGAA permettra à tous les acteurs de l'accessibilité d'agir vite, fort, pour faire de l'accessibilité numérique autre chose qu'un voeu pieux, d'en faire une réalité durable.
Je vous invite, à prendre connaissance du RGAA et à nous faire part de vos commentaires selon la procédure définie par la DGME afin d'améliorer encore ce document. Vous pouvez également consulter les billets de Laurent et de Elie sur le sujet, ils vous permettrons d'approfondir votre découverte du RGAA.
Dans les semaines à venir, je reviendrai sans doute à de nombreuses occasions sur le contenu du RGAA, espérant récupérer ainsi vos retours de façon non officiels mais en attendant je prend un peu de repos jusqu'à dimanche, bonne lecture à vous.
Teasing du 1er mai
mardi 1 mai 2007 à 20:22 :: Accessibilité
Pour célébrer la fête du travail, voici un petit teasing.
Ce projet tournant autour de l'accessibilité a monopolisé un part très importe de mon temps ces 6 derniers mois et devrait au plus tard être en ligne la semaine prochaine.

edit : allez encore un petit bout

Plus d'informations très prochainement.
P.S : Ceux qui savent sont priés de se taire (hein Elie et Laurent).
