Blog Accessibilité

Trackbacks

Aucun trackback.

Pour faire un trackback sur ce billet : http://www.blog-accessibilite.com/dc/tb.php?id=11

Commentaires

1. Le mardi 7 décembre 2004 à 01:24, par Jpvillain

Ce qui démontre à contrario toute l'ambiguité de la démarche d'accessiweb qui donne un niveau "parfait" à un site qui n'obtiendrais pas le niveau WAI/AA, avec un code HTML particulièrement lourd, du javascript inline, des erreurs de validations de code, une utilisation abusive de la mise en page par tableaux imbriqués et des avancées technologiques pour le moins surprenantes comme les gif transparents "pipé", ce qui entre paranthèse, les rends inopérables pour les lecteurs d'écrans qui auraient désactivés la lecture des images...

Certes l'effort est louable mais franchement, ce genre de page n'est-elle pas tellement plus simple à faire en HTML standard Strict (je ne parle même pas de X...), full CSS et avec un minimum de sémantique ?
Dans cette optique, la question de l'accessiblité ne se poserait plus qu'en terme d'optimisation d'un niveau AAA déjà atteint à la réalisation...

Je suis très respectueux du travail d'accessiweb mais je ne peux m'empêcher de penser qu'à force de vouloir trop en faire (tout valider même l'innommable), ils en viennent à aller à contre sens de toute la démarche du W3C qui est d'amener les concepteurs de pages web à adopter les langages et les méthodes standards qui de facto offre une base d'accessiblité à optimiser au lieu du bricolage (je ne vois pas d'autres termes) que l'on peut voir à l'oeuvre sur les pages de ce site...

2. Le mardi 7 décembre 2004 à 09:24, par Matthieu Faure :: site

L'objet du Label AccessiWeb est de certifier l'accessibilité d'un site, pas la beauté de son code HTML.

Les recommandations du W3C en matière d'accessibilité sont très claires (relisez les WCAG ou les critères AccessiWeb, plus digestes): il n'y a aucune interdiction d'utiliser des tableaux, aucune sur les gif, aucune sur le javascript... Par contre, toutes les images doivent posséder une alternative textuelle, tous les tableaux doivent posseder un attribut summary, le javascript doit avoir une alternative, etc.

Evidemment, certains (et j'en fait partie) préfèreraient un code XHTML strict et conforme, mais le duo XHTML/CSS n'est pas encore la solution absolue. Beaucoup de sites en XHTML/CSS ne valident pas les critères AccessiWeb 10.2 et 10.3 (http://www.accessiweb.org/fr/Label_Accessibilite/criteres_accessiweb/92_accessiweb_lineaire/), alors qu'un tableau de mise en forme bien fait valide haut la main ces deux critères.

La route est longue, mais nous y arriveront

3. Le mercredi 8 décembre 2004 à 02:23, par jpvillain

Certes mais la beautée (je dirais plutot la simplicité) d'un code est le moteur de son efficacité.
Ma réaction un chouia épidermique viens du fait que je suis, depuis longtemps, assez critique sur le référentiel de braillenet, qui me semble souffrir des même symptômes que la section 508 US et de ses effets pervers...

Mon activité proffessionnelle, je suis "expert" en accessibilité et en développement standard pour l'une des sociétés d'audit et de remediation (mise en conformité) leader sur le marché US depuis 2002, m'à permis de me retrouver regulièrement confronté à un formidable paradoxe, un effet pervers que je peux comprendre pour la section 508, eut égard à son ancienneté, mais que je ne parviens pas du tout à comprendre pour un label comme accessiweb qui bénéfice pourtant de l'apport essentiel du WCAG 1.0.

Avant d'expliquer plus en détail mes quelques critiques, je voudrais juste faire une toute petite correction.

Le WCAG est effectivement très clair et, si il est vrai que l'attribut alt des images est obligatoire au point d'être un élément de langage dans le mode Strict de HTML/XHTML, il est absolument faux de dire que l'élément summary est obligatoire.
L'attribut summary est un des moyens alternatifs, comme l'attribut title, à utiliser pour décrire la structure d'une table si c'est pertinent, adapté et utile et si il est justifié, pour des raisons de contraintes d'ergonomie ou de design de ne pas utiliser la méthode formelle par l'utilisation de l'élement caption.

La grosse différence entre ces deux éléments le alt des images et le summary des tableaux est qu'un attribut alt vide induit une réponse logicielle, en tant qu'élement de langage, notamment en évitant à un lecteur d'écran d'annoncer l'image, alors que le logiciel se contrefout de l'attribut summary qui n'à une utilité que pour l'utilisateur final.

D'où mon immense stupéfaction en voyant cette série d'attribut summary "vide" dans les pages d'intégrance ce qui reviens à dire à l'utilisateur :" voilà une table dont je n'ai rien à vous dire...", un peut comme si on mettait "ceci est une page" en haut de toutes les pages d'un livre.

Ce premier indice m'à poussé à effectuer un pre-test de la page d'acceuil, et si je veux bien me reconnaitre d'être parfois trop exigeant, il y à des choses dans ces pages qui tendent à me faire acroire qu'on à validé pour la validation, ce qui peut se comprendre de la part de développeurs inexpérimentés mais pose de sérieuses questions sur le processus de validation des experts d'accessiweb...

Mon propos n'est absolument pas polémique, je suis juste très éttoné de voir se reproduire ici les effets pervers de la section 508 aux états unis, et de voir se développer un label qui, en tout état de cause, permets de valider à l'excellence à peut près n'importe quoi...

Quelques exemples des résultat du pré-test, qui est une procédure de mon cadre d'activité, destiné à diagnostiquer rapidement le travail à fournir et les pistes à explorer...
Je n'ai noté ici que les problèmes les plus graves..

-----
Le titre caché de la page, constitué d'une image est une double violation de la règle de base WAI AA :
3.1 When an appropriate markup language exists, use markup rather than images to convey information.
D'autres parts c'est particulièrement stupide eut égard à la simplicité des techniques de masquage de contenu adapté.

----
les listes de liens, à elles seules concentrent trois violations importantes , respectivement :

3.6 Mark up lists and list items properly (WAI AA)
Qui devrait aboutir à l'utilisation d'élements de listes UL en lieu et place de cellule de tableaux.

10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.(WAI AAA)
En effet une image n'est pas un caractère imprimable, du coup la "respiration" naturelle du rythme de lecture censé être prise en charge va être particulièrement pénible puisque le lecteur d'écran, au lieu de marquer une simple pause, va annoncer 8 fois l'image et sa description (inutilisable avec un pipe) ce qui repoduit étonamment l'effet d'une image dépourvue d'attribut alt et donc invalide. C'est d'autant plus la aussi "stupide" car je n'ai rien vu dans le design qui justifie d'une manière ou d'une autre l'utilisation d'une image de calage dans cette liste de liens.

et ensuite :
13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group. (WAI AAA) qui il est vrai est une règle avancée mais diablement bien pratique car elle aurait obligé le concepteur à utiliser un élément UL et aurait obligé à l'implémentaion d'un lien d'évitement et d'accès immédiat au contenu bienvenu dans un structure aussi compliquée (5 tables imbriquées !!)

-----
Le manque de structure sémantique, notamment au niveau des titres d'actualité est une double violation de la règle de base

3.5 Use header elements to convey document structure and use them according to specification. (WAI AA)
Car ces "titres" sont des titres (en loccurence des sous-titres) qui devraient être taggés H3.

D'autres parts on peut remarquer un effets pervers de l'architecture du layout en ce sens que la seconde actualité est implémentée dans une table de niveau inférieur à celle contenant le bloc "actualité", il n'y à donc plus de cohérence de navigation dans la structure de cette sous-rubrique identifié par le titre H2 qui se retrouve dés lors totalement inutile (puisqu'il ne structure absolument rien...)

----
L'utilisation abusive de tableaux imbriqués aboutissant à une strcture particulièrement compliquée même si elle est linéarisable.
Ce point est important car, quoiqu'on en dise c'est une violation d'une règle de BASE de niveau AA qui est rappelons le niveau "moyen-bon" :
3.3 Use style sheets to control layout and presentation.

mais aussi des règles avancées :
11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.

et

12.3 Divide large blocks of information into more manageable groups where natural and appropriate.

et encore

13.4 Use navigation mechanisms in a consistent manner.

---------
Je vous passe les autres détails qui peuvent se discuter, comme l'utilisation systématique d'image comme lien d'évitement, ce qui n'est jamais une bonne idée ou l'utilisation de retour chariot pour créer des effects visuels ce qui est toujours une mauvaise iddée.

A ce stade je suppose que vous m'aurez déjà catalogué indécrotable intégriste et ce serait une très grave erreur car l'ensemble de ces violations ne sont pas que des arguties, chacune d'elle représente une difficultée supplémentaire, créé artificiellement par le manque de formation des concepteurs, ce qui peut se comprendre mais aussi par manque de discernenement et de réflexion préalable, tant du point de vue de l'ergonomie que des techniques de codage de la part de l'expertise ayant aboutis à la validation OR.

C'est ça qui est beaucoup plus inquiétant car que vaut une certification qui valide a l'excellence une page qui ne pourrait, en toute rigueur, même pas obtenir le niveau médium "moyen-bon" du WCAG, sur lequel est fondé accessiweb et qui laisse passer au moins 6 violations graves de règles absolument basiques et ayant une influence directe sur l'expérience de l'utilisateur auquel est destiné la certification.

Et je n'est fait qu'une première approximation (un pré-test) qui tendrait à me montrer qu'avant même de tenter d'optimiser ce site il serait necessaire de réécrire une très grosse partie de la structure...

Je ne peux m'empêcher de penser que si il est effectivement possible, comme vous le dites, de produire du site XHTML/CSS innaccessible, cette expérience montre qu'il est également possible de valider a peut-près n'importe quoi (sans volonté péjorative de ma part) et je trouve ça particulièrement inquiétant s'agissant d'une sorte "d'exemple"...

JP

4. Le mercredi 8 décembre 2004 à 09:18, par Matthieu Faure :: site

Réponse courte à commentaire long

Les critères AccessiWeb sont équivalents (à trois points près) aux WCAG. Le tableau de correspondance est disponible sur http://www.accessiweb.org/fr/Label_Accessibilite/criteres_accessiweb/correspondance_wcag10/

Pour un tableau de mise en forme (pas un tableau de données), avoir un attribut summary vide est normal, autant qu'une image de décoration possède un alt vide.

5. Le mercredi 8 décembre 2004 à 12:02, par jpvilain

Ben je voudrais pas avoir l'air d'insister mais non, un attribut summary vide n'est pas normal...

D'ailleurs, le critère accessiweb parait assez clair sur ce sujet :
5.1 "L'attribut SUMMARY est-il présent et pertinent ?"
Où il faudrait expliquer la pertinence d'un attribut vide...

Donc, si ce critère est "obligatoire", ce que laisse supposer la regle 5.1, il faudrait le renseigner, par exemple en intitulant : "affichage principal ect..., ce qui n'à de sens qu'à partir du moment ou le layout par tableaux présente une logique et un cohérence, ce qui n'est malheureusement pas le cas des pages d'intégrance (cf le bloc d'actualités).
D'autres part, il n'y à absolument aucune notion d'obligation dans la règle référente des WCAG, ni même dans les annotations techniques.
Dans le cas précis, les 7 attribut summary sont inutiles en ce qu'ils ne portent aucune information...
Il en va différemment de l'attribut alt des images, qui à un statut différent puisqu'il est un élément de langage du mode Strict et induit une réponse logicielle des screen readers.
Ceci dit, en dehors de la charge de code inutile ça n'à pas de grande conséquence, c'est juste inutile ou mal renseigné...

Il est vrai que le référentiel diffère assez peut du WCAG, mais il différe sur un point, à mon sens crucial qui concerne, ce qui va recentrer le débat, la fameuse règle :
3.3 Use style sheets to control layout and presentation.

Et c'est là que mon intervention prends tout son sens...

En effet, la plupart des erreurs que j'ai relevé sont créées par l'utilisation abusive de tableaux pour construire le layout en lieu et place d'une mise en page full CSS, qui en passant serait quand même plus gérable que les 7 tables imbriquées...

Les conséquences de ce choix enchaine inévitablement les problèmes de structuration de la liste de lien et de la méthode choisie pour traiter les liens adjacents et le manque de structure sémantique formelle par exemple.

La liste de liens est symptomatique parce que rien n'interdis, évidemment, de l'utiliser dans une cellule de tableaux, simplement l'absence de la règle
3.6 Mark up lists and list items properly (WAI AA)
au moment de l'expertise n'à alerté personne sur ce problème.
Je ne doute pas que les concepteurs connaissent la balise UL, mais comment est-il possible qu'une expertise en accessibilité ne parviennes pas à les alerter sur les immenses bénéfices qui en découle pour le rendu de la page par un agent-utilisateur comme un screen-reader ?

C'est vrai que la "disparition" de cette règle de base du WCAG, peut paraitre "avantageuse" en ce qu'elle n'oblige pas un site voulant être accessible à modifier les méthodes de codage...

Par contre, l'effet pervers de cette approche est de laisser perdurer des méthodes qui, au lieu de pousser le développement et l'accessibilité vers le "haut", le nivelle par le bas.

C'est exactement ce qu'il se passe aux états-unis avec la section 508, là bas les sites "accessibles" se compte par dizaines de milliers, mais à bien y regarder on trouvera pele-mele des sites totalement invalides, sans doctype, truffés d'erreurs et, pour un cas qui me préoccupe beausoup en ce moment une réticence formidable à comprendre ce qu'est une page web de la part d'une équipe de développement en charge d'un site "fédéral" de grande importance.

D'où cet incroyable paradoxe que l'espace web le plus "accessible" en quantité est aussi le plus "innacessible" en qualité avec une manque de compétences et de formation extraordinaire.
Par exemple les équipes d'experts de la société pour laquelle je travaille sont constituées à plus de 50% d'étrangers, européens ou australiens faute de pouvoir tourver sur place les compétences nécessaires.

Bien sur le référentiel accessiweb est loin de provoquer ce même genre de "catastrophe" mais présenter comme "excellent" un résultat plutôt moyen me parait quand-même un peut fort de café et me parait comporter plusieurs risques :

- D'abord de produire une sorte d'accessibilité du pauvre, un peut comme les places de parking qui donnent accès à des escaliers infranchissables, ou les rampes d'entrée des centre commerciaux qui donnent accès à des couloirs de caisses trop étroits...
- D'autres parts cela ne peut que freiner les efforts du W3C pour la titanesque migration vers le "tout XML" et donc vers XHTML/CSS, ou HTML 4.01/CSS même si HTML est technologiquement mort et abandonné, et le developpement standard.
Et là il y à un rapport intime avec l'accessibilité car les prochaines années vont voir les équipes de développements se pencher sur les sites pour les mettre aux normes "accessibles" et c'est là une formidable occasion d'entamer cette migration en s'appuyant sur des règles comme la règle 3.3 et toutes ses conséquences pour provoquer un débat et une prise de conscience.

Avec le label OR d'accessiweb il n'y à rien qui puisse provoquer cette prise de conscience, tout au contraire les équipes de conception seront encouragées à ne rien modifier, juste à "saupoudrer" leurs pages de quelques adaptations qui, parcequ'elles s'appuieront sur de mauvaises méthodes et de mauvaises structures ne pourront que donner des résultats plutôt mauvais.

Il s'agit là d'un "décrochage", une dérive à mon sens dangereuse de la fusion qu'avait opéré le W3C entre la problématique de l'accessibilité et l'adoption de méthodes standards dont la séparation contenu/forme est pour le web le coeur du problème et, mais c'est juste un détail, le plus sure moyen de préparer un site à devenir réellement accessible.

La prochaine loi devrait donner environ 3 années de délai pour la mise en conformité des milliers de sites qui en dépendent, ne risquent on pas de perdre ces 3 années à saupoudrer du HTML 4 mal conçus pour produire des sites "obsolètes" et d'un niveau d'accessibilité "tout juste bon" dans la meilleure des hypothèses...

On se retouvera exactement dans l'état du web US qui est en train de transformer une énorme avance en retard technologique patent et un déficit de compétences très préoccupant.

Encore une fois, car je sais le sujet sensible, ce n'est pas tant la méthode (le pragmatisme) qui me soucie que le fonds qui présente "excellement" un résultat à peine moyen et créé des effets d'inerties qui ne peuvent que nourrir la stagnation technologique actuelle.

Au final tout le monde à y perdre : les publics concernés qui continueront à visiter des pages mal taillées, mal foutues, "moyennement accessible" et sans pouvoir bénéficier des outils propres aux périphériques qu'ils utilisent, les concepteurs de pages qui n'auront aucune raison d'évoluer, les utilisateurs lambda qui continueront à financer un gaspillage de bande passante éhonté et le web en général qui continuera à "ne pas évoluer".

Et ça c'est vraiment dommage...

Bon j'arrete là j'ai un rapport urgent à terminer qui consiste à expliquer à une équipe de développement que, même si leur site est validé 508 les 180 erreurs de codes "transitionnal" (!), les 15 tables imbriquées et les 40 lignes de jscript avant la balise head de la page ça fait mauvais effet et empêche même ce site "valide" d'être tout simplement lu par window-eyes... Ya des jours je vous jure...

JP

6. Le mercredi 8 décembre 2004 à 15:43, par Matthieu Faure :: site

Plus les réponses sont courtes, plus les commentaires sont longs

Nous ne parlons pas la même chose. Le Label AccessiWeb ne mesure qu'un seul et unique aspect: l'accessibilité. Le fait de savoir combien de tableaux sont utilisés ne relève pas de l'accessibilité (du moment que leur linéarisation est correcte). La "qualité" du code HTML ne figure ni dans le Référentiel AccessiWeb, ni dans les WCAG.

Permettez-moi d'insister: les CSS en particulier les CSS-P (pour le positionnement) sont loin d'être la solution absolue en matière d'accessibilité. Autant les WCAG (et le référentiel AccessiWeb) incitent à l'utilisation des CSS pour la mise en forme (gras, italique, souligné, couleurs...), autant pour le positionnement il devient périlleux de respecter les critères 10.2 ("Avec les feuilles de style désactivées, l'information est-elle toujours présente ?") et 10.3 ("Avec les feuilles de style désactivées, l'ordre d'apparition de l'information est-il respecté par rapport à l'ordre d'apparition initialement défini ?").

7. Le mercredi 8 décembre 2004 à 20:01, par jpvillain

J'ai beau essayer, je n'arrive pas à faire des réponses courtes... :)

Ca n'à aucun sens de séparer l'accessibilité de la qualité de code, ou tout du moins des choix de méthodes puisqu'il y à un rapport intime entre les méthodes et la qualité de l'accessibilité...

D'autres parts la qualité du code est une exigence du WCAG tragiquement disparue dans le référentiel braillenet :

11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.
Qui suppose que vous utilisiez les meilleurs langages donc la meilleure qualité de code.

Enfin une expertise, surtout en matière d'accessibilité où les solutions toutes faites n'existent pas, doit être particulièrement exigente sur la qualité du code qui à une influence directe sur le niveau d'accessiblité et apporter les solutions permettant de bonifier le travail initial.
A quoi bon une expertise qui se contenterait de cocher une grille d'évaluation en laissant passer de telles énormités ?

Concernant les tableaux, le nombre de tableaux, leur organisation, le nombre de cellules ont une influence directe sur l'accessiblité par la manière dont ils sont digérés et rendus par les périphériques adaptés comme les lecteurs d'écrans.

La linearisation n'assure qu'une seule chose, que les informations seront lues dans l'ordre, elle ne garantie pas la manière dont elle seront lues... , ce qui fait toute la différence...

La technique de la mise en page par tableaux est à la fois archaique, redondante et technologiquement condamnée comme l'est HTML qui est, il est toujours utile de le rappeler abandonné par le W3C depuis déjà quatre ans.
C'est exactement comme si on faisait le choix, en 2004, d'installer un windows 95 comme OS de production, vous trouveriez ça sans doute ridicule non ?
Et que penseriez vous d'une expertise qui ne trouverait rien à y redire en qualifiant ce choix d'excellent ???

J'avoue être très étonné de la remarque sur les CSS...

La regle 3.3 ne parle pas de style de caractères mais bien de layout et de présentation.

D'autre part les balises B,I,FONT,BGCOLOR ayant été supprimées, je ne vois pas comment vous pourriez faire autrement que d'utiliser CSS...

CSS pour du gras et de l'italique ??? que faites vous des balises d'emphases strong et em qui ont cet extraordinaire avantage d'induire une réponse logicielle en demandant au lecteur d'écran de modifier sa lecture afin de retranscrire l'effet d'emphase.
Dans la rubrique d'actualitré d'intégrance, il y à un effet de graisse sur les titres de chaque actualité, ce qui signifie que la conception à voulu porter un accent particulier sur ces phrases.
Le fait d'utiliser un font-weight:bold rend cet effet totalement invisible pour un utilisateur aveugle, et c'est particulièrement dommage quand il suffirait d'une balise strong pour assurer un effet identique sur les deux médias.
En loccurence d'ailleurs l'expertise aurait du recommander l'utilisation de l'élément sémantique H, tagés H3 ce qui permettrait à un utilisateur de lecteur d'écrans de disposer d'un accès direct à chaque actualité, par l'intermédiaire de la liste des titres de la page que fournis son périphérique.
Et vous reconnaitrez sans doute qu'il ne s'agit pas là d'un gros effort...

Enfin je ne vois rien dans les critères accessiweb qui recommandent d'utiliser CSS pour faire du style de caractère...

Je ne comprends pas la remarque sur les CSS car c'est pour résoudre l'inextricable problème causé par l'utilisation de tableaux, qui n'ont jamais été fait pour faire de la mise en page, que les CSS ont été créées

CSS est d'abord un langage de positionnement, c'est son but et sa finalité et ça ne date pas d'hier, ça date de 1996 :)

Quand vous faites du style de caractères avec CSS vous utilisez un peut moins de 1% des possibilités de CSS, plus exactement les deux seules familles de propriétés Font et Color, que faites vous des 99% des propriétés restantes, celles qui permettent deux choses extrèmement importantes pour l'accessibilité :

- De positionner les éléments exactement comme on le veut sans les bricolages des rowspan intempestifs et de l'imbrication épileptique de tables qui sont l'un des problèmes les plus important pour l'accessiblité...

- De pouvoir spécifier l'organisation du flux, en fonction du média ce qui résoud définitivement, avec élégance et efficacité les deux règles que vous citez...
Il est nottament possible de découpler l'organisation du flux de la page, le code, de son traitement par l'agent-utilisateur, browser, lecteur-d'écran, plage braille, pda, téléphone ou tout ce que vous voulez.

J'avoue être très perplexe car dire qu'il est périlleux d'assurer la présence et l'ordre du flux avec CSS c'est un contre-sens, avec CSS vous ne faites que ca de choisir quoi, ou, comment et pour qui...
Avec la mise en page par tableaux vous ne faites que vous arrachez les cheveux à multplier les tables dans l'unique but de satisfaire le rendu d'écran...

Mais c'est déjà un combat d'arrière garde, la mise en page par tableaux et ses conséquences sont le principal obstacle à l'accessibilité, ce n'est plus un débat et c'est le coeur de toute la normalisation, abandonner les layout par tableaux et utiliser les CSS.

Dans le projet du WAI c'est un point tellement important que les normes fusionnent les préoccupations d'accessibilité et de qualité du code en rendant inéluctable les concepts qui y sont associés notamment la séparation forme/contenu, l'utilisation des CSS et l'adoption du mode Strict.

En extrayant de ce corpus les seuls éléments concernant l'accessibilité on retarde cette échéance, on laisse perdurer des méthodes d'un autre age et au final on travaille contre les publics qu'on est censé aider, c'est ce point qui motivait mes interventions, le débat tableaux/CSS n'à aucun intérêt tant l'évidence de l'utilisation des CSS s'imposent, même si cela demande une professionalisation du développement...

JP

Ajouter un commentaire

Nom ou pseudo :

Email (facultatif) :

Site Web (facultatif) :

Commentaire :

Le code HTML dans le commentaire sera affiché comme du texte, les adresses internet seront converties automatiquement.

Se souvenir de mes informations