Cette page regroupe les commentaires sur le débat au sujet de l'article To Hell with WCAG 2.0
publié conjointement par Aurélien Levy sur Fairytells, Monique Brunel sur Webatou et Jean-Pierre Villain sur WebonOrme
J'ai rapidement lu l'article et malgré toutes les critiques que j'ai pu noter, je pense tout de même que WCAG 2 représente un progrès. Pas immense certes, mais un progrès tout de même. Etant constamment en veille, je pense que dans moins de 3 ans, les changements seront fulgurants notammenet via les nouvelles technologies qui vont arriver.
Si entre 2000 et 2006 il y a eu un progrès de 50 (sur une base de 100), je prévois entre 2006 et 2009 un progrès de 120.
Ce n'est que mon avis. Il est partagé par certains et pas par d'autres.
Enfin, je compte aller au salon de la recherche et de l'innovation qui aura lieu du 8 au 11 juin à Paris. J'espère découvrir quelques technos prometteuses. Je tiendrais tout le monde au courant sur le blog.
Sur ce, je tiens à dire que vous avez fait du bon boulot sur la traduction =)
Bonjour Ramenos
"Je pense tout de même que WCAG 2 représente un progrès"
C'est difficile de dire si WCAG 2.0 est un "progrès", je dirais plutôt une évolution et surtout, c'est ce qui le caractérise, un changement de point de vue.
On passe de la vision plutôt technique de WCAG 1.0 à une vision plus globale et plus abstraite.
C'est la base des critiques que fait Joe, quelque fois à juste titre.
Nous aurons besoin de documents d'accompagnement pédagogiques, voire de véritables méthodes d'application de WCAG 2.0
C'est pourquoi il nous est apparus important de tenter de lancer ce débat dans la sphère francophone.
Jean-pierre
Depuis quand une recommandation, une spécification ou un document technique a-t-il à être facile à lire et à comprendre par le premier venu?
Je pose la question car ce semble être le principal reproche adressé aux WCAG 2.0.
Bonjour Normand,
Il est vrai qu'on en demande souvent beaucoup trop à ce genre de document technique.
La critique de Joe se concentre sur le fait que WCAG 2.0 serait incompréhensible même pour des professionnels et à fortiori pour des webmasters néophytes dans ce domaine.
En même temps c'est un des reproches qu'on peut faire à WCAG 1.0 de "sembler" applicable par des profils plutôt néophytes avec les effets pervers qu'on connait.
Jean-pierre
Il y a un point qui me semble un peu flou (vous allez me dire, s'il n'y en avait qu'un...). Il ne me semble pas que les WCAG 1.0 vont disparaître... or il me semble avoir lu cela dans la traduction de Jean-Pierre.
Que je sache, les problèmes d'accessibilité des pages n'ont pas changé. Pourquoi ces guidelines devraient-elle tout d'un coup cesser d'être applicables aux "sites" Web?
Sur le même sujet, si les 1.0 ne disparaissent pas, je pressens que bon nombre vont s'infiltrer dans les imprécisions des 2.0 pour justifier un peu n'importe quoi.
Bonjour Gilles,
L'expression que j'ai traduite par "WCAG 1 vient juste de célébrer son septième anniversaire et s'apprête à disparaître" est "WCAG 1 just celebrated its seventh birthday and is closing in on the end of its life."
WCAG 2.0 sera le cadre normatif pour l'accessibilité du web dés son adoption finale.
A ce moment WCAG 1.0 ne disparaitra pas, pourra toujours être utilisé si on en a envie, mais la référence, notamment dans le cadre règlementaire, sera WCAG 2.0
Mais c'est, à mon sens, un débat biaisé : WCAG 2.0 inclu naturellement WCAG 1.0 qu'il corrige et y rajoute la possibilité d'intégrer dans une démarche d'accessibilité toutes les technologies qui ne sont pas du Html.
Donc, si on veut ne faire que du WCAG 1.0, il suffira de définir le cadre de référence WCAG 2.0 comme étant exclusivement consacré à "html".
On peut donc faire du WCAG 1.0 dans le cadre WCAG 2.0.
C'est pour cette raison que je réagis assez mal à la proposition de Joe qui est de dire : On met WCAG 2.0 à la poubelle et on se bricole du WCAG 1.0+++.
Jean-pierre
D'accord, je comprends mieux. Cette histoire de "cadre de référence" peut en soi être une excellente chose, comme une porte ouverte à tous les abus.
Si on considère que les 1.0 sont intégrées dans le cadre de référence HTML des 2.0, ça me va. Presque. Parce que les 1.0 ne sont pas parfaites!
Pour aller plus loin dans ce sens, le W3C n'a pas pour vocation de publier des recommandations sur des technologies propriétaires. Or les WCAG 2.0 sont sensées être assez générales pour êtres déclinables en plusieurs cadres de référence. Qui se chargera du boulot?
Par exemple, dans quel "cadre de référence" tombera AJAX? Parce que la techno équivalente estampillée W3C n'est pas un standard de facto, et tout porte à croire que c'est XMLHttpRequest qui va l'emporter. Comment les WCAG se déclinent-elles dans ce cas-là? Qui définira les cadres de références et rédigera les directives correspondant à ces cadres (je préfère la traduction ligne de conduite, directive est trop normatif)?
AJAX n'est pas forcément le meilleur exemple, dans la mesure où la seule contrainte de validité porte sur le DOM... et qu'il existe des solutions pour les navigateurs plus répandus.
Le grand classique, Flash, est un autre cas. Ou bien (pourquoi pas?) Open Document. C'est une norme ISO, après tout, et on peut fort bien imaginer des interfaces utilisant ce format (des suites bureautiques faisant office de véritables bureaux à distance, par exemple). Il supporte des langages de macro, est interfaçable avec une base de données... Que donneraient des WCAG 2.0 pour un tel cas?
Bonjour,
" Si on considère que les 1.0 sont intégrées dans le cadre de référence HTML des 2.0, ça me va. Presque. Parce que les 1.0 ne sont pas parfaites!"
Oui, nous disposons même d'un document permettant de rapprocher WCAG 1.0 de WCAG 2.0
Enfin un certain nombre d'items ont été corrigés, modifiés ou abandonnés.
"Or les WCAG 2.0 sont sensées être assez générales pour êtres déclinables en plusieurs cadres de référence. Qui se chargera du boulot?"
Nous sommes là au coeur de l'ambition de WCAG 2.0.
Le cadre de référence est la simple indication des technologies que l'on décide de rendre "conformes WCAG 2.0" pour les agents utilisateurs qui les supportent pleinement.
Pour AJAX cela nous donnerait simplement : HTML+Javascript (+ ou -)XML selon la nature de l'application.
"Qui définira les cadres de références et rédigera les directives correspondant à ces cadres (je préfère la traduction ligne de conduite, directive est trop normatif)?"
Les cadres de références peuvent être définis par n'importe qui, l'Auteur, une organisation, un gouvernement, un client...
Il n'y aura pas de "directives" pour un cadre de référence précis, ou, plus exactement elles existent déjà, ce sont les WCAG 2.0
Chaque technologie du cadre de référence devant respecter les recommandations qui lui sont applicables.
Pour reprendre l'exemple d'une application AJAX :
- Avec le cadre de référence Html seul, je dois produire une alternative au procédé AJAX, nous sommes en territoire connu c'est WCAG 1.0
- Avec le cadre de référence HTML+Javascript je dois, en plus de l'alternative, rendre pleinement fonctionnel les dispositfs javascript pour les agents utilisateurs qui le supportent, ou ceux que j'aurais référencés par exemple dans le cas d'une fonctionnalité s'appuyant sur un UA ou une version de l'UA précise.
Je dois, en outre m'assurer que ces technologies et les dispositifs destinés a les rendre accessibles ne bloquent pas les alternatives pour les UA qui ne supportent pas les technologies du cadre de référence.
Enfin je dois m'assurer que les technologies qui ne sont pas référencées dans le cadre de référence ne bloquent pas l'accès au contenu.
De cette manière, et même si cela peut paraitre un peut compliqué au début, WCAG 2.0 est supposé pouvoir s'appliquer à toute technologie, normalisée ou pas, existantes ou futures, tout en appliquant les principes de base sur l'alternative qui sont le coeur de WCAG 1.0
C'est la raison pour laquelle elles paraissent tellement "abstraites" et devront trouver des retranscriptions à des domaines plus précis, c'est pourquoi je pense qu'il sera nécessaire de disposer de méthode d'application.
Par exemple il sera important de disposer d'une méthode pour rendre des animations flash accessibles, conformes WCAG 2.0, quitte à restreindre le cadre de référence par exemple à IE+jaws 8, l'alternative étant par ailleurs assuré dans les autres cas.
Pour le moment dans une page web, une animation flash "opérable" utilisable avec Jaws 8 se retrouve dans un cas très particulier :
- Vous ne disposez pas de Jaws 8, vous ne pouvez pas utiliser pleinement le contenu flash mais vous pouvez le lire, et comme vous pouvez le lire, vous ne pouvez pas utiliser l'alternative.
C'est ce genre de paradoxe que se propose de résoudre WCAG 2.0 et pour lequel WCAG 1.0 ne peut rien proposer.
Ca c'est la théorie, la réalité de terrain sera ce que nous en ferons...
Jean-pierre
Un article intérssant, parce qu'il donne du jargon compréhensible (ce qui n'est pas souvent le cas du WCAG 2.0)
http://www.redaction.be/electure/facilite.htm
La lisibilité d'un texte peut être prise dans deux acceptions différentes. En anglais, comme le rapportent Morin, Sallio et Kretz (1982), on utilise :
"legible", pour désigner la lisibilité matérielle d'un texte (typographie, espacement, contraste,...) ;
"readable", pour désigner la dimension intellectuelle et psychologique liée au processus de compréhension du texte lu (vocabulaire, logique, contexte,...). Dans ce cas, on évaluera la clarté d'un texte du point de vue de l'utilisateur/lecteur plutôt que du point de vue du producteur/rédacteur.
Autrement dit, un texte (ou, de manière plus générale, un contenu) devrait être facile à lire, mais aussi facile à comprendre, de même que facile à explorer (Zibell, 2000).
Bonjour david,
Oui, un article intéressant, de même que la problématique plus générale de la spécificité de l'écriture pour le média web.
La question du jargon qui concentre déjà une grande partie des critiques sur WCAG 2.0 est intéressante.
Par exemple une expression comme "Web unit" (unité web) qui remplace le mot "page" tellement "simple, facile à lire, facile à comprendre".
Oui mais en 2006 et à fortiori dans le futur, il est incontestable que la notion de "page" est inadaptée aux réalités techniques du web.
Il fallait bien trouver autre chose qui puisse décrire tout à la fois la page web statique de mon site sur les poissons rouges et l'interface de restitution d'une application Ajax.
Et comme le dit très justement Michael Landis sur les commentaires de A List Apart : "This is amusing, but not exactly a danger to the web community or to those using assistive technologies." : "C'est amusant mais pas exactement un danger pour la communauté du web ou ceux qui utilisent des aides techniques".
On a un autre très bel exemple de jargon c'est "user agent", comme le faisait remarquer Monique dans nos commentaires.
Qui emploie "user agent" pour parler d'une de ses représentations, personne, on parle de robot d'indexation ou de navigateur web, c'est "plus facile, plus simple, plus compréhensible".
Et quelque fois, quand on en à besoin, on emplois le jargon, c'est plus simple, plus facile à lire et à comprendre que d'écrire "les robots d'indexation et les navigateur web et les lecteurs d'écrans et les navigateurs vocaux et les imprimantes ..."
Qui emploiera "web unit" pour parler de quelque chose de particulier ? personne, on dira "la page web", "l'interface de consultation", "l'animation flash"...
Et quelque fois on dira... Allez je vous fait grâce de répéter la démonstration.
Pour un document comme WCAG 2, eu égard à ses objectifs, le recours à du jargon est une fatalité, ce serait l'inverse qui serait source de confusion : une "page flash" c'est quoi ??
"Web unit" n'est pas plus incompréhensible, compliqué ou illisible que "user agent" c'est une simple question d'appropriation à l'issue de laquelle ce jargon ne posera plus aucun problème, il sera "simple, facile à lire et à comprendre".
Jean-pierre
Ps : Message perso à David : Je m'occupe dés demain de répondre à ton email... :)
Bonjour à tous,
Tout d'abord permettez-moi de remercier les initiateurs de cet intéressant débat. J'interviens ici en temps que membre de l'équipe BlindSurfer dont nous venons de réviser les directives afin de coller à la réalité sans attendre la sortie des WCAG 2.0. Voici pour l'intro...
Comme le dit très bien Monique, le simple fait de la qualité normative des WCAG les berce automatiquement dans un flou jargonique. Ce pour tenter d'aborder le problème de manière holistique. Pour leur défense, j'ajouterais simplement que les compromis démagogiques avec autant de variables à prendre en considération ne sont vraiment pas aisés à rédiger. Les règles doivent être comprises autant par un responsable de site peut-être néophyte en technologie que par un développeur web averti.
Si nous regardons la chose du côté pratique : le but ultime étant d'améliorer l'accès d'un maximum de site au plus grand nombre de personnes, il faut des compromis. Je veux dire en cela que le webmaster qui veut rendre son site accessible ne le fera pas s'il se voit obliger de refuser les propositions alléchantes de webdesigner en java, et autres technologies forts pratiques, l'html pure en pratique malheureusement est très difficile à « vendre ». Alors faut-il faire bloc, et refuser les intentions louables des personnes demanderesse d'améliorer l'accessibilité de leur site. Non, donc les directives doivent s'adapter aux technologies existantes, il n'y a pas photo.
Le danger est évidemment de tomber dans l'excès. Certes...
De notre côté, nous n'avons pas la solution et travaillons dès lors toujours au cas par cas. Les directives comme normes, chemin à suivre ou ligne de conduite, puis selon, les difficultés présentes par site, nous sommes obligés d'offrir solution en fonction des situations. Sorte de jurisprudence. C'est dangereux, nous en sommes conscients, cela prend du temps, nous en sommes conscients, mais voilà des solutions toutes faites, il n'y en a pas.
Ni Rome, ni la Constitution ne s'est faite en 1 jours, tout comme les WCAG... Doivent-elles se préciser par ajouts d'articles qui développeraient tous les cas possibles et la solution pour chacun d'eux, au risque de devenir indigestes et illisibles ?
Doivent-elles diversifier leurs présentations et pousser la rédaction de documents en fonction du lecteur afin d'évincer les termes flous ou vague tel un cours de droit pour les étudiants en mathématique qui ne sera pas aborder de la même manière que s'il était destiné à des étudiants de 3ème licence en droit
Une solution idéale et idéelle serait peut-être de garder les WCAG 2.0 en guise de charte et compléter celle-ci par des multitudes d'articles récoltés par la pratique. Et nous aurions alors des références telles que "&2 alinéas 5 de l'article 345 chapitre V", certes... Travail titanesque, base de données énormes et risques en conséquence mais précision et diminution d'interrogation. Voilà pour l'illusion...
Avec le pieds sur terre, je pense que nous ne devons pas attendre des WCAG qu'elles puissent apporter solution à toutes les difficultés, elles existent au moins pour une chose très importante : conscientiser les personnes responsables de site internet. En rappelant de manière officielle à tout un chacun qu'il existe de multitudes de façon de parcourir l'information sur le net, qu'il existe des normes d'accessibilité (qui prennent en considération tellement de variables que les débats sont loin d'être finis ;-). C'est déjà cela. Et des débats tel que celui que vous proposez ici les ferons avancer.
Bien à vous
Jean-Pierre > je ne vois pas de quel message tu parles, désolé
Sinon, je suis tout à fait d'accord avec toi. Sophie, ta référence au holisme est pertinente
Un document de référence n'est pas un manuel d'utilisateur. Il n'est pas fait pour être intelligible (legible), mais pour une référence. C'est la couche 1. La couche 2, c'est le manuel d'utilisateur et les raccourcis (comme l'exemple pertinent de Monique sur navigateur / agent utilisateur le rappelle très bien).
J'ai publié un article sur WCAG 2.0. Comme tous les gens intéressés par la question ne lisent pas forcément Openweb, je me permet un cross-post.
http://blog.empyree.org/?2609-wcag-2-0-une-copie-a-revoir
Pour résumer, les trois point abordés:
- 450 pages, est-ce vraiment nécessaire (vraie question) ?
- politique : abstraction pour permettre la compatibilité descendante. Intention louable, mais nécessité d'un « intermédiaire ». Parallèles : Debian/distro-filles et Creative Commons Lawyer-readable et human-readable
- le retour d'une conciliance de mauvais augure (validité du code facultative). « Ce n'est pas parce qu'ils sont nombreux à avoir tord qu'ils ont raison »
Bonjour,
"450 pages, est-ce vraiment nécessaire (vraie question) ?"
Ce qui est amusant avec cette critique, c'est qu'on reproche à WCAG 2.0 d'être trop imprécis et aux documents annexes, qui sont chargés d'expliquer et de préciser d'être trop longs.
"Intention louable, mais nécessité d'un intermédiaire".
C'est évident mais nous en avons eu besoin aussi pour WCAG 1.0 : les milliers de tutoriaux, livres, guides en tout genre, de ce point de vue où est la différence.
On en aura d'autant plus besoin pour WCAG 2.0 que sont présentées des notions nouvelles, comme "parsé de manière univoque" que tu reprends dans ton billet :
"Parsé de manière univoque" ne veut rien dire tant qu'on ne donne pas sa définition :
"Analysé au travers d'une structure de donnée unique"
et la précision :
"L'analyse transforme le balisage ou un autre code en une structure de donnée, généralement un arbre, qui est approprié pour un traitement ultérieur et qui en restitue la hiérarchie."
Pour HTML c'est quelque chose qu'on connait bien, ça s'appelle le DOM.
"Parsé de manière univoque" pour HTML cela veut dire qu'on doit s'assurer que le DOM soit restitué de manière identique.
Maintenant le problème c'est : comment le garantir ?
Il y à plusieurs manière :
- Contrôler le DOM restitué sur une gamme de navigateur au moyen d'outils, c'est long et compliqué.
- Contrôler à la main que toute les balises sont correctement écrites et imbriquées et que les attributs du type ID sont bien uniques, c'est stupide.
- Valider le code, c'est simple, facile, rapide, rationnel, simple à comprendre, facile à expliquer.
Cela semble-t-il aussi "incompréhensible" qu'on veut bien le dire ???
Par ailleurs, les explications que je viens de donner ne sont pas de mon fait, elles sont directement issues des deux documents d'accompagnements de WCAG 2.0
"Parsé de manière univoque" est incompréhensible ou c'est plutôt qu'on ne peut pas le comprendre sans lire les documents d'accompagnements ??
Jean-pierre
Ps : @ David : Le mail concernant la demande d'inscription sur webonorme... :)
Je viens de te répondre
Bonjour Jean-Pierre,
Pour les tutoriaux, c’est exactement ce que je dis dans l'article : que ce soit pour CSS, HTML ou n’importe quoi d’autres, un utilise toujours des tutoriaux. C'est pour ça que je conclus cette partie en disant que ça ne me gêne.
Je comprend mieux parsé de manière univoque avec ton explication. En fait, c'est *la version abstraite de « DOM »*. Donc, si je comprends bien, ça ne remets pas en cause la nécessité d'un code valide, c'est presque orthogonal à cette exigence, mmh?
Pourtant, Joe Clark signale ensuite que le code valide reste facultatif (niveau 2, je crois). Donc, je m'emmêle un peu.
Merci pour webonorme, on continue sur ce sujet précis pas courrier.
"En fait, c'est *la version abstraite de « DOM »...
Pourtant, Joe Clark signale ensuite que le code valide reste facultatif (niveau 2, je crois). Donc, je m'emmêle un peu."
Pour les langages a balises comme XML / HTML c'est le DOM qui décrit la structure de donnée et les relations entre les éléments.
Donc si l'on veut garantir qu'un document qui utilise le DOM puisse être analysé de manière univoque par un agent utilisateur, la solution de valider le code est plus "qu'orthogonale" : tout autre solution est stupide.
On va chercher à valider deux choses, d'abord que le balisage est bien formé et d'autre part que les éléments identifiants sont correctement employés, pour ID par exemple il faudra vérifier que chaque valeur est unique.
C'est tout ce que nous demande ce critère.
Dans une perspective de développement web "responsable", pour reprendre l'expression de Joe Clark, le chemin est tout tracé : DTD et validation, point barre, critère suivant.
Mais il serait également tout à fait plausible de valider un document HTML sans DTD si tant est que les deux conditions ci-dessus soit respectées.
C'est à ce moment que les choses se complique et que certains, dont Joe, y voit un "retour en arrière" et l'abandon d'une exigence jugée capitale.
Car il sera tout à fait possible de valider, pour ce critère, un copier-coller de texte issus de Word dans un document HTML sans DTD mais "conforme" au critère 4.1.1 et bourré de caractères non SGML et donc susceptibles de poser problème à la restitution.
Cette critique est juste, ce critère peut être détourné et il le sera certainement.
Mais nous avons quantité d'autre critères, notamment dans WCAG 1.0 qui fonctionne de la même manière.
Le premier d'entre eux est dans ce cas et si vous voulez valider les alternatives textuelles des images "ayant du sens" sans vous emmerder, décrivez les toutes : c'est valide !
C'est con, stupide, ça rends la page totalement imbitable à l'écoute mais c'est valide.
Pour le critère de succès 4.1.1 c'est la même chose : un document qui valide ce critère mais dont le jeux de caractère n'est pas conforme c'est tout aussi con et stupide que les sempiternels "Logo de la société" ou pire les "images 112_2" de certains CMS.
Alors pourquoi ne pas exiger la validité du code ?
La question est mal posée, la bonne question c'est pourquoi WCAG 2 ne peut pas exiger la validation du code HTML, c'est bien de ça qu'il s'agit.
Ce n'est pas, comme on voudrait bien le faire croire, une volonté de WAI de faciliter la vie des certains gros poissons, c'est simplement la conséquence d'une des bases fondamentales de WCAG 2.0 : la neutralité vis a vis des technologies.
Tout ce que je viens de vous raconter concerne un territoire connu : notre bon vieux HTML.
Mais maintenant, si ce critère doit êre appliqué à un format binaire comme flash, je valide quoi, avec quelle référence, quel est le sens de "valider le code pour la grammaire formelle publiée" dans ce contexte.
En revanche, un agent utilisateur qui va analyser le contenu d'une animation flash, va récupérer une structure de donnée, je devrais m'assurer que cette structure de donnée est univoque.
De ce point de vue on est en territoire inconnu et WCAG 2 ne nous aide en rien, je n'ai aucun commencement de début d'idée de comment réaliser ce test.
Je sais comment rendre un tant soit peu accessible une animation Flash, mais tester la restitution de la structure de donnée...
Peut-être même qu'il est inutile de le faire... Je ne sais pas.
Ce que je sais en revanche, c'est que WCAG 2 va me permettre de cadrer, d'uniformiser, de définir une méthode de travail, de test et de validation pour l'accessibilité des animations flash.
Et j'ai beau retourner le problème dans tous les sens, je ressens ça comme un immense progrès.
On arrêtera enfin de bricoler chacun dans son coin des animations flash accessibles sur la base de ce qu'on croit comprendre des tutoriaux de macromédia ou des travaux de webaim.
On pourrait, peut-être, avoir pour cette technologie une véritable méthode d'application, un corpus technique solide et identique pour tout le monde, fondé sur WCAG 2.
Il reste à le faire, il faut le faire.
C'est en tout cas c'est comme ça que je comprends l'ambition de WCAG 2.
Certes on va perdre ce levier important de la validité du code HTML qui tirait le développement web vers le haut.
Mais on va gagner de pouvoir intégrer dans des démarches d'accessibilités formelles des technos qui en sont, pour le moment, exclues.
Pour la validité du code HTML, faudra trouver d'autres moyens, d'autres levier, la qualité par exemple en est un particulièrement intéressant.
Mais je peux comprendre que certains s'en alarme, c'est un peut le dilemne du verre à moitié vide ou à moitié plein.
Je suis d'un naturel particulièrement optimiste et je sais bien que ma naiveté me joue souvent des tours, mais bon, ça fait 4 ans que j'arrive à convaincre mes clients de faire du code valide, je ne vois pas de raison que ça change...
Comment ça je n'ai pas beaucoup de clients ??? :) :)
Jean-pierre
Comme beaucoup de monde, je pense qu'il va falloir impérativement mettre en place des guides de "bonne pratique" pour les différents éléments abordés dans les WCAG 2. Ce qui me chagrine, c'est le temps que cela va prendre. 5 ans pour pondre ce document, 2 ou 3 ans minimum (si l'Europe ne s'en mêle pas) pour se mettre d'accord sur les bonnes pratiques et qu'est-ce qu'on fait des différences de législation d'un pays à l'autre ?
De toute les critiques qu'on peut faire sur WCAG 2.0 celle sur la législation est la plus juste et la plus problématique.
A la différence de WCAG 1.0 où le choix se limitait au respect d'un des niveaux de priorité, ce qui permettait une harmonisation relativement facile, la situation est plus complexe avec WCAG 2.0.
On pourrait tout a fait imaginer avoir à gérer des choix très différents d'une législation à l'autre, voire antagonistes.
Deux remarques cependant : La situation actuelle n'est pas très différente, un site US sous le section 508 aura beaucoup d'effort à faire pour respecter les législations nationales européennes.
De même le référentiel SDAE introduit des thèmes liés à l'utilisabilité qui n'ont pas d'équivalent WCAG.
Si l'on se place dans la perspective de WCAG 2.0, la référence de base correspondant aux législation actuelles est Html,Xhtml,Xml.
Il ne devrait pas y avoir de difficultés notables pour transposer les législations actuelles sous le couvert de WCAG 2, la question se résumantt à choisir un niveau d'accessibilité.
On pourrait, par exemple, dire qu"un référentiel comme ceui de du SDAE exigerait un niveau "double A" pour la référence de base : Html,Xhtml,Xml,CSS,gif,jpeg,png et obtenir ainsi une équivalence à WCAG 1.0 double-A.
Ce qui laisserais le temps d'évaluer comment les autres technologies peuvent et doivent s'intégrer dans WCAG 2.0
Les commentaires sont fermés pour cette ressource