[accessibilite-numerique] critique wcag 2

[Villain]

Bonjour,

J'ai beaucoup de respect et d'admiration pour Joe mais je trouve, 
malheureusement son article trop "orienté", c'est très dommage car il 
mets le doigts sur plusieurs problèmes inhérents à WCAG 2.0

La critique principale de Joe est de dire que WCAG 2.0 est "ambigue", 
"floue", "difficile à comprendre" et pour certains items dit-il 
"innaplicable".

Je ne suis pas vraiment de cet avis, il est vrai que WCAG 2.0 change de 
point de vue et développe une nouvelle approche : on quitte le checklist 
technique pour aborder un processus moins "formel", je veux dire moins 
"je coche une case c'est bon" au profit d'un processus "analytique" où 
le jugement et l'expérience auront une part prédominante.

Ceci dit, la critique de Joe sur la "complexité" et le manque de 
"clarté" de WCAG 2.0 est juste. Cela va demander de la part de 
l'intervenant un niveau de maitrise, d'expérience et de qualification 
bien supérieur à celui requis pour WCAG 1.0 où on trouve foison 
"d'experts de moins d'une semaine".

Je ne suis pas certain que ce soit une si mauvaise chose !

Joe dit que WCAG 2.0 souffre d'avoir eu comme ambition de vouloir rendre 
accessible tout type de contenu, c'est vrai que c'est ce qui est au 
coeur de WCAG 2.0 qui remplace par exemple la notion de validité du code 
par celle de "robustesse".

On peut faire cette critique, elle est juste et fondée, à l'unique 
condition que l'on relève les énormes limitations de WCAG 1.0 où un 
contenu avec une adresse email cryptée en ascii/hex pour lutter contre 
le spam ne peut être validé pour l'accessibilité pour une stupide 
question d'entité Html qui n'à pas le commencement du début du quart 
d'une importance quelconque.

Et on le sait tous : les cas où l'on se retrouve à devoir gérer des 
écarts aux normes WCAG 1.0 sont légions, le cas des textes en image en 
est un autre très emblématique.

Voici une première lecture "à chaud" de sa liste d'arguments où je 
relève, disons, quelques remarques qui font preuve à tout le moins d'une 
lecture "orientée" :) :

*2. A future website that complies with WCAG 2 won't need valid 
HTML---at all, ever. (More on that later.) *
You will, however, have to check the DOM outputs of your site in 
multiple browsers <http://www.w3.org/TR/WCAG20-TECHS/#F28-procedure> and 
prove they're identical.

C'est un fait que WCAG 2.0 abandonne la notion de "formal grammar" et de 
validité de code pour la remplacer par une notion plus "ambigue" qui 
réfère au concept de "robustesse" : "Support compatibility with current 
and future user agents (including assistive technologies)".

Maintenant quel est le seul moyen pour garantir ça si ce n'est 
d'utiliser un langage normalisé ce qui passe par un "maximum" de 
validité ???

On n'empêchera pas les margoulins de déclarer de la soupe de tags 
"robuste" mais on permettra à des clients d'accepter de faire des 
efforts en direction d'une normaisation des langages si on peut accepter 
les écarts à la norme.

J'ai en ce moment un cas de ce genre : Refaire l'outil pour produire du 
code valide c'est trop cher mais les erreurs de validation n'ont pas 
d'importance : le code est éminemment "robuste".

Vivement WCAG 2.0 que je puisse dire à mon client : "ok on fait cette 
première étape, on verra le zéro défaut plus tard" !

Et pour ma part je trouve qu'il est effectivement plus important de 
garantir la structure du point de vue du DOM qui est le coeur de la 
restitution que du point de vue de la validité du code qui est 
essentielle mais peut s'affranchir sans effet de certaines erreurs.

3. *You can still use tables for layout. (And not just /a/ 
table---table/s/ for layout <http://www.w3.org/TR/WCAG20-TECHS/#N11001>, 
plural <http://www.w3.org/TR/WCAG20-TECHS/#N11138>.)
*
Là Joe est à la limite de l'interpétation tendancieuse le point F43 ne 
concerne pas l'usage des tables mais celui d'une mauvaise utilisation de 
balisage pour créer une relation de structure entre des contenus.

Et il est précisé que l'usage de tables de layout n'est pas une cause 
d'échec, si si elles sont utilisés comme tables de layout !

Et de toute manière quel expert censé et raisonnable pourrait prétendre 
interdire l'usage des tables de layout, ce serait interdire 
d'accessibilité une immense part du web pour un simple problème 
"philosophique".

Je précise quand même que je me range dans la catégorie "les tables de 
layout c'est le mal" mais que je valide sans état d'âme des structures 
par tableaux si tant est que je constate leur "robustesse"... :)
*
**5. You'll be able to define entire technologies as a "baseline 
<http://www.w3.org/TR/WCAG20/complete.html#baseline>," meaning anyone 
without that technology has little, if any, recourse to complain that 
your site is inaccessible to them.
*
Je ne peux que m'inscrire en faux sur l'interprétation que fait Joe de 
cette recommendation qui au contraire permet, enfin, de pouvoir 
travailler sur des structures applicatives fondées sur Html et surtout 
sur Xml/Xhtml, comme des interfaces intranets où la simple utilisation 
d'une technologie "propriétaire" dont on à garantis par ailleurs 
l'accessibilité est déclarée "invalide" pour WCAG 1.0 alors qu'il n'y à 
aucune raison de le faire.

*6.you'll be able to define entire directories of your site as 
off-limits to accessibility (including, in WCAG 2's own example, all 
your freestanding videos 
<http://www.w3.org/TR/WCAG20/complete.html#conformance-scoping>).
*
Là aussi cet item est un grande avancée de WCAG 2.0, non pas en ce qu'il 
permet n'importe quoi, comme le laisse supposer Joe mais en ce qu'il 
permet de gérer des cas limites, par exemple l'inclusion publicitaire de 
contenus issus d'affiliation qui se contrefichent de l'accessibilité.

WCAG 1.0 dit "désolé monsieur votre site est innacesssible, adressez 
vous à votre agence pub et corrigez le problème" et le monsieur il dit 
"Ha ok ben alors tant pis".

Pour ma part si la condition à l'effort d'un client qui veut rendre son 
contenu accessible est de conserver des bandeaux de publicité affiliés 
innacessibles et si tant est que j'ai vérifié qu'ils ne genent en rien 
je dis banco, je dis pas "ha non désolé c'est pas possible, supprimer 
les pubs et faites moi un beau site accessible mais en faillite".

Si on est pas près à ce genre de compromis pour faire de l'accessibilité 
il faut changer de métier.

Et croyez bien pour autant que je suis particulièrement tatillon sur les 
compromis !!
***
7. Not that anybody ever made them accessible, but if you post videos 
online, you no longer have to provide audio descriptions for the blind 
at the lowest "conformance" level 
<http://www.w3.org/TR/WCAG20/complete.html#N10516>. And only prerecorded 
videos require captions at that level.

*Là aussi le débat est ouvert : Je suis assez d'accord avec Joe et pour 
ma part j'aurais conservé les flux live dans le champs d'application du 
critère à ce niveau
En même temps c'est aussi un cas ou certains compromis peuvent être 
acceptables si ils permettent d'engager de la part de l'éditeur une 
reflexion et une démarche.
Par ailleurs cela ne concerne que le niveau 1.

*8.Your podcasts may have to be remixed so that dialogue is 20 decibels 
louder than lengthy background noise 
<http://www.w3.org/TR/WCAG20/complete.html#visual-audio-contrast-noaudio>.

*Je ne comprends pas la position de Joe, où est le problème de devoir 
fournir des flux audio clairs et intelligibles ?
Mais peut-être que je ne comprends simplement pas ce qu'il veut dire.

*9. You can put a few hundred navigation links on a single page and do 
nothing more, but if you have two pages together 
<http://www.w3.org/TR/WCAG20/complete.html#navigation-mechanisms-skipcb> 
that have three navigation links each, you must provide a way to skip 
navigation.

*D'un certain point de vue on peut considérer que la limitation du 
nombre de liens par page relève plus de la qualité et de l'utilisabilité 
que de l'accessibilité.

Je ne sais pas me déterminer la dessus mais je sais parfaitement 
démontrer à mon client que 100 liens par page c'est trop et pas pour 
l'accessibilité mais simplement pour tout le monde !

Enfin dans une présentation d'un sommaire de documentation technique où 
nous avons une page qui n'est qu'une liste de liens ordonnés il n'y à 
aucun soucis à en avoir plusieurs centaines au contraire, 
l'accessibilité va se jouer sur une TOC et des Bypass pas sur la 
quantité de liens.

Remarque également valable pour une carte de site, on fait comment si on 
limite le nombre de liens ????

Pour le bypass je ne comprends pas ce que ça viens faire dans cette remarque

*10 You can't use offscreen positioning to add labels (e.g., to forms) 
that only some people, like users of assistive technology, can perceive. 
/Everybody 
<http://www.w3.org/TR/UNDERSTANDING-WCAG20/#content-structure-separation-programmatic-intent-head>/ 
has to see them.
*
La critique est fondée, ce point ne devrait pas relever de 
l'accessibilité mais de l'ergonomie et de la qualité, mais entres nous, 
il me semble plus facile de justifier un écart à la norme pour le cas 
d'un formulaire à controle unique que de devoir batailler et gérer un 
conflit pour convaincre un client que son magnifique formulaire à 20 
contrôles avec des labels invisibles c'est une grosse bétise même si 
c'est "validé".

*11 CSS layouts, particularly those with absolutely-positioned elements 
that are removed from the document flow, may simply be prohibited 
<http://www.w3.org/TR/WCAG20-TECHS/#N100C7> at the highest level. In 
fact, source order must match presentation order even at the lowest level.*
 
La aussi j'ai du mal à suivre Joe, le point référent me semble limpide : 
On ne doit pas utiliser de positionnement CSS qui modifie le *sens 
*donné par le  flux et l'exemple donné me semble particulièrement approprié.

*12 Also at the highest level, you have to provide a way 
<http://www.w3.org/TR/WCAG20/complete.html#N107C8> to find all of the 
following (e.g Definitions of idioms and "jargon")*

Oui c'est une contrainte forte mais il est précisé : "for identifying 
specific definitions of words or phrases used in an unusual or 
restricted way 
<http://www.w3.org/TR/WCAG20/complete.html#unusual-restricteddef>,"
Ce qui de mon point de vue change tout : le sujet ce n'est pas de 
fournir un glossaire systématique mais quand c'est utile et nécessaire : 
Banco !
*
*Et pour finir juste pour adoucir ma critique des propos de Joe :

*13. You also have to provide an alternate document if a reader with a 
"lower secondary education level" couldn't understand your main 
document. (In fact, WCAG 2 repeatedly 
<http://www.w3.org/TR/WCAG20/complete.html#N1089F> proposes 
<http://www.w3.org/TR/WCAG20-TECHS/#F19> maintaining separate accessible 
and inaccessible pages. In some cases, you don't necessarily have to 
improve your inaccessible pages as long as you produce another page.)

*Oui Joe, tu à raison c'est aussi stupide que WCAG 1.0 qui sur ce point 
n'est ni applicable ni appliqué.
Ce sera pareil dans ce cas, mais il est vrai que le Working Group aurait 
pu en faire l'économie... :)


Je n'est pas trop le temps de m'intéresser au reste qui contiens des 
points de vue intéressants, j'essaierai de trouver le temps d'ici ce soir

Jean-pierre
*



*s.billard at free.fr a écrit :
> Oui l'article est assez dur. Je n'ai pas vraiment examiné la version 2 de WCAG,
> mais des guidelines se doivent d'être le plus compréhensibles possibles, et
> sans ambiguité. La version 1 n'était déja pas simple, mais avait été assimilée
> depuis le temps.
>
> Concernant la traduction, c'est un travail assez énorme pour un document qui
> risque d'être modifié et lu par un public restreint qui comprend en général
> l'anglais non ?
>
> Sébastien Billard
> http://s.billard.free.fr/referencement/
>
>   
>> Suite à cela, je pense qu'il serait urgent de mobiliser des ressources
>> pour la traduction de la dernière version proposé de ces wcag 2.0
>>     
>
> _______________________________________________
> accessibilite-numerique mailing list
> accessibilite-numerique at list.accessiweb.org
> http://list.accessiweb.org/mailman/listinfo/accessibilite-numerique_list.accessiweb.org
>
>   

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: /pipermail/accessibilite-numerique_list.accessiweb.org/attachments/20060523/c7f09c9e/attachment-0001.htm