Les WCAG 2.0 sont de retours écouter le billet : Les WCAG 2.0 sont de retours - mp3 - nouvelle fenêtre

samedi 26 mai 2007 à 14:50 :: Accessibilité :: #66 :: rss

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.

Trackbacks

Aucun trackback.

Les trackbacks pour ce billet sont fermés.

Commentaires

1. Le samedi 26 mai 2007 à 20:40, par Râleur

"Le langage utilisé devenu beaucoup plus compréhensible."
-> Dommage qu'il n'en aille pas de même pour la rédaction de ce post qui, bien qu'intéressant, se révèle être franchement pénible à lire et intégré au vu du nombre inacceptable d'énormités grammaticales...

Réponse de aurélien levy le samedi 26 mai 2007 à 22:49

Arf on a même plus le droit de publier un billet avant de sortir manger sans se relire ;), ça devrait être mieux maintenant.

2. Le samedi 26 mai 2007 à 20:58, par billyboylindien

"tous les liens devront être soit souligné, soit en gras, soit les deux."
=> Je trouve cela un peu contraignant :(.

Merci pour toutes ces infos.

3. Le dimanche 27 mai 2007 à 11:07, par Jérôme Mulsant

> 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.

Et un peu vain : yorunokoe.net/ressources/...

4. Le mardi 5 juin 2007 à 20:27, par Matt

Merci pour l'info.

5. Le jeudi 7 juin 2007 à 12:48, par Christophe Strobbe

Je voudrais attirer votre attention sur Conformance Requirement 4 (www.w3.org/TR/2007/WD-WCA... et le document "Alternate Versions Conformance Requirement" (www.w3.org/WAI/GL/2007/05... Trois alternative sont présentées. Le groupe de travail dit que la première alternative est la plus accessible. La présence des deux autres doit donc être interpretée comme si le groupe pourrait choisir une des alternatives moins accessibles. Ceux qui préfèrent la première alternative sont donc priés de réagir en très grand nombre...

Ajouter un commentaire

Les commentaires pour ce billet sont fermés.

Calendrier

« mai 2007 »
lunmarmerjeuvensamdim
123456
78910111213
14151617181920
21222324252627
28293031

Catégories

Sondage

Lequel des ces tutoriaux préféreriez vous voir traiter en priorité ?

Syndication

Archives

Il y a 105 billets publies sur ce blog, alors n'hésitez pas à fouiner

Liens