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

Sommaire

Le débat

Note : Cette version est annotée de nos observations


Marre des WCAG 2.0 par Joe Clark

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.

Jean-pierre

Ce point de vue se défend. En revanche il est absolument nécessaire que WCAG intègre les nouvelles formes d'exploitation du média internet et offre une possibilité de prendre en compte les types de contenus très divers diffusés par le web. On peut regretter le résultat mais pas la nécessité de ses objectifs.

Monique

WCAG 2 est un progrès puisqu'il prend en compte des technologies qui ne l'étaient pas (soit parce qu'elles n'existaient pas, soit parce qu'elles étaient marginales) et qu'il permettra de prendre en compte de futures technologies encore inconnues. Mais la majorité des personnes concernées, en tout cas à l'heure actuelle, ce sont les auteurs (ou responsables) de pages Web et ils n'ont pour ainsi dire plus aucune base pratique sur laquelle s'appuyer.

Aurélien

Derrière cette critique, je ne pense pas que Joe Clark regrette l'élargissement des WCAG 1.0 à tous les contenus web, j y vois plus une mise en exergue de l'importance de ce document qui revient sur les bases même de l'évolution qu'à put connaître le développement web en matière d'accessibilité ces dernières années. Cela démontre le nécessité absolue d'avoir un document compréhensible et applicable, ce qui est loin d'être le cas.

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.

Jean-Pierre

WCAG 2.0 marque une vraie rupture avec WCAG 1.0. C'est consubstantiel aux nouveaux objectifs qui y sont définis, notamment sa neutralité vis à vis des technologies. Il est difficile de se prononcer sur sa mise en oeuvre parce que WCAG 2.0 n'est pas un véritable document opérationnel comme pouvait l'être (mais avec d'autres problèmes) WCAG 1.0. Ses applications vont être multiples et nécessiteront la mise en place de méthodes opérationnelles spécifiques...

Monique

Le problème à mes yeux, c'est que seules les Guidelines sont normatives d'où peut-être cette impression de flou quant aux « obligations » à respecter.

Aurélien

Les WCAG 2.0 atteignent en effet cet objectif de neutralité technologique, mais le problème est double, en réalisant cette objectif, le document nécessite des méthodes opérationnelles pour être applicable, document qui compte tenu de la place laissée à l'interprétation de certaines directives pourrait diverger d'un pays à l'autre. L'utilisateur final et les développeur d'aide techniques ne pourront alors qu'en subir les conséquences. Ce qui replacé dans la problématique législative, rendent de faite les WCAG 2.0 inutilisable comme référence législative.

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

Jean-Pierre

Ce délais fait partie des procédures habituelles du W3C. Par ailleurs, il vient d'être prolongé de trois semaines. Enfin, on peut noter que, de début 2003 au 26 avril 2006, date de départ de la procédure "last call rewiew ", seuls 150 commentaires ont été publiés sur la liste WCAG 2.0

Aurélien

Ce qui pour un document de cette importance est tout de même alarmant, la faute sans doute, un peu au WAI qui il est vrai n'apparaissent pas forcement comme des experts en communication mais à nous autres standardiste pour reprendre le terme de Joe Clark qui nous intéressont au WCAG 2.0 peut être un peu tard.

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.

Aurélien

N'étant pas partie prenante dans le WAI, il nous est difficile de juger la véracitée de ces propos. Notons tout de même que la mise à l'écart des non anglophones ou que la capacité des participations supérieur pour les multinationales sont deux critiques qui pourraient être faite pour n'importe quel groupe de travail du W3C. Quant à la non participation de personnes handicapées, je pense que ces propos sont à modérer le WAI travaillant normalement en relation avec les représentants d'associations de personnes handicapées.

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.

Jean-Pierre

Je suis d'accord, WCAG 2.0 n'est pas opérationnel pour un type de langage ou un type de contenu donné. Pour sa mise en oeuvre, il sera nécessaire d'établir un processus particulier et de définir une méthode d'application.

Toutefois, je ne suis pas d'accord sur le fait que les directives aient été " lissées " ou " noyées " dans la masse du contenu. Il est normal, par exemple, que la référence à un attribut comme " alt ", spécifique à Html, soit remplacée par l'expression " alternative textuelle " qui peut indifféremment s'appliquer à une image dans un code Html, ou dans une animation flash. Il est vrai également que certaines formulations gagneraient à être retravaillées.

Monique

Il est vrai également que certaines formulations gagneraient à être retravaillées.
Oui et ce n'est pas gagné ! Quand on voit combien confondent des termes de base comme balise et attribut, parlent toujours de calques, sont convaincus que le contenu de l'attribut alt est ce qui s'affiche au survol de la souris...

De par leur conception, ces documents représentent une masse considérable d'informations qui pourraient rebuter certains auteurs de pages Web. Contrairement aux développeurs (utilisant un langage de programmation), beaucoup utilisent un logiciel WYSIWYG et maîtrisent peu, pas ou mal le code et les spécifications.

Aurélien

La critique qui peut être faite est que certes les éléments de priorité 1 ont été maintenu et développé mais ce n'est pas principalement les éléments qui avaient besoin de l'être car ils commençaient en règle général a être bien compris par les standardistes. Nous attendions surtout des directives de niveau supérieures plus poussées, plus précise et plus exigentes dans certain domaines, or ce n'est pas le cas avec ces WCAG 2.0 ou de façon timide est incomplète.

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.

    Jean-Pierre

    Il est vrai que la notion de "page" ou de "site" n'est plus explicitement employée. Maintenant dans un site 100% Flash où est la notion de "page"?
    De même dans une application AJAX, la notion de "page" est particulièrement "volatile". La notion de page est remplacée par la notion "d'unité web", celle de "site" est plus floue, remplacée par "Unité de Conception". C'est plus abstrait, plus difficile à comprendre et cela peut donner lieu à des divergences d'interprétations mais c'est en même temps plus adapté.

  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.

    Jean-Pierre

    Certes, le tampon " html valid " ne sera plus exigé, en revanche, la validité Html sera le moyen le plus simple, le plus facile, le plus économique et le plus rationnel pour garantir la directive 4.1 : " Assurer la compatibilité avec les agents utilisateurs courants et à venir, y compris les aides techniques" . (Voir à ce sujet mes notes sur le chapitre " C'est comme si les standards du web n'avaient jamais existé " )

    Monique

    Dans les Techniques, F28: Failure of SC 4.1.1 due to using markup that results in inconsistent DOMs in user agents si on suit le lien How to Meet Success Criterion 4.1.1 on retrouve

    • Ensuring that Web units can be parsed unambiguously by using one of the technology-specific techniques below (future link) OR
    • Validating Web units OR
    • Fully Conforming to specifications (future link)
    Aurélien

    La vérification que demande WCAG 2 est irréalisable pour un webmaster lambda et penser que tout le monde pourra s'offrir les services d'un expert capable de le faire est également une lourde erreur à ne pas commettre.

    Certes la validation de la grammaire reste le moyen de vérifier cela le plus simplement et comme le montre Monique cela est dit dans le document d'accompagement au point 2. Validating Web units. Cependant, il aurait été préférable à mon sens d'exiger la validité du DOM au niveau le plus bas mais de garder la validité à une grammaire pour un niveau supérieur directement dans les directives.

  3. Vous pourrez continuer à utiliser des tables de mise en page. (Et pas juste une table, tables for layout (en), plural (en).)

    Jean-Pierre

    L'interprétation est 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 éléments de contenu.

    Il est simplement précisé que l'usage de tables de layout n'est pas une cause d'échec, si elles sont utilisées comme telles !

    Rien dans ce passage n'est destiné à autoriser ou favoriser leur usage. Notamment la directive 1.3 " Garantir que la structure et l'information peuvent être séparées de la présentation ". Appliqué à Html , celle-ci implique, de la même manière que pour la validité Html, l'usage de la mise en page CSS comme moyen le plus simple et le plus rationnel.

    Monique

    Je crois que le fait de ne pas interdire totalement l'usage de tables pour la présentation est réaliste. Il est des cas où le seul usage des CSS (colonnes de même hauteur...) est assez difficile à gérer de manière simple... de là à multiplier les tableaux imbriqués, la frontière est-elle facile à faire admettre ?

    Aurélien

    Joe Clark se trompe effectivement sur les exemples qu'il donne et exagère dans son interprétation des directives, à mon sens, la directive 1.3.3 When the sequence of the content affects its meaning, that sequence can be programmatically determined. Interdit bien par exemple l'utilisation de tableau de mise en forme mal imbriqués qui ne se linéariserait pas correctement. Donc il y a interdiction de mal utiliser les tables de mise en pages mais pas de les utiliser tout court ce qui pourrait être le cas sur un niveau de directive supérieur. Pour bien comprendre, la position du W3C je vous recommande de lire les Questions sur la séparation du contenu et de la présentation (en).

  4. Votre page, ou une de ses parties, pourra clignoter jusqu'à trois secondes (en). Mais, évidemment, Une partie (en) ne pourra pas flasher.

    Jean-Pierre

    Oui, cela peut correspondre notamment aux cas où le clignotement d'éléments dans la page est "imposé", "requis" ou "fortement souhaité".

    Dans ce cas, l'usage, établi par la Communauté des experts, autorise le clignotement pour un cycle unique, bien difficile à déterminer car la directive WCAG 1 " Evitez de faire clignoter le contenu " permet toutes les interprétations...

    La directive équivalente WCAG 2 impose une limite : 3 secondes et/ou de fournir un moyen de stopper le clignotement continu d'un élément. C'est typiquement le genre de compromis que l'on rencontre tous les jours. Il n'y a pas d'ambiguïté avec l'autre point de cette directive, concernant les " flash ". Ces derniers sont déterminés très précisément et sont proscrits, eu égard à leurs possibles conséquences, notamment sur les syndromes photo-sensibles.

    Aurélien

    oui la distinction est nécessaire mais on ne peut pas dire que la différence entre un flash et un clignotement soit très clair sans aller lire les spécification techniques détaillée de ce qu'est un Flash pour le W3C et encore plus compliqué pour le mesurer par soit même.

  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.

    Jean-Pierre

    Oui, WCAG 2 créée un nouveau concept , l'essence même de ce travail, la fameuse "référence de base" qui va faire couler beaucoup d'encre.

    Il est regrettable que Joe ne réfère pas à l'explication que donne WCAG de cette notion. Sans entrer dans les détails, une référence de base est définie par l'ensemble des technologies utilisées, qu'on suppose supportées et implémentées par un agent utilisateur et que l'on décide de rendre accessibles.

    HTML+CSS+Javascript constitue, par exemple, une "référence de base" . L'auteur doit alors s'assurer de plusieurs choses :

    • Que l'ensemble des contenus et fonctionnalités soit garanti pour tous les agents-utilisateurs implémentant la "référence de base".
    • Dans le cas inverse que les contenus et les fonctionnalités aient une alternative accessible.
    • Et que, dans ce cas, les technologies du référence de base ne bloquent pas l'accès à ce même contenu.

    Si on se contente du référence de base cité plus haut, on est en territoire connu.

    En voici une autre : Html+CSS+javascript+flash 8. Dans ce cadre, WCAG 1 ne nous obligeait pas à rendre accessible l'animation flash mais recommandait simplement que soit produit une alternative. WCAG 2 demande la même chose mais requiert de rendre accessible l'animation Flash pour les agents utilisateurs supportant le "référence de base".

    C'est un progrès immense qui résout ce paradoxe bien connu : Une animation flash " opérable " est lue par un lecteur d'écran sans pouvoir être utilisée. L'alternative est, de fait, " inaccessible " pour le lecteur d'écran en capacité d'en lire le contenu.

    Pour terminer, la référence de base " html ", seule, revient à faire du WCAG 1.0...

    Monique

    Cette notion de "référence de base" est intéressante, elle permet de mieux gérer l'impact des différentes technologies utilisées... en principe. Ce qui m'inquiète c'est comment répondre à cette condition (en) success criteria in the guidelines are met assuming user agent support for only the technologies in the specified baseline quand on connaît le nombre d'implémentations et de rendus différents selon le système et les logiciels utilisés, leur version, leurs combinaisons... Combien pourraient se permettre de tester « Firefox 1.5 on Windows 2000 SP4 with Jaws 7.0, Firefox 1.5 on Windows XP SP 2 with Jaws 7.0, IE 6.0 on Windows 2000 SP4 with Jaws 4.51, IE 6.0 on Windows 2000 SP4 with Jaws 7.0, and Firefox 1.5 on Windows XP SP2 with Jaws 7.0, Safari 2.0 with OS X 10.4 » (Example 1 (en)), à partir de combien de tests effectués l'accessibilité peut-elle être considérée comme conforme à un niveau ?

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

    Jean-Pierre

    C'est vrai, c'est un sujet de débat intéressant. Quelle attitude vaut-il mieux adopter :

    Considérer qu'un site est inaccessible parce qu'il héberge un programme ou des contenus particuliers (par exemple, un module de visualisation 3D impossible à rendre accessible) alors que "tout le reste" est accessible.

    Considérer qu'un site est inaccessible parce que son auteur n'a pas les moyens de rendre ses vidéos accessibles, ce qui peut être très cher, alors que tout le reste l'est.

    Dans ces deux cas, WCAG 1.0 n'a aucune solution à proposer , ce qui très " décourageant " et souvent un frein important au début d'une réflexion. WCAG 2.0 prend acte de ces situations et propose un " compromis " : on peut exclure des contenus à deux conditions :

    1. Ils sont annoncés et identifiés par la déclaration d'accessibilité.
    2. Ces contenus ne viennent pas interférer avec du contenu accessible.

    Dans l'exemple qu'utilise Joe, effectivement un ensemble de vidéo peut être exclu mais à la condition qu'il soit localisé et qu'elles ne soient pas affichées dans des pages accessibles, il est en revanche possible de les lier de manière explicite. Il est évident que cette disposition pourra être détournée ou servir d'alibi facile à des mauvais plaisants. Mais, au moins, les auteurs de bonne volonté ne seront plus pénalisés.

    Monique

    Je suis d'accord avec ta conclusion.

    Aurélien

    Je rejoint l'avis de Jean Pierre, cependant la déclaration d'accessibilité n'est nullement obligeatoire et le W3C lui même n'est pas clair dans l'explication de cette notion il dit : Scoping cannot exclude a particular type of content (for example, images or scripts) since it would allow exclusion of individual success criteria. qui pourrait se traduire en français par un type particulier de contenu ne pourra être exclu puisqu'il autoriserait l'exclusion de critères de succès spécifique à ce type de contenu, or dans l'exemple de mise en oeuvre cité par le W3C il est choisi d'exclure spécifiquement toutes les vidéos. Plus largement, si en théorie ce notion d'exclusion peut être grandement bénéfique au développement de l'accessibilité, c'est aussi en l'état une énorme porte ouverte pour que chacun fasse ce qu'il veut au détriment des utilisateurs.

  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.

    Jean-pierre

    Oui la critique est juste.

    Monique

    Oui, quand on voit des exemples comme ceux donnés dans la page que je cite au point 5...

  8. Bien que personne ne se soit donné la peine de les rendres accessibles, mais 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.

    Jean-pierre

    Je ne comprends pas Joe Clark. Comment interprète-t-il alors cette recommandation, "Critères 1.2.2 (Niveau 1) : Une description sonore pour les vidéos ou une alternative textuelle complète y compris les interactions sont fournies pour les éléments multimédia pré-enregistrés "?

    Monique

    J'avoue ne pas bien m'y retrouver dans ces directives (différences entre niveau 1 et niveau 2). Si les vidéos ne sont pas pré-enregistrées (webcam par exemple), je ne vois pas comment on pourrait sous-titrer. [traduction : ne parle-t-on pas plutôt de sous-titres pour des vidéos et de légendes pour des photos ?]

    Aurélien

    La possibilité est laissé de ne pas synchroniser la description sonore au niveau 1 et de donner uniquement une version texte comportant ces informations.

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

    Jean-pierre

    Il est vrai que les podcasts ne rentrent pas, strictement, dans la définition d'un élément multimédia, en ce qu'ils ne sont pas " synchronisés " avec un autre élément. Mais on devra, car ce sont des éléments non-textuels, fournir une alternative textuelle en bonne et due forme. L 'argument de Joe est également, ici, tendancieux, à moins que je ne le comprenne pas. On pourrait supposer qu'on peut se dispenser de rendre ces contenus accessibles ce qui est faux.

    Monique

    Les documents sonores sont bien des éléments non textuels, mais vu l'importance prise par les podcasts, il aurait peut-être été utile de préciser la manière de les traiter.

    Aurélien

    Effectivement Joe Clark a tort sur cette critique, il est clairement indiqué dans comment satisfaire la directive « Fournir une alternative textuel au contenu non textuel » : For non-text content that presents information, such as charts, diagrams, audio recordings, pictures, and animations, text alternatives can make the same information available in a form that can be rendered through any modality (for example, visual, auditory or tactile). Short and long text alternatives can be used as needed to convey the information in the non-text content. Note that pre-recorded audio-only and pre-recorded video-only files are covered here.

    L'alternative texte est donc bien obligatoire dans le cas d'un podcast. Quant au diaporama, il sera effectivement nécessaire de les soutitrer ou de s'assurer que les aides techniques ont bien accès successivement aux différentes alternatives textuelles.

  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.

    Jean-pierre

    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 là 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 la présentation d'un sommaire de documentation technique, où nous n'avons qu'une liste de liens ordonnés, il n'y a aucun souci à en avoir plusieurs centaines au contraire! L'accessibilité va se jouer sur une TOC et des Bypass, pas sur la quantité de liens.

    Monique

    Le libellé des liens, compréhensible hors contexte, me aussi plus important que leur nombre.

  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.

    Jean-pierre

    La critique est fondée. Ce point ne devrait pas relever de l'accessibilité mais de l'ergonomie et de la qualité. Entre nous, il me semble plus facile de justifier un écart à la norme pour le cas d'un formulaire à contrôle 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 est une grosse bêtise même si c'est "validé".

    Aurélien

    Je ne trouve nul part dans le lien mentionner par Joe Clark l'interdiction de positionner hors écran des labels, par contre il est recommander lorsque l'on ne peut pas en mettre pour des raisons de design d'utiliser l'attribut title sur les champs de formulaire.

  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.

    Jean-pierre

    Je dois dire pour paraphraser Joe " qu'il est dur mais juste de dire " que l'ami Joe est particulièrement tendancieux, pour rester diplomatique, sur cette critique.

    Il n'y a rien qui interdise le positionnement absolu, et je mets au défi quiconque de démontrer le contraire. Le critère référent est le point 1.3.3 Quand une séquence de contenu affecte son sens, la séquence peut-être programmatiquement déterminée. La seule critique qu'on peut faire ici est que cet intitulé n'est pas particulièrement clair.

    Il faut pour le comprendre se reporter aux documents annexes, notamment "comprendre WCAG 2.0" qui "éclaire" ce critère :

    L'objectif de ce critère est de s'assurer qu'un agent utilisateur peut fournir une présentation alternative d'un contenu en préservant l'ordre de lecture nécessaire à sa compréhension.

    Une séquence est à considérer lorsque l'ordre du contenu ne peut être changé sans en modifier le sens.

    C'est encore obscur ? Rendez-vous sur l'exemple de défaillance, celui-là même qui est repris par Joe. Il illustre le cas où un positionnement absolu est utilisé pour " simuler " un tableau, à partir d'une énumération de termes encapsulés dans des conteners anonymes span. Cet exemple n'implique pas l'interdiction d'utiliser du positionnement absolu, mais interdit de le faire à mauvais escient !

    Il n'y a pas non plus à rapprocher l'ordre du flux de sa représentation graphique SAUF si l'un ou l'autre et les techniques utilisées pour les produire modifient le sens du contenu. WCAG 1.0 disait exactement la même chose, d'une manière différente, avec le critère 6.1 Organisez vos documents pour qu'ils soient lisibles sans les styles de présentations. L'exemple donné en illustration de ce point étant quasi-identique pour WCAG 1.0.

    Monique

    Oui... c'est juste un peu moins évident à comprendre que dans les WCAG 1.0.

    Aurélien

    Effectivement Joe Clark se laisse emporter et tire des conclusions attives, sans doute à cause de la place laissée à l'interprétation. A noter que dans tous les cas la directives et de niveau 1 et non de niveau maximum comme le dit Joe Clark.

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

    Oui, c'est une contrainte forte mais il est précisé : Pour identifier des définitions spécifiques de mots ou de phrases utilisés de manière particulière ou inhabituelle. Ce qui, de mon point de vue, change tout ! Le sujet n'est pas de fournir un glossaire systématique mais de le faire quand c'est utile et nécessaire pour des termes spéciaux.

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

    Jean-pierre

    Ce sujet est identique à WCAG 1. Il est particulièrement difficile et je ne vois pas bien comment le traiter autrement que, le cas échéant, en produisant des versions adaptées.

    Monique

    Je ne comprends pas ceci (pas la traduction mais l'implication) :

    3.1.5 When text requires reading ability more advanced than the lower secondary education level, supplemental content is available that does not require reading ability more advanced than the lower secondary education level. (Lower secondary education level : the two or three year period of education that begins after completion of six years of school and ends nine years after the beginning of primary education.)

    Il faut juger du niveau scolaire ??? Il semble que oui quand je lis :

    Educators can also measure the education level required to read text content. For example, qualified teachers can evaluate text according to local education standards to determine if it requires reading ability beyond what is expected for students in the last year of lower secondary education.

    Sinon, je confirme les difficultés rencontrées avec les acronymes, abréviations ou autre jargon... dans mon cas, dyslexie non décelée (on n'en parlait pas à mon époque) combinée avec les séquelles de la méthode globale mal utilisée !

    Aurélien

    Ce jugement par le niveau scolaire me semble ridicule, à quand la détection automatique du QI par le navigateur grâce à javascript, je ne vois pas comment l'ont peut choisir que tel ou tel mot sera compris par tel ou tel publique et encore moins savoir à l'avance qui va venir lire notre site ou pas. Le niveau scolaire ne prévaut en rien des capacités de lecture, dois je rappeler qu'en France, même si ce n'est pas la majorité certaines personnes arrivent jusqu'à la journée d'appel nationale (18 ans, niveau bac) en étant dyslexique.

    Pour ce qui est des versions alternatives, on ne pourra pas empêcher que certains sites continus à se faire entièrement via des technologies non accessibles mais peut être devrait il être mentionné que cela concerne principalement les référence de bases autre que html. Dans ces cas là, à défaut d'autre chose, une version accessible équivalente séparée, c'est mieux que rien du tout.

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. Les définitions vont s'occuper de ça.

WCAG 1 est spécifique à HTML. Chacun reconnaît que c'est un problème à une époque où des formats, comme PDF et Flash, qui posent tant de problèmes aux non-voyants, 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, comme des formats pas encore inventés qui devraient ê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).
Parser 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.

Jean-Pierre

Il est vrai que certaines définitions, et celles-ci en font parties, sont relativement obscures, elles ne sont pas pour autant "incompréhensibles". Elles sont fondées sur des normes terminologiques (Glossary of Terms for Device Independence pour Authored Unit par exemple, ou Web Characterization Terminology & Definitions Sheet pour Web Unit).

Monique

Disons que cela ne nous simplifiera pas la tâche d'information et de promotion des directives auprès des webmasters « moyens » qui se contentent de produire des pages Web de base, qui ne sont même pas encore convaincus de l'importance d'un code (XHTML et CSS) valide et conforme.

Aurélien

Euh, elle est ou la version accessible des WCAG 2 pour les personnes du niveau d'éducation seconde le plus bas, qu'il puisse la comprendre.

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.

Jean-Pierre

Prenons par exemple un agrégateur de nouvelles basé sur une interface web et essayons d'illustrer ces définitions pour voir si elles sont " manipulables " ou tellement obscures qu'elles en deviendraient incompréhensibles.

L'unité de conception (1) : Elle peut représenter trois choses différentes selon le point de vue de l'analyse :

  1. Ce serait l'ensemble du contenu, le balisage et les styles de mise en forme diffusé par le moyen des flux RSS.
  2. Ce serait l'ensemble du contenu, le balisage et les styles de mise en forme diffusé par le moyen d'un seul de ces flux RSS, pris et considérés isolément.
  3. Ce serait également l'ensemble des pages relatives à la diffusion de ces Flux RSS, par exemple si ces pages ne sont que la partie d'un ensemble plus vaste (comme un agrégateur de flux dans un site d'informations spécialisées)

Le composant de conception:

Ce serait l'ensemble du contenu, le balisage et les styles de mise en forme diffusé par le moyen d'un seul de ces flux RSS, considéré comme élément de l'ensemble. Ce serait aussi tout autre ensemble d'élément constitutif du flux lui-même.

L'unité-web : Ce serait l'interface elle-même, identifiée par sont Url unique, donc la page.

Mis à part la petite gymnastique intellectuelle nécessaire pour " manipuler " le concept d "unité de conception" qui peut prendre plusieurs formes, est-ce vraiment aussi " incompréhensible " que ça ?. Cela peut paraître exagérément tordu, obscur et compliqué et ça l'est dans le cadre de quelque chose d'aussi connu qu'un agrégateur de nouvelles basé sur le web.

Entre nous, je parlerais évidemment des "contenus" diffusés par une "page" web regroupés en " rubrique ". Je ne suis pas fou au point de vouloir à toute force discourir sur les unités de conception et l'unité web de mon agrégateur.

Prenons un autre exemple : Qu'est-ce qu'une animation flash ?

Si l'on se réfère à ces définitions, une animation flash est une " unité web " bien qu'elle ne soit pas une " page ". En revanche, ce n'est jamais une unité de conception ni un composant de conception parce que ce n'est pas du contenu. Elle est composée exclusivement d'unité de conception et de composants de conception car dans une animation flash il n'y a pas de " pages".

Allez, on continuera à dire " animation ", " contenus " et " rubriques ", nous sommes des gens bien élevés.

Néanmoins, dans d'hypothétiques outils d 'analyse sémantique et de représentation ontologique, basés sur des technologies 3D, où ces notions de rubriques ou de pages n'auraient plus de sens, je ne suis pas certain qu'il ne soit pas plus simple d'adopter finalement ce genre de terminologie.

Evidemment, la critique de Joe sur la clarté et la difficulté de compréhension est juste, mais qu'elles sont les propositions pour qualifier des contenus diffusés autrement que sous forme de "pages" ou de "rubriques" ??

Monique

Comme nous parlons généralement de navigateur et non d'agent utilisateur...

Aurélien

Comme je l'ai dit WCAG 2 atteint parfaitement ces objectifs, les termes employés ne sont pas clairs mais c'est normal par rapport à l'objectif. Le problème est pour les législations qui s'appuient sur les WCAG explicitement dans leur texte de loi (bien que très peut doivent contenir la mention WCAG2 de toute manière puisqu'elle ne sont pas encore sorti). Ce qui est regrettable c'est qu'en conséquence de cela, comme l'utilisateur se perd parfois dans les méandre de la législation internationale il va se perdre dans les méthodologie d'utilisation des WCAG. Qu'elle méthodologie appliquer lorsqu'il s'agit d'un site internationale, du site français d'une marque américaine, hébergé en russie, dont la gestion ce fait en inde avec un CMS australien unique pour gérer tous les gabarits de pages de tous les sites de la compagnie.

Procédure de test

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.

Jean-Pierre

Je trouve que c'est un faux procès, la directive WCAG 1 est fondamentalement inapplicable. Qui peut juger de la clarté et de la simplicité d'un texte ? J'écris ces lignes en étant absolument certain qu'un nombre considérable de lecteurs me trouveront exagérément compliqué.

On peut faire le reproche à WCAG 2.0 de ne plus insister, comme le faisait WCAG 1.0 sur la qualité de l'écriture et sur le fait qu'un contenu " écrit " est " difficile " à " écouter " et qu'il faut respecter un minimum de clarté et " d'intelligence " dans l'écriture.

Lequel d'entre vous, honnêtement, à jamais fait apparaître dans un rapport que l'idée principale d'un paragraphe n'était pas assez " remontée " en haut du corps de texte, où que le style ou la syntaxe n'était pas assez claire et " simple ". Il m'est arrivé des dizaines de fois de faire comprendre les avantages d'une écriture de qualité, jamais de refuser de valider un site pour cause de contenus " exagérément " compliqués.

Le cas des déficients cognitifs est un problème très spécifique qui ne peut pas se résoudre par un travail, aussi profond soit-il, sur l'intention éditoriale initiale. Le passage par des versions alternatives, séquencées, accompagnées, bénéficiant de signalétiques particulières me semble la moins mauvaise des solutions.

Monique

Maintenir une seule version en tenant compte de certains troubles cognitifs, cela reviendrait en quelque sorte à niveler par le bas. C'est le plus souvent impossible et irréaliste.

Aurélien

Certes, écrire un contenu compréhensible de tous est difficile voir impossible mais à noter tout de même, qu'il existe un profession qui s'appelle rédacteur web et que bien trop souvent la rédaction d'un contenu adapté au web est laissé de côté, faute de temps et d'argent ou de compétences. Cette directive de WCAG 1 disparu était là pour rappeler cela à mon sens.

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 ?

Jean-Pierre

Je ne comprends pas en quoi WCAG 1.0 était meilleur ou pire.

Monique

Tendancieux encore une fois.

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

Jean-Pierre

La remarque de Joe est juste en ce qui concerne la différence d'approche. Dans WCAG 1.0, les directives de priorité 3 étaient considérées comme moins importantes et finalement perçues comme des moyens d'améliorer les directives de niveaux inférieurs. Cette logique qualitative a été abandonnée au profit d'une logique différente : toutes les directives sont importantes « pour quelqu'un ». Pour ma part, je trouve qu'il s'agit d'un progrès.

Mais, paradoxalement, le niveau 3 conserve un statut particulier, comme il l'était dans WCAG 1.0, en regroupant un ensemble de directives spécifiques à des besoins ou des utilisateurs particuliers. WCAG 2.0 ne justifie pas le seuil de 50% des directives de niveaux 3 à respecter pour la validation, c'est bien dommage car c'est effectivement difficile à comprendre.

Aurélien

Personnellement je suis d'accord avec Joe Clark.

Si il avait été jusqu'au bout de cette nouvelle approche, la séparation en 3 niveau ne devrait plus être présente, surtout que dans la situation actuelle le niveau 3 n'est toujours présenté que comme un supplément innatteignable.

Au final ce double discours manque donc cruellement de cohérence ce qui ne va pas aider l'utilisateur à faire son choix quand au niveau à atteindre.

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.

Jean-Pierre

Cette critique est certainement la plus fondée. En effet, elle marque une rupture importante avec la philosophie générale du W3C concernant la normalisation des langages. C'est une position de compromis relativement intéressante puisqu'elle permet d'intégrer des cas qui étaient difficiles à traiter. Un exemple simple est celui de certains éléments, comme des attributs spécifiques, insérés dans des applications web à diffusion restreinte ( interfaces d'intranet, ... ). Ces pages ne sont jamais validables pour la norme de langage mais, pour autant, les insertions d'attributs propriétaires n'ont jamais gêné la restitution; ils sont purement et simplement ignorés.

Toutefois, la critique sur la disparition de ce levier important de la normalisation des langages est juste. Je ne suis pas sûr que ce soit la marque d'une volonté délibérée de torpiller l'essence même des activités du W3C mais plus sûrement le constat qu'on ne peut pas exiger quelque chose d'irréalisable. Quoi qu'il en soit, la conformité du code aux spécifications est implicite dans l'objectif de garantir la directive 4 sur la " robustesse " des restitutions.

Monique

Implicite oui, mais pas normatif... alors à quoi cela sert-il que les spécifications du W3C le soient ? En fonction du but poursuivi, de son niveau de compétence et d'éventuelles contraintes de production, le choix d'un doctype est libre. Un HTML Transional est un minimum qui n'est pas si difficile à atteindre. J'avoue que cette absence d'obligation est une des choses que j'ai le plus de mal à admettre dans les WCAG 2.0.

Aurélien

Pour information, il est possible de valider même avec des attributs propriétaires en définissant sa propre DTD grâce au XML.

Je partage néanmoins l'avis de Joe Clark sur ce point à mon sens la validation du code par rapport à une grammaire défini devrait toujours être dans les directive ne serais ce qu'au niveau maximum. Si en 1999, cela était fou et irréalisable, cela l'est parfaitement maintenant, de grand groupe le font comme de tout petit, c'est avant tout un choix sur la qualité et cela sans forcement devoir payer un coup supplémentaire, on ne compte pas le nombre de développeurs indépendants ou de sociétés respectueux des standards et à des tarifs tout à fait normal).

Ne pas envoyer de message clair quand à la position des WCAG sur ce point n'est pas promouvoir la qualité globale du web et son évolution.

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.

Jean-Pierre

Même si les podcasts ne font pas partie de la définition des éléments " multimédia ", ils sont des éléments non-textuels pour lesquels nous devons fournir une alternative textuelle. De nouveau je trouve la présentation de cette critique très spécieuse, on pourrait croire qu'il n'est pas nécessaire de fournir une alternative aux fichiers audio pré-enregistrés comme un podcast, c'est absolument faux.

Aurélien

Voir les remarques des points 8 et 9 de Joe Clark.

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.

Jean-Pierre

Joe lance une initiative intéressante mais mal orientée . A quoi bon essayer d'améliorer WCAG 1.0 alors même que des pans entiers des technologies web actuelles lui échappe ? Il est certain qu'on aura besoin de méthode d'application et de guides " pédagogiques " pour implémenter WCAG 2.0.

L'énergie du futur WCAG Samurai aurait sans doute été mieux employée à produire du contenu pédagogique sur la base de WCAG 2.0, quitte à donner des recommandations annexes, supplémentaires, additionnelles ou " volontaires " pour corriger les défauts et les imperfections. Le sujet du WCAG Samurai est clairement d'établir une scission avec WAI et WCAG, à l'image de ce qu'est le WHATWG pour HTML 5.

C'est, à mon sens, la pire chose qu'il puisse arriver à l'accessibilité du web. La situation est déjà assez compliquée comme ça. Entre WCAG 1.0 inadapté, des méthodes d'application qui l'interprètent plus ou moins bien, associées ou non à des processus de labellisation, des législations plus ou moins restrictives et, maintenant, une guerre ouverte avec WAI menée par une " figure " de l'accessibilité. Je ne suis pas certain que l'utilisateur y retrouve ses petits.

Monique

Je ne peux qu'être d'accord, malheureusement.

Aurélien

Je partage l'avis de Jean Pierre, à la différence qu'ici selon Joe Clark ce sont les industriels qui ont le mauvais rôle alors que pour HTML 5 ils ont plutôt le bon (ce n'est que mon avis personnel).

On pourra regretter également l'opacité de WCAG samouraï qui est pourtant une critique qu'il fait vis à vis du WAI.

Nos conclusions

Jean-pierre

WCAG 2 est une évolution majeure dont le web a besoin, ce n'est pas parfait, loin de là, mais cela réponds à certaines problématiques qui sont actuellement des verrous importants. Je peux comprendre le " désarroi " de certains face au degré d'abstraction de WCAG 2 qui décris des objectifs et des méthodes là où son prédecesseur ne décrivait que des implémentations réputées " immédiatement applicables " et exclusivement liées à Html.

On peut se représenter WCAG 2.0 comme une " boite à outils ", technique et méthodologique, avec laquelle il est possible de définir autant de cadre d'application que de besoins. Ce ne peut pas être un " document opérationnel immédiatement applicable et à la portée de tous ". WCAG 1.0 ne l'étais pas non plus même si il pouvait être perçus en tant que tel, avec les effets pervers que l'on connait.

C'est à l'ensemble des acteurs spécialisés de s'approprier WCAG 2.0, de produire le fond pédagogique nécessaire, les cadres techniques d'applications et les cadres réglementaires. Il est de notre responsabilité de commencer ce travail, de s'y préparer, si on ne veut pas prendre le risque de voir WCAG 2.0 massivement rejeté faute de disposer des outils pour le comprendre.

Monique

Conclusion générale après une overdose de lecture des directives, de leurs explications et des techniques... je pense qu'il sera urgent de s'organiser pour sortir au plus vite une traduction en français de la version définitive de ces documents ! Comme traductrice je serais peu productive, mais je serais disponible comme relectrice.

Aurélien

Oui il faut en passer par là, mais malheureusement si l'on veut quelque chose d'officiel il faut demander l'autorisation au WAI qui doit qualifier la traduction comme étant correcte ce qui de toute façon nous rendra après la date maximum pour pouvoir commenter ces WCAG 2.

Au final, je dirais oui les WCAG 2 sont une réussite par rapport aux objectifs fixés, oui elles contiennent de nombreuses évolutions intéressante, malheureusement tout cela est parfois innabouti et laisse une large place à l'interprétation sur un document qui tel qu'on l'attendais ne devais pas le permettre.

Le document est de qualité mais les gens seront déçus et désorientés face à un tel document ce n'est pas ce qu'ils attendaient, ce n'est pas une bonne base législative et ce n'est pas applicable si ce n'est pas des experts qui sauront allez lire entre les lignes parmis les nombreux documents satellites.

Fin de la traduction anotée


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