Marre des WCAG 2.0 (A list Apart / Joe Clark)

Sommaire

Traduction de l'article

Note : Cet article a été publié sur le site A List Apart (en) sous le titre To Hell with WCGA 2 (en) le 23 mai 2006.

Note du 07 juin :Stéphane Deschamps ( nota-bene, pompage entre autres choses) viens de nous signaler un "très lourd contre-sens" sur la traduction du titre de l'article. To hell with WCAG 2 devant se traduire par Marre des WCAG 2 et non pas En enfer avec WCAG 2.0 comme je l'avais naivement compris. Mille mercis, c'est corrigé

Cet article a été traduit par Jean-Pierre Villain et relu par Monique Brunel et Aurélien Levy.

Marre des WCAG 2.0 par Joe Clark

En illustation : un cheval dessiné trotte à reculons

Les directives pour l'accessibilité aux contenus Web 1.0 (WCAG ), publiées en 1999 sont devenues très rapidement inadaptées. Le nouveau WCAG 2.0 est le difficile résultat de 5 longues années de travail par le comité WAI (Web Accessibility Initiative). Avec l'ambition de convenir à tous les contenus web, les bases fondamentales de WCAG 2.0 sont devenues très vite impossibles à comprendre pour un « standardiste ». WCAG 2 revient sur les bases d'un développement web responsable, bien acceptées par les " standardistes ".

WCAG 2. n'est pas un progrès, ça ne valait pas le coup d'attendre.

Préparez-vous à être déçu.

Si vous êtes un développeur spécialisé dans la standardisation du web, vous avez déjà de l'expérience et vous êtes habitué aux seules références en la matière, les directives pour l'accessibilité aux contenus Web. WCAG 1 vient juste de célébrer son septième anniversaire et s'apprête à disparaître. La révision de WCAG 1 était vraiment nécessaire.

Le 27 avril, WAI publiait la première étape de la longue séquence des documents requis pour que WCAG 2.0 devienne un standard.

Si vous vous attendiez à des progrès spectaculaires, vous risquez d'être déçu. Beaucoup de choses ont été mises au placard et beaucoup de priorités de base sont maintenant confirmées. Le problème,ici, c'est que les " standardistes " savaient déjà comment couvrir les besoins définis par ces priorités de base . La où WCAG se goure, c'est pour les choses importantes. Curieusement toutefois, et peut-être due à une réécriture méticuleuse au fil des ans, les choses importantes sont bien camouflées et, pour un lecteur peu informé, WCAG 2 semble raisonnable. Ce n'est pas le cas; et si vous êtes un développeur impliqué dans la standardisation vous allez constater qu'il est presque impossible d'implémenter WCAG 2.

Où trouver les documents ?

Dans la grande tradition du W3C, les documents actuels WCAG 2 sont confus et difficiles à trouver. (Je vous donne également le nombre de pages, au format PDF US Letter sur Safari, et le nombre de mots sans le balisage).

J'ai imprimé et lu intégralement les trois documents pour cet article.

Quand on les compare aux dimensions standards d'une page de livre, les trois documents WCAG 2, font 450 pages, ce qui est plus important que chacun des livres publiés au sujet de WCAG 1, y compris le mien. De plus, comme le signale de nombreux articles de blogs (Snook (en), Clagnut (en), Sitepoint (en), Kurafire (en)), Shaw Lawton Henry (en) du groupe de travail Formation et Sensibilisation de la WAI a mis en garde l'auditoire qui assistait à sa présentation à la " South by Southwest 2006 " de ne lire que le document "Comprendre WCAG 2", pas la spécification elle-même. Comme "comprendre WCAG 2.0" fait plus du double de ce qu'il est supposé expliquer, c'est bien le signe d'un problème avec WCAG 2.

Il y a, par ailleurs, un document séparé, couvrant les techniques HTML (en), qui n'est plus mis à jour depuis novembre 2005. Il n'est pas inclus dans cet article. Enfin, les "directives" pour WCAG 1 sont appelées maintenant "critères de succès" pour WCAG 2, un changement de nomenclature que j'ai ignoré.

Dans la discussion ci-dessous, les liens vers et à l'intérieur de ces documents ont été difficiles à établir avec précision; j'ai donné leur numéro d'identification, mais cela reste insuffisant. Il n'y avait souvent pas d'attribut title apparent.

Vous n'avez pas beaucoup de temps pour commenter.

Après avoir travaillé 5 ans sur WCAG 2, WAI a donné aux industriels et à toutes les parties intéressées, y compris les personnes handicapées, pas plus de 34 jours pour commenter WCAG 2 (jusqu'au 31 Mai 2006). [Ndt : le délais a été prolongé jusqu'au 22 Juin 2006] A ce propos, le groupe de travail vous demande de remplir un formulaire, avec Excel par exemple, pour chaque référence avec laquelle vous n'êtes pas d'accord.

Je vous conseille simplement d'envoyer un mail à public-comments-wcag20@w3.org et de lire les archives de cette mailing list (où il est, avec la méthode du formulaire WAI, impossible de dire exactement qui a soumis tel commentaire). Il y a une longue liste de commentaires reçus par le formulaire WAI. Je suggère également à tout le monde d'envoyer une pétition pour obtenir quelques mois supplémentaires pour commenter, confer le processus du W3C (à savoir : les périodes de commentaires peuvent durer plus longtemps si le rapport technique est compliqué ou à des implications extérieures significatives).

Les remugles du processus (Ndt : du WAI)

Maintenant un mot sur le processus, ce qui vous permettra de comprendre le résultat. Le Groupe de Travail des Directives pour l'accessibilité aux contenus Web est le pire des comités, groupes, compagnies ou organisation avec lequel j'ai jamais travaillé. Plusieurs de mes amis et moi-même avons été diversement ignorés, rejetés par le groupe ou mis sur la touche et activement harcelés. Le processus favorise les multinationales qui ont un gros budget et peuvent se payer deux heures de téléphone par semaine et des avions pour les capitales où sont organisées les rencontres.

Le processus de développement pour WCAG est inaccessible à quelqu'un qui ne parle pas anglais. Plus important, il est inaccessible à une personne handicapée, notamment les personnes qui ont des difficultés d'apprentissage (qui doivent patauger pour écrire des documents et des emails, ce qui a déjà fait l'objet d'une plainte) et les mal-entendants (qui doivent écouter les conférences ). Evidemment, quelqu'un présentant des déficiences d'apprentissage ou de compréhension ne contribue pas au processus, parce que, en pratique, il ne le peut pas.

Ce que le WAI est supposé faire est d'améliorer le Web pour les personnes handicapées. Quelque chose ne va pas si plusieurs participants travaillent dans un climat de tension (Ndt: traduction littérale : frayeur) comme on me l'a rapporté. Je n'ai jamais entendu de pareilles plaintes au sujet d'un autre groupe. Le groupe de travail WCAG est une duperie dans le W3C, et il est urgentque le président Tim Berners-Lee le ramène à l'ordre.

Le processus est dévoyé, ce n'est donc pas une surprise que le résultat le soit aussi.

Moins qu'une farce, mais un échec patent.

Si vous avez déjà consacré deux heures de votre vie pour lire la précédente ébauche de WCAG2, vous avez probablement été déconcerté et/ou fâché. Le groupe de travail a effectivement amélioré des recommandations mineures et a excellé pour donner au document entier un côté éminemment raisonnable. Ils ont réussi à enfouir profondément l'essentiel des directives dans le document. Ils ont réalisé un joli travail pour donner à WCAG 2 l'aspect d'un document opérationnel. Mais il ne l'est pas.

J'ai lu les pratiques requises et suggérées, à partir des trois documents; laissez-moi vous expliquer ce que WCAG dit réellement :

  1. Il y aura un conflit pour déterminer ce que représente exactement une page, et encore plus un site.
  2. Un futur site, conforme WCAG 2 n'aura pas du tout besoin d'être valide pour HTML, jamais, (nous y reviendrons plus klin). Vous devrez néanmoins contrôler les sortie DOM de votre (en) site dans de multiples navigateurs et prouver qu'elle sont identiques.
  3. Vous pourrez continuer à utiliser des tables de mise en page. (Et pas juste une table, tables for layout (en), plural (en).)
  4. Votre page, ou une de ses parties, pourra clignoter jusqu'à trois secondes (en). Mais, évidemment, Une partie (en) ne pourra pas flasher.
  5. Vous pourrez définir une technologie en tant que référence de base (en), ce qui veut dire que quelqu'un sans cette technologie a peu de recours, le cas échéant, pour se plaindre de l'inacessibilité de votre site.
  6. Vous pourrez définir un répertoire entier de votre site comme n'étant pas concerné par l'accessibilité (y compris, dans l'exemple même de WCAG 2, toutes vos vidéos indépendantes (en).
  7. Si vous voulez faire une déclaration de conformité WCAG 2, vous devez publier une checklist (en) de déclaration plus proche d'une confession forcée que n'importe laquelle des politiques d'accessibilité typiquement employées aujourdhui.
  8. Bien que personne ne se soit donné la peine de les rendres accessibles, si vous mettez des vidéos en ligne, vous n'aurez plus à fournir des descritpion sonores pour les aveugles pour le premier niveau de conformité (en). Par ailleurs, seules les vidéos préenregistrées exigeront des sous-titres à ce niveau.
  9. Vos podcasts devront être remixés pour que le dialogue soit 20 décibels plus élevés (en) que le bruit de fond. (Vous n'avez plus à les sous-titrer ou les transcrire, car ils ne sont plus considérés comme des éléments multimédia (en) En revanche, les diaporamas, eux, sont maintenant considérés comme de la vidéo (en), ce qui réserve des surprises aux utilisateurs de Flickr.)
  10. Vous pouvez mettre plusieurs centaines de liens de navigations sur une seule page et ne rien faire de plus, mais, si vous avez deux pages liées (en) qui ont trois liens de navigation chacune, vous devez fournir un moyen de sauter la navigation.
  11. Vous ne pouvez pas utiliser un positionnement hors-écran pour ajouter des labels (e.g à un formulaire) de telle sorte que seuls certains utilisateurs, comme les utilisateurs d'aides techniques, puissent les percevoir. Tout le monde (en) devra les voir.
  12. Les mises en pages CSS, particulièrement celles qui utilisent un positionnement absolu pour retirer des éléments du flux, sont simplement interdites (en) au niveau le plus haut. En fait, l'ordre de la source devra être comparé à l'ordre de la présentation au niveau le plus bas.
  13. Par ailleurs, au niveau le plus haut, vous avez à fournir une explication et le moyen d'y accéder (en) pour tout les points suivants :
    1. Les définitions des idiomes et du jargon
    2. La forme étendue des acronymes
    3. La prononciation de certains mots.
  14. Vous avez aussi à fournir un document alternatif si un lecteur avec un niveau d'éducation secondaire ne peut pas comprendre votre document original. (En fait, WCAG2 propose (en) à plusieurs reprises de maintenir séparées des pages accessibles et inacessibles. Dans certains cas vous n'avez pas nécessairement à améliorer vos pages inacessibles tant que vous proposez une page alternative.)

Ces trois documents sont des ébauches, et, bien sûr, tout ce qui est au-dessus peut changer; mais cela ne changera pas. Le dernier appel d'une ébauche de travail est vu comme substantiellement complet (en). C'est le signal que le Groupe de Travail considère qu'il satisfait tous les pré-requis techniques ET qu'il satisfait de manière significative ses implications avec les autres groupes. Le groupe de travail WCAG ne bougera pas de manière significative à cette étape.

Ce sont les définitions qui ont ruiné ce travail.

Bien que WCAG 2 réclame de toute manière des choses irréalistes et infondées, ce n'est pas ça qui ruinent les directives. Quelque chose d'aussi banale que les définitions va s'occuper de ça..

WCAG 1 est spécifique à HTML. Chacun reconnaît que c'est un problème à une époque où des formats que les non-voyants adore haïr, comme PDF et Flash, commencent à devenir petit à petit accessibles. Donc WCAG 2 doit être neutre vis à vis de la technologie.

Mais, ce faisant, un univers parallèle, dans lequel une vaste majorité de contenu web cessait d'être de simples ensembles HTML, CSS et Javascript, a été imaginé. Un monde dans lequel existerait énormément de Flash, PDF et autres formats pas encore inventés, qui seraient disponibles et conçus pour être accessibles. Pour correspondre à ce monde imaginaire (Ndt : dreamworld) WCAG 2 a été écrit, réécrit, re-réécrit pour s'appliquer à n'importe quoi. En chemin, il a perdu sa capacité à s'appliquer aux choses réelles, au travail quotidien du développement d'un simple ensemble HTML, CSS, et Javascript.

Question : que signifient réellement les termes suivants, reproduits ici avec leurs définitions officielles selon WCAG 2.0 ?

Unité de conception (Ndt : authored Unit, voir la note à ce sujet en fin de document).
Collection de matériel créé comme un ensemble unique par un auteur.
Composant de conception (Ndt : authored component).
Une unité de conception utilisée comme partie d'une autre unité de conception
Unité web (Ndt : Web Unit).
Une collection d'informations, constituées d'une ou plusieurs ressources dans l'intention d'être restituées ensemble et identifiées comme une unique URI (Uniform ressource identifier) à l'image des Url.
Parsé (analysé) de manière univoque (Ndt : parsed unambiguously).
Parsé au travers d'une structure de donnée unique.
Déterminé programmatiquement (Ndt : programmatically determined).
Déterminé par un logiciel à partir de données fournies à un agent-utilisateur qui les supportent de telle sorte que l'agent-utilisateur peut extraire et présenter cette information selon différentes modalités.

Pouvez-vous traduire chacun de ces termes dans des mots compréhensibles comme page, site, valide, bien-formé ou modèle ? Moi, je ne peux pas. Parmi toutes ces définitions, où sont les modèles que nous utilisons pour créer des sites composés de pages valides et bien formées ?

Si vous êtes un standardiste et que vous travailliez sur des sites accessibles, êtes-vous aujourdhui, sans le savoir, un auteur publiant une unité de conception utilisant des composants de conception au travers d'une unité web déterminée programmatiquement et qui peut-être parsé de manière univoque ?

Jetez un oeil à WCAG 2 et vous vous ferez votre propre liste de passages inappropriés et incompréhensibles. En fait, trop de choses de WCAG 2 sont très difficiles à comprendre, et également impossibles à appliquer dans le monde réel des sites web; WCAG 2, à cet égard, n'est pas meilleur que son prédecesseur, les deux documents échouent à produire des directives claires et simplement écrites.

Si vous ne pouvez pas comprendre les bases d'une directive et si WCAG 2, en général, est tellement éloigné du web réel qu'il ne peut même pas utiliser des mots que les développeurs comprennent, êtes-vous réellement en mesure d'implémenter WCAG 2 sur votre site ? Rappelez-vous que vous ne pouvez pas vous appuyer sur les documents techniques et les documents pédagogiques pour obtenir de l'information supplémentaire officielle. WCAG 2 est le seul document "normatif". Vous passez ou échouez uniquement en fonction de celui-ci.

Et si vous avez de la difficulté à comprendre WCAG, cela ne sous-entend-t-il pas que quelqu'un puisse venir avec une interprétation différente et vous accuser de violer les WCAG et de produire un site inaccessible ? Parce que c'est illégal dans certaines parties du monde, un certain degré de clarté est essentiel, mais la clarté est absente de WCAG 2.

Testabilité

Si vous étudiez attentivement WCAG 2, vous remarquerez que quelque chose d'aussi trompeusement simple que la directive WCAG (Ndt : WCAG 1) écrire clairement et simplement (en) n'est plus là. Et qu'il n'y a rien d'autre pour remplacer ou améliorer cette directive. En fait, il n'y a rien du tout dans le texte qui satisfasse le principe 3 de WCAG 2 Le contenu et les commandes doivent être compréhensibles.

Vous devez, cependant, accorder une attention fanatique à expliciter les expressions étrangères, les idiomes, et équivalents, et si votre contenu nécessite, pour être compris, une capacité de lecture supérieure à un niveau d'éducation secondaire de premier cycle, (Ndt : équivalent au collège) vous devez fournir un contenu supplémentaire qui n'exige pas ce niveau de lecture. Si vous avez des difficultés d'apprentissage, c'est à peu près tout ce que WCAG 2 est prêt à faire pour vous.

Selon mon analyse et les présentations de Gian Sampson-Wild, il semble que les dyslexiques et autres déficients cognitifs ont été sacrifiés sur l'autel des procédure des test.

WCAG 2 nous dit : (en)

Tous les critères de succès sont testables. Alors que certains d'entre eux le sont automatiquement, d'autres doivent l'être par des personnes qualifiées. Quelquefois, une combinaison de logiciels et de vérificateurs (contrôleurs) humains qualifiés peut être utilisée. Lorsque plusieurs personnes qui comprennent WCAG 2, testent le même contenu pour le même critère de succès, le même résultat devrait être obtenu avec le maximum de cohérence (Ndt : inter-fiability).

Le maximum de cohérence n'est pas défini. Cela veut-il dire 8 personnes sur dix, six ? Les dix ?

Il semble que chacun ait supposé qu'il serait facile de trouver des "gens qui comprennent WCAG 2" tout en étant en désaccord sur le fait que certaines parties d'un contenu soient clairement et simplement écrits. Je suppose qu'il a été considéré comme évident que des tests de contenus parviendraient rarement à un maximum de cohérence, dés lors qu'il sont basés sur l'opinion humaine, par nature imparfaite. Le groupe de travail était, et est toujours, exagérement focalisé sur les test automatiques; la présence dans le groupe de travail des éditeurs de solutions de tests automatiques et de leurs algorythmes y est sans doute pour quelque chose. Le groupe était viscéralement convaincu, par exemple, qu'un texte alternatif ne peut pas être testé automatiquement, mais peu disposé à accepter le même raisonnement pour un contenu de manière générale.

Il est dur mais juste de dire que WCAG 2 a sacrifié les personnes ayant des difficultés d'apprentissage, de telle sorte qu'un outil comme bobby, un concurent ou son successeur, puissent tester un nombre de critères plus important avec un meilleur taux de succès.

L'illusion des niveaux multiples

WCAG 1 avait trois niveaux de conformité ce qui nous donnait, dans le style typique de WAI un total de six noms : Priorité 1 / Niveau A, Priorité 2 / Nivea AA (écrit "Double-A" pour contrevenir au défaut de prononciation des lecteurs d'écrans) et Priorité 3/Niveau AAA ("triple-A").

Les standardistes avaient finalement établi que les priorités 1 et 2 représentaient ce dont vous aviez vraiment besoin pour rendre un site accessible, les priorités 3 étant strictement optionnelles (et également onéreuses (en) et en principe impossibles à réunir).
Quelques gouvernements, comme le Canada (en), exige le niveau de priorité 2 pour leur propres sites même si l'objectif n'est pas nécessairement atteint..

Quand des experts effectuent une évaluation de l'accessibilité d'un site pour WCAG 1, ils considèrent le plus souvent les priorités 1 et 2. Peu de sites passent l'évaluation de niveau 3. La Disability Rights Commission (en) (Ndt : Commission des Droits des Handicapés anglaise) et Nomensa (en) n'ont pas trouvé de sites conformes pour les trois niveaux dans ceux qu'ils ont testés

Pour un observateur rationnel, ça montre que le niveaux 1 et 2 pour WCAG 1 sont réellement un ensemble de régles et que le niveau 3 n'est pas pertinent et impossible à satisfaire.

Faire comprendre cette idée aux membres du Groupe de Travail (ou plutôt à l'un des co-présidents) était impossible, donc, pour WCAG 2, nous avons toujours à faire avec les trois niveaux. Mais retenez ceci : ils sont tous considérés comme importants. (en)

Critères de réussite de niveau 1 :

  1. Atteindre un niveau d'accessibilité minimum
  2. Peuvent raisonnablement s'appliquer à toutes les ressources Web.

Critères de réussite de niveau 2 :

  1. Améliorez le niveau d'Accessibilité
  2. Peuvent raisonnablement s'appliquer à toutes les ressources Web.

Critères de réussite de niveau 3 :

  1. Atteindre un niveau supérieur d'accessibilité pour les personnes handicapées
  2. Ne s'applique pas à toutes les ressources Web

Traduction : Pauvres idiots que nous sommes, nous n'avons juste pas compris que les trois niveaux de priorité WCAG 1 sont de vrais niveaux de priorité. WCAG 2 considère toutes les directives "essentielles pour quelqu'un" bien qu'elles soient toujours organisées en trois niveaux.

Mais, en fait, si vous étudiez attentivement les documents WCAG 2 :

  1. Même si vous êtes conforme avec les trois niveaux WCAG 2, vous pouvez vous retrouver avec un site inaccessible.(en)
  2. Vous n'avez jamais à satisfaire plus de la moitié du niveau (en) de priorité 3.
  3. Le document WCAG 2 lui-même reconnaît ouvertement (en) que il n'est pas recommandé que la conformité triple A soit exigée pour des sites entiers.
  4. En contradiction avec elle-même, la directive 4.2.4 (en) de niveau 3 ne demande pas que vous satisfassiez globalement ce même niveau 3.

Avec quel niveau voulez-vous être conforme ? Veuillez faire votre choix maintenant.

Nouvelle absurdité : le Groupe de Travail n'a même pas pu contraindre ses directives à s'appliquer à tous les niveaux. Quelques directives sont même absentes du niveau 1, le niveau le plus bas. J'ai fait le compte

C'est comme si les standards du web n'avaient jamais existé

Des gens comme vous et moi avons labouré le terrain depuis 1998 pour améliorer les standards du web, leur support par les navigateurs, leur compréhension par les auteurs, les bases pédagogiques pour les expliquer.

Pendant ce temps, le Groupe de Travail WCAG s'est mis en dehors du jeu, concoctant, dans son univers parallèle, des directives qui s'appliquent de manière ambiguë à tout. Mais le Groupe de Travail a certainement pris le temps de supprimer quelques concepts consensuels.

Oui, nous le savons déjà (en) : un site valide Xhtml n'est pas automatiquement accessible (en). Nous avons deux ou trois pages amusantes pour illustrer ça (Avec Gez Lemon (en) et Bruce Lawson (en)). Mais ces exemples ne démontrent que ça. Dans le monde réel où l'ignorance produit de la soupe de tags, la minorité croissante qui comprend la validité Html est une élite qui comprend aussi l'accessibilité. Qui comprend que la validité Html facilite les dispositifs d'accessibilité (comme les textes alt, qui, oui nous le savons déjà, doivent être écrits correctement). Ces développeurs prennent toujours le temps d'inclure systématiquement les dispositifs d'accessibilité.

Ils comprennent aussi que la soupe de tags produit des résultats imprévisibles dans les navigateurs et les lecteurs d'écran. Ils savent qu'une simple esperluette mal encodée, un point virgule oublié (en), un caractère unicode perdu dans une page, peuvent la renvoyer sur les terres du Html invalide; mais ce sont là des exemples insignifiants non-représentatifs des pages de soupe de tags d'Amazon ou d'Ebay. (Ils connaissent le succès d'Amazon et Ebay malgré leur soupe de tags). Ils savent que la validité est un processus fragile qui peut être remis en cause par une chose aussi simple qu'un caractère comme é, un &nbsp (sic), ou un & à la mauvaise place. Ils savent tout ça.

Néanmoins, la validité Html est une exigence de niveau 2 (en) dans WCAG 1.0. Vous ne le constaterez jamais sur un site commercial; la récente enquête Nomensa en a trouvé quatre sur les 99 sites vérifiés manuellement; c'est le taux le plus haut que j'ai jamais vu. Mais comme c'est une exigence, cela alerte les développeurs, et alors que la soupe de tags est la norme, ils savent que ce n'est pas ce que nous voulons.

WCAG 2 met un terme à ce mouvement de fond. Vous n'avez jamais à valider le code Html pour un site conforme WCAG 2. Tout ce qui est exigé c'est que la page puisse être parsée de manière univoque (Directive 4.1 (en), une Directive de niveau 1 sans directive de niveau 2 ou 3). C'est est supposé signifier (en): Aucun élément improprement imbriquété mais cela n'est jamais dit de manière explicite.

Dans une page Html vous pouvez utiliser tous les caractères mal implémentés que vous voulez mais vous ne pouvez pas insérer un <p> dans un <p>. Vous n'avez pas l'obligation d'utiliser les éléments ou les attributs requis par les spécifications. Vous n'avez pas l'obligation d'utiliser les éléments en accord avec leur spécification (en) (Ndt : au sens de la sémantique). Dans le cas d'un formulaire, ces erreurs sont ennuyeuses et représentent une source constante de difficulté pour un utilisateur de lecteur d'écran. Un document composé uniquement de div et de span, s'il est parsable (analysable) de manière univoque, validera WCAG 2 sans problème.

L'analyse d'une page Xhtml est supposée s'arrêter à la première erreur de code mal formé, mais nous savons que ce n'est pas le cas dans le monde réel, où Xhtml est traité comme une sorte de HTML auquel sont rajoutés des slashes de fermeture, (sauf pour les rares perfectionnistes qui servent du Xhtml comme du Xml). Cette disposition donne, de fait, le même rôle à Xhtml qu'il donne à HTML.

Est-ce que ça résoudra vraiment le problème ? Ou est-ce que ça en donne suffisamment l'apparence pour que ce soit voté par des compagnies présentes dans le Groupe de Travail telles que IBM, Oracle ou SAP, dont les logiciels ont tellement de mal à produire un code Html véritablement valide. (IBM a activement promu (en) une technique de DHTML accessible qui viole les spécifications Html. Curieusement et de manière futile, le document Technique le décourage (en)).

Pensez-vous que WCAG 2 est suffisamment bon pour améliorer les pratiques des développeurs qui produisent de la soupe de tags ? Même si un code Html valide partout et tout le temps est inenvisageable, les faits montrent qu'en 2006 nous n'avons jamais eu autant de développeurs qui comprennent le concept et tentent de l'appliquer sur leur propres sites. WCAG 2 défait une disposition qui, si elle était conservée, serait parfaitement envisageable actuellement.

Sous-titres et description sonores pour le multimédia

S'il y a un thème pour lequel l'application de WCAG 1 était totalement inefficace, c'est le multimédia. Les gens se sont satisfaits d'ignorer les dispositions concernant les sous-titres (pour les sourds) et l'description sonore (commentaires additionnels pour les non-voyants), les deux (en) étant requis pour le premier niveau d'accessibilité. (En fait, c'était pire que ça; pour les mal-entendants vous pouviez vous en sortir en ne fournissant qu'une transcription au lieu de réels sous-titres).

Les sous-titres et les descriptions ne sont pas naturellement implémentées. Quand c'est le cas, c'est par les sous-titres. Dans cette perspective, le multimédia en ligne suit la TV, la vidéo et le cinéma où, dans la majorité des démocraties, les sous-titres sont utilisées et les description sonores ne le sont pas. (Qui peut oublier l'ironie du responsable accessibilité d'AOL, un non-voyant, annonçant le sous-titrage d'une sélection de vidéos (en) mais pas de description sonore ?).

Pour un non-voyant ou un sourd qui veut comprendre des contenus multimedia, WCAG 2 n'apporte aucun progrès. L'échappatoire qui n'exigeait que la transcription a été abandonnée et les sous-titres restent une obligation de premier niveau pour les vidéos pré-enregistrées. Mais au lieu de la description sonore, vous avez à faire à une invention tout droit sortie de l'imagination du Groupe de Travail et ainsi définie: une alternative textuelle complète au contenu multimédia y compris l'ensemble des interactions. Une survivance de WCAG 1, discriditée, qui est apparemment une combinaison (en)de la transcription des dialogues et des effets sonores (inutiles pour les non-voyants), une transcription de la description sonore (inutile pour les mal-entendants) et des liens pour chaque composante interactive de la vidéo.

On suppose que tout ça est destiné aux non-voyants sourds qui n'ont jamais été consultés sur leurs préférences, une action que j'avais recommandée lors d'une réunion (en) en 2003. Aucun test utilisateur n'a été effectué. ( C'est tout ce que je peux dire, de toute façon, avec ce qui est publié; j'ai envoyé une demande par email aux organisations de mal-voyants sourds de plusieurs pays pour leur demander si elles avaient été consultées ou avaient des avis, sans réponse).

Il y a environ trois exemples connus d'une telle transcription dans les sept années d'histoire du WCAG (e.g DigNubia (en)). Il n'y a pas vraiment de balises sémantiques appropriées pour de telles descriptions à moins que vous n'utilisiez des listes de définitions (en) (un usage interdit (en) par HTML 5).

Juste avant le niveau le plus bas, brusquement, une réelle description sonore est requise et, tout aussi soudainement, les vidéos en direct doivent être sous-titrées. Aller à l'étape suivante et vous devez traduire vos vidéos en langage des signes (lequel ? ), et, parmi d'autres choses, fournir le même procédé illusoire de transcription. Vous n'avez jamais à décrire une vidéo en live (en).

Et alors que je n'ai jamais été partisan d'exiger le sous titrage des centaines de radio en ligne, il est évident que les podcasts pré-enregistrés sont une source multimédia inaccessible. Mais actuellement « multimédia » est défini comme « un flux vidéo ou audio synchronisé avec un autre type de média et/ou comportant des interactions, basées sur le temps, avec d'autres composants ». Vos podcasts n'étant pas synchronisés avec quoi que ce soit en sont exemptés. Cette disposition satisfaira la majorité des podcasteurs qui ne se sont même jamais donné la peine de penser à l'accessibilité et à peu près tout ceux qui ont trouvés que cela demandait trop d'efforts, même s'ils ont aimé l'idée où on travaillé quelques temps (en) pour WAI. La disposition sera aussi la garantie que le statu-quo sur les podcasts inaccessibles sera maintenu.

Discussion à suivre

Je pense que c'est suffisant pour un article. Mais ce n'est pas la fin de mes commentaires sur WCAG 2; vous pouvez surveiller mon site web (en) pour de futur commentaires. Cet article à une section pour les commentaires, et le tag WCAG 2 (en) est une autre façon de le faire.

Annonce du WCAG Samurai

WCAG 2 n'est pas assez dévoyé pour qu'il soit possible de le corriger mais nous n'avons aucune raison de penser que le Groupe de Travail WCAG le fera. Le Groupe de Travail est trop compromis avec des intérêts privés, trop engagé dans les conclusions inhérentes à l'ébauche actuelle, trop devoyé. Ce que vous avez dans WCAG 2 est vraisemblablement ce que vous aurez finalement.

Tel qu'il est, WCAG 2 sera inutilisable par les développeurs, spécialement ceux impliqués dans le développement standard. Il est trop vague et circonstanciel pour être une base législative. Il laisse trop d'échappatoires aux développeurs qui les chercheraient. WCAG 2 est un échec, même pas noble.

Si c'est ce que nous obtenons quand WAI essaye de réécrire WCAG à partir de zéro, peut-être y a-t-il une autre option. WCAG 2 ne remplace par WCAG 1, pas plus que Xhtml ne remplace Html. Peut-être que tout ce dont nous avons besoin est de corriger les erreurs de WCAG 1. a déjà été discuté (en) mais un WCAG 1.0 seconde édition ou un WCAG 1.1 n'a jamais été mis en place.

Cependant, je peux annoncer aujoudhui que de telles corrections vont vraiment être publiées et que mes amis et moi allons nous charger de le faire. De la même manière que le groupe (en) de Zeldman, CSS Samurai, publie des rapports pour les éditeurs de navigateurs et les développeurs, le WCAG Samurai (en) publiera des corrections et des extensions aux actuelles spécifications en matière d'accessibilité.

Bien sûr nous n'allons pas enfreindre de copyright, et nous n'allons pas non plus mettre en place un processus totalement ouvert. C'est un modèle viable pour le développement standard, que j'ai soutenu dans un autre contexte, mais, en matière d'accessibilité, il est prouvé que ça ne marche pas. Les membres de WCAG Samurai, comme ceux de CSS Samurai, seront choisis uniquement sur invitation. Si nous vous choisissons, nous vous contacterons.

Bien sûr, c'est injuste, c'est le moins qu'on puisse dire, sinon très élitiste et hypocrite. Appelez ça comme vous voulez. Mais ce que nous allons essayer de faire, dans l'espoir que cela aboutisse, c'est ce que WAI et son modèle n'ont pas réussi à réaliser.

Fin de la traduction - illustration par Kevin Cornell (en) - Traduit avec la permission de A List Apart Magazine et ses auteurs : A List Apart, Copyright Notice, Translations - Translated with the permission of A List Apart Magazine and the author[s]


(1) Note au sujet de la traduction de "Authored":

La dernière version francophone du document de travail WCAG 2.0 traduit l'expression "Authored Unit" par "Unité de conception".

Authored signifie "ce qui est écrit (conçu) par un auteur", le sens "conception" n'est évidemment pas faux mais j'aurais préféré traduire "Authored unit" par "Unité Editoriale" et "Authored Component" par "Composant éditorial" qui me semble plus "parlant".

J'ai conservé la traduction "Unité de conception" et par conséquent "Composant de conception" pour respecter la version francophone du document de référence.