[avis] Checklist accessibilité

NOTE : ceci est un billet originellement posté dans le salon privé des modérateurs.
Au fil de la discussion, il s'est avéré qu'il pourrait concerner tous les membres du forum...

Hello,

J'aimerais votre avis sur un billet en brouillon :

Accessibilité : une petite checklist

Puisque les points de contrôle d'accessibilité sont parfois obscurs (peu évident de cerner leur importance, leurs bénéfices, la façon de les mettre en place), j'ai pensé reprendre rapidement et de manière très simplifiée la philosophie générale à suivre afin de faciliter l'accessibilité de son site web.

Pour commencer, je tiens à me décharger par rapport aux lecteurs : la liste suivante n'a aucune valeur officielle et ne représente en rien l'exclusivité des nombreux points de contrôles des WCAG 1.0, qui est l'actuelle version des standards.

Elle ne fait office que de "check-list", de philosophie générale à respecter afin de faciliter la vie des personnes handicapées ainsi que la nôtre en général. Elle n'est pas suffisante. C'est une sorte de point de départ minimal, pour éviter de grosses erreurs à la base.

A savoir que l'on part du postulat qu'aucun site web ne peut être 100% accessible à tous, notamment en raison de l'extrême pluralité des déficiences, de leurs contradictions, des outils employés qui emploient encore parfois leurs propres normes, etc.

Je rappelle donc que cette liste rapide n'est là que pour donner un aperçu très superficiel de la philosophie à respecter. La mise en accessibilité d'un site va bien au-delà d'une simple checklist à cocher (oui/non), mais nécessite un gros travail de professionnel expert dès la création du cahier des charges du projet, et doit s'adapter spécifiquement à chaque projet particulier.

1- Toujours prévoir une alternative à tout contenu

* les images : employer un texte alternatif (balises alt et eventuellement longdesc)
* les sons : prévoir une équivalence textuelle
* les vidéos : associer des sous-titrages ou une description textuelle
* les plugins (Flash, Java, etc.) : là encore, une alternative textuelle doit se substituer si les plugins ne sont pas installés (volontairement ou non)
* les styles de mise en forme (CSS) : le contenu doit rester cohérent et compréhensible quand les styles ne sont pas actifs

La règle générale : un document doit être parfaitement interprétable et compréhensible lorsque toutes les surcouches (styles, images, scripts, etc.) sont désactivées.

2- Toujours faciliter la compréhension du document

* les textes doivent être clairs et compréhensibles : rédigez dans un style et un langage adaptés au public, signifiez la langue du document et les changements de langue (lang), spécifiez les sigles (acronym, abbr) tout en privilégiant l'affichage complet si possible, employez l'attribut title pour apporter des informations supplémentaires aux liens qui le nécessitent (ajouter que le document à télécharger est au format PDF, son poids, etc.) il doit toujours reproduire - et non remplacer - l'information du libellé du lien avant de la compléter, attention également aux fautes d'orthographe sur certains mots qui pourraient devenir incompréhensible lors de la synthèse vocale d'un non-voyant, règle essentielle : les libellés de lien doivent être explicites hors contexte (pas de "cliquez ici")
* utilisez un balisage HTML sémantique : les balises doivent être employées selon leur fonction et non leur aspect par défaut. Ainsi, le travail de récupération et d'interprétation est largement facilité pour les outils comme les terminaux braille, les lecteurs vocaux, les moteurs de recherche, etc.
* épurer le document HTML de toutes les surcouches (styles, images, scripts, etc.) : c'est le principe de la séparation entre le contenu et la forme, qui a également de nombreux autres aspects positifs. Attention à ne pas déplacer les images de contenu dans le CSS.
* permettre l'agrandissement des contenus en employant des unités de taille fluide (% ou em).

3- Toujours faciliter la navigation dans la page et le site

* ne jamais imposer de navigation au visiteur (target), ou indiquer que sa navigation naturelle va être modifiée.
* proposer dès le début de page un "point de repère", les liens d'évitement tels que "page d'accessibilité", "aller au menu", "aller au contenu", "aller à la recherche".
* proposer diverses façons de naviguer sur le site web : plan de site, moteur de recherche interne, fil d'Ariane, liens d'évitement, retour en haut de page.
* permettre de naviguer grâce au clavier : utilisez les raccourcis-clavier (en prenant en compte leurs faiblesses). Attention aux tabindex. Leur implémentation dans une page HTML est délicate et ne doit servir qu'en dernier ressort, si le flux ne peut pas être modifié pour permettre une tabulation accessible. Généralement mal employés, ils font plus de mal que de bien.

Pour finir : toujours se baser sur un document propre et validé, pour éviter toute erreur de structure.


Merci d'avance
Modifié par Raphael (12 Feb 2006 - 12:20)

Rien à redire sur le fond, par contre sur le jargon et leur compréhension par le débutant que je suis presque (disons le Candide ):

Raphael a écrit :
La règle générale : un document doit être parfaitement interprétable et compréhensible lorsque toutes les surcouches (styles, images, scripts, etc.) sont désactivées.

Ca c'est très clair.

Raphael a écrit :
* épurer le document HTML de toutes les surcouches (styles, images, scripts, etc.) : c'est le principe de la séparation entre le contenu et la forme, qui a également de nombreux autres aspects positifs.

Ca ça l'est moins: cela signifie qu'il faut virer les surcouches du coeur du document XHTML pour les placer dans une feuille de style et un .js? Les images, ce sont celles de déco uniquement je pense?

Raphael a écrit :
* utilisez un balisage HTML sémantique : les balises doivent être employées selon leur fonction et non leur aspect par défaut.

Ca c'est pas clair du tout je pense. Un exemple ou un lien vers un exemple indiquerait immédiatement de quoi l'on cause.

Raphael a écrit :
* permettre l'agrandissement des contenus, textes et images, en employant des unités de taille fluide (% ou em).

Je propose de rajouter "exclusivement" ou bien "mais pas px" vu que px est théoriquement fluide mais qu'IE par défaut blablabla

Bonjour,

Rapidement, et en vrac :

Le plan du billet est clair, percutant et les priorités retenues sont généralement bonnes. Cependant :

- 92 = critères accessiweb, pas WCAG1.0
- les images : balise alt et éventuellement longdesc. La formulation actuelle laisse croire que longdesc peut remplacer alt.
- les styles de mise en forme (CSS) : le contenu doit rester cohérent et compréhensible quand...
- spécifiez les sigles : abbr n'est pas reconnu par IE, acronym disparaîtra en XHTML2.0. aucun des deux n'est reconnu par les lecteurs d'écran actuels, ni par les navigateurs textes, etc. Mieux vaut recommander d'indiquer la signification des sigles dans le contenu lui-même à la première occurence de ceux-ci.
- attribut title : s'il est employé, il doit toujours reproduire l'information du libellé du lien avant de la compléter. Il ne doit pas la remplacer par une information du type "format PDF - 250Ko" qui ne désigne plus la cible quand elle est hors contexte.
- ne pas oublier une règle essentielle : les libellés de lien doivent être explicites hors contexte (pas de "cliquez ici")
- les styles internes (attributs styles) n'ont aucune incidence sur l'accessibilité. Les scripts internes non plus. Et il ne faut surtout pas inciter à déplacer en CSS les images : les gens se mettent à le faire avec des images de contenu, avec perte d'information faute d'alternative textuelle. Mieux vaut que leur HTML comporte comporte des images "décoratives" et qu'ils utilisent des <img alt="">. Il y aura moins de dégâts.
- Ne pas utiliser d'unités relatives pour les images. Surtout pas. Elles font partie des éléments pour lesquels WCAG2.0 va explicitement imposer les unités fixes (px), pour éviter les affichages déformés ou défectueux.
- ne pas mentionner les tabindex. Leur implémentation dans une page HTML est délicate et ne doit servir qu'en dernoer ressort, si le flux ne peut pas être modifié pour permettre une tabulation accessible. Généralement mal employés, ils font plus de mal que de bien.

J'ajouterais peut-être, mais c'est délicat à expliquer rapidement :
- plutôt que des astuces CSS complexes, en cas de difficulté à gérer les bugs ou les implémentations dans les différents navigateurs, renoncer à l'effet de présentation concerné, ou utiliser une solution HTML (tableau simple, image <img>) si elle existe. CSS mal employé crée très facilement de l'inaccessibilité.
- ne pas utiliser de div scrollables, ou de page figées en hauteur (100% de la fenêtre d'affichage).
- ne pas utiliser les dernières techniques à la mode du Web2.0 sans précautions en raison de leur inaccessibilité fréquente.

Et j'ajouterai également, impitoyablement : ne pas utiliser de menus déroulants (CSS et/ou javascript).
Modifié par Laurent Denis (30 Nov 2005 - 08:08)

Bonjour à toutes et tous

A propos d'accessibilité, j'avais une autre idée en tête, mais je ne sais pas si cette idée peut être intégrée à ce billet ou même si elle pourrait faire l'objet d'un billet publié sur Alsa.

Plutôt qu'un unième billet sur l'accessibilité, je verrais plus un billet sur l'inaccessibilité... Je m'explique :

Tous les discours qu'on entend ou qu'on lit aujourd'hui laissent penser que les sites qui ne mettent pas en place les principes d'accessibilité sont d'office inaccessibles. Je pense que cette "notion" faussement et involontairement véhiculée n'est pas forcément une bonne chose. Ainsi, une personne qui désire procéder par étape, pourrait commencer par remplacer ce qui n'est pas accessible pour ensuite mettre en place les "conforts" d'accessibilité.

Je ne sais pas si mon propos est très clair, en d'autres termes, on a :
- le noir et le blanc
- le nuit et le jour
- le bien et le mal (beurk mais bon, soyons tolérant )

Dans un autre domaine on a le vide et le non-vide qui n'est pas en opposition comme le serait le plein. C'est dans cette idée qu'on pourrait avoir : l'accessible - le non-accessible - l'inaccessible.

En gros, lister déjà ce qui peut rendre un site inaccessible, faire un point sur les idées reçues sur les frames, les tableaux, etc..

Qu'en pensez-vous ?

Je ne suis pas sûr de bien saisir l'idée, Dominique, mais il me semble que cela reviendrait en fait :
- à rappeler que WCAG distingue 3 niveaux de priorités d'accessibilité (et les limites du A)
- à inviter à traiter à traiter progressivement l'accessibilité d'un site, du A au AA, puis au AAA
- à enfoncer le clou sur les facteurs d'inaccessibilité correspondant au niveau A (générer un flux HTML brut accessible, équivalence textuelle des contenus multimédia, etc.)

Ce serait évidemment plus utile que d'orienter vers les accesskeys, tabindex et autres...
Modifié par Laurent Denis (30 Nov 2005 - 10:01)

Arffff ! J'me doutais que je ne serais pas très clair sur cette idée...

Je pense qu'on a tendance à conclure trop vite, par opposition, qu'un site qui n'est pas "accessible" est inaccessible. On le voit d'ailleurs dans certaines remarques ou "dénonciations". On parle plus, à mon avis, d'accessibilité sans vraiment parler d'inaccessibilité, ce serait peut être bien de faire un point là dessus, non ?

Par exemple, l'absence de "alt" ne rend pas forcément un site inaccessible... pourtant, ça n'est pas "aux normes de l'accessibilité"... Donc faire la part des choses permettrait de fixer, en quelques sorte des priorités sur ce qui est plus urgent de faire en fonction du site pour qu'il soit un peu plus accessible.

Dans un autre ordre d'idée, on lit souvent : "Faut surtout pas utiliser de frames, c'est pas accessible" ... Qu'en est-il réellement ?

Hummmmm ! J'ai vraiment du mal à être clair.

En fait j'aurais dû expliquer ma démarche avant de proposer ce billet : je viens de rentrer d'un séminaire de 2 jours consacré à l'accessibilité web et où j'ai pu assister en tant qu'observateur-intervenant.

Le séminaire était bien fichu, mais il s'est trouvé qu'à la fin, tous les participants m'ont fait part de leur regret qu'il y'ait autant de règles à connaitre, qu'elles leur paraissaient encore floues et surtout, dans ce flot de recommandations, comment arriver à résumer très vite pour convaincre d'autres personnes (les "élèves" étaient plus des décideurs que des techiciens).

Ils m'ont donc fait part de ce qu'ils aimeraient avoir, c'est à dire une sorte de philosophie générale à suivre... d'où ce billet.

Laurent Denis a écrit :
- Ne pas utiliser d'unités relatives pour les images. Surtout pas. Elles font partie des éléments pour lesquels WCAG2.0 va explicitement imposer les unités fixes (px), pour éviter les affichages déformés ou défectueux.

Preuve que l'accessibilité est vraiment au cas par cas : l'un des participants, mal voyant et utilisant une loupe, prône le navigateur Opera car il permet de faire un vrai zoom (images comprises) ce qui lui facilite énormément les choses lorsqu'il n'est pas sur son poste.
Tu vas me dire que Opera va zoomer même si les images sont en px, mais le discours de cette personne était vraiment convaincant sur l'intérêt (pour lui) de pouvoir agrandir les images.

dominique a écrit :
Dans un autre ordre d'idée, on lit souvent : "Faut surtout pas utiliser de frames, c'est pas accessible" ... Qu'en est-il réellement ?

Une étudiante aveugle (pas du tout technicienne) nous a fait une jolie démonstration, revenant sur certains a-prioris tenaces.
Au sujet des frames, elle a clairement fait comprendre qu'elle trouvait les cadres... très pratiques !
Ils lui permettent de se repérer beaucoup plus facilement que d'autres méthodes : elle peut ainsi passer de la page "menu" à la page "contenu" le plus facilement du monde. En fait, pour elle, cela est aussi pratique qu'un lien d'évitement en début de page.
Cela implique évidemment (elle a fait un test désastreux sur un autre site à frames) que :
- les frames ne soient pas nombreuses (3-4 au grand maximum)
- les frames soient très structurés : en fait chaque frame doit être une partie distincte fonctionnelle (menu, contenu)
- les frames doivent être nommées très clairement (surtout s'il y'en a plus de 2-3)

J'aime bien le débat qu'ouvre ce "énième" billet sur l'Accessibilité.
Par contre, je le répète, l'objectif est ici plus "philosophique" que technique : je voudrais éviter justement de devoir aller dans des considérations (abbr/acronym parce que bla bla), bref, je voudrais aller au-delà des différentes subtilités des versions WCAG ou des navigateurs, pour rester dans le fond du sujet.

Le débat reste ouvert...
Modifié par Raphael (30 Nov 2005 - 11:38)

Raphael a écrit :
Preuve que l'accessibilité est vraiment au cas par cas : l'un des participants, mal voyant et utilisant une loupe, prône le navigateur Opera car il permet de faire un vrai zoom (images comprises) ce qui lui facilite énormément les choses lorsqu'il n'est pas sur son poste.

Cela n'a rien à voir, Raphaël :
- dans un cas, c'est l'utilisateur qui a la possibilité de zoomer une image grâce à un outil adapté à ses besoins propres, avec le facteur de son choix, et via un interface qu'il maîtrise
- dans l'autre, c'est la feuille de style qui va lui imposer un agrandissement ou une réduction a priori des dimensions de l'image. Avec un résultat imprévisible selon les configurations utilisateurs et une dégradation éventuelle que ne pourront pas corriger les utilisateurs d'IE, par exemple.

Concrètement : que va faire l'utilisateur d'IE mal-voyant face à un titre mis en image ou à un logo dimensionné relativement, agrandi et flou ? Ou réduit par sa configuration et trop petit pour être lisible ?

Lorsque j'utilise Opera, il m'arrive fréquemment de recourir à un JS user qui améliore encore le zoom graphique de ce navigateur, et qui me permet de zoomer sur une image précise sans modifier la mise en page. Tout simplement parce que la crise de la quarantaine frappe très fort, et que j'ai horreur de mettre ces maudites lunettes pour lire. Mais contente-toi de me donner une image nette pour qui a 10/10 aux deux yeux, et laisse-moi zoomer à ma guise dans Opera ou mettre mes lunettes quand je navigue avec IE

Raphael a écrit :
je voudrais aller au-delà des différentes subtilités des versions WCAG ou des navigateurs, pour rester dans le fond du sujet.

Pour rester au niveau philosophique : le principe de base à ne jamais oublier est de donner à l'utilisateur et à ses outils le maximum de liberté pour adapter à leurs besoins et à leur initiative le résultat par défaut normalisé. Pas de tenter d'anticiper tel cas de figure et tel besoin spécifique, au risque de gêner d'autres utilisateurs.

Ton utilisateur d'Opera ne fait que prôner, pour son cas, l'outil utilisateur qui lui convient. Il ne te demande pas de gérer son besoin à sa place ! Et si jamais il le faisait, il ne faudrait pas accepter, car l'accessibilité vue comme l'accumulation de réponses à des besoins spécifiques n'aboutit qu'à des contradictions
Modifié par Laurent Denis (30 Nov 2005 - 12:46)

Pour répondre à Dominique, et plus généralement sur cette idée de "critères d'accessibilité" :

Il faut, dans les circonstances actuelles, être prudent sur tout ce qui, de près ou de loin, suggèrerait aux professionnels du Web un "minima d'accessibilité" en deça de WCAG, ou décalé par rapport à celui-ci.

Ce contexte, c'est celui de la loi sur l'accessibilité numérique et du référentiel à venir de l'ADAE pour son application.

Comme Jean-Pierre et moi-même l'avons plusieurs fois souligné, il y a, au sein des intervenants officiels dans l'élaboration de ce référentiel, des partisans d'un référentiel réduit aux seuls critères d'accessibilité automatiquement et formellement validables et d'une accessibilité des sites publics qui se fierait (presque ?) exclusivement aux automatismes de la chaîne de production du contenu Web. Le résultat serait une section 508 à la française, et une accessibilité réelle de façade.

(sur le fond, ceux qui s'opposent à cette démarche ne refusent évidemment pas les automatismes, mais sont simplement conscients qu'ils doivent être intégrés dans un processus plus complet, qui tient compte du facteur et de l'expertise humaine).

Or, il y a aujourd'hui de plus en plus de raisons de craindre que cette démarche réductrice de l'accessibilité soit celle retenue par l'ADAE. Si c'est le cas, il faut bien comprendre que tous les sites, publics et privés, seront impactés : un prestataire de service réalisant un site privé ne va pas manquer d'exploiter, sans doute en toute bonne foi, le référentiel récent et officiel de l'Etat, qui lui permettra de réaliser de substantielles économies, notamment en formation de son personnel, en se bornant à l'automatisable.

Il va donc falloir peut-être faire face durant les deux ou trois ans à venir à un net recul de la qualité des incitations à l'accessibilité. Dans ce contexte, inutile de susciter le doute sur les WCAG.

Vous me connaissez: il m'arrive d'être un peu prolixe

Dominique : ma première réponse à ton message était :

Hum... En gros, tu chercherais à distinguer :
- ce qui serait obstructif et qui interdirait à l'utilisateur de percevoir le contenu ou d'utiliser le service.
- ce qui serait gênant, pénible, mais qui n'interdirait pas totalement la perception du contenu ou l'utilisation d'un service.

Avec l'idée sous-jacente que les normes d'accessibilité ne feraient pas cette différence et considèreraient des "gênes" comme étant obstructives...

Si c'est le cas, cela me semble assez risqué. Tu cites le cas de l'absence d'attribut alt :
- une icône de navigation sans attribut alt serait obstructive (intitulé de lien dénué de sens)
- une image sans rôle fonctionnel, non indispensable au sens global de la page, et sans attribut alt ne serait qu'une gêne (le lecteur d'écran va lire le src de l'image, un navigateur texte va afficher un terme par défaut, etc.). La corriger ne serait pas une priorité.

Le problème quand on va émettre des recommandations ou définir des bonnes pratiques, etc., ce sont des questions comme :
- l'utilisateur de la recommandation pourra-t-il décider aisément quelle image entre dans quelle catégorie ?
- pourra-t-il décider aisément jusqu'à quel point la répétition d'images sans alt sera gênante ou rendra la lecture ou l'audition tellement confuse qu'elle devient obstructive ?

Comment permettre à l'utilisateur du tutoriel de trancher avec certitude ou avec facilité ? Comment assurer la vérificabilité du critère ?

Il est parfois (souvent) nécessaire d'émettre des recommandations laissant leurs utilisateurs face à leurs responsabilités. Mais il est également nécessaire d'éviter les prises de décision sans assurance. C'est pourquoi WCAG1.0 ne fait aucune distinction en matière d'images.

Et en fait, on pourrais aussi dire que ce "tri" du plus ou moins obstructif a déjà été fait par WCAG : c'est l'une des fonctions des 3 niveaux d'inaccessibilité. Ce qui relève du niveau A est potentiellement obstructif. Ce qui s'ajoute au niveau AA est obstructif/gênant pour un public plus réduit. Le niveau AAA vise un public encore plus spécifique, et un degré de gêne moins grave.

Laurent Denis a écrit :
Hum... En gros, tu chercherais à distinguer :
- ce qui serait obstructif et qui interdirait à l'utilisateur de percevoir le contenu ou d'utiliser le service.
- ce qui serait gênant, pénible, mais qui n'interdirait pas totalement la perception du contenu ou l'utilisation d'un service.

Avec l'idée sous-jacente que les normes d'accessibilité ne feraient pas cette différence et considèreraient des "gênes" comme étant obstructives...

Je me suis également déjà fait cette réflexion et c'est vrai qu'elle m'a aussi été faite par les participants au séminaires :
- "en fait, qu'est-ce qui est vraiment handicapant ? Qu'est-ce qui est *seulement* gênant ? Qu'est-ce qui est de l'ordre du confort ?"

Tu y réponds en partie, Laurent, mais un billet qui donnerait un réponse claire à ces 3 questions serait un extraordinaire outil de vulgarisation de l'accessibilité... même s'il semblerait que la question est coriace.

J'en reviens à mon billet premier qui lui aussi se voudrait une tentative de vulgarisation à l'usage des "décideurs un peu techniciens" ou des "débutants".
- Est-ce que celui-ci mérite-t-il sa place (avec quelques rectifications) ?
- Peut-on vulgariser l'accessibilité rapidement, sans entrer dans les détails des recommandations ou des implémentations de balises précises (abbr/acronym) ?

Si la réponse est oui, il reste une double alternative :
- je publie mon billet (modifié) de vulgarisation "philosophique" de l'accessibilité web
- on publie un double billet, en intégrant l'idée de Dominique si celle-ci est exploitable

L'essentiel est, je le rappelle, de proposer un langage très clair et compréhensible par des personnes non techniciennes (pas comme nous par exemple).

Qu'en dites-vous ?
Modifié par Raphael (30 Nov 2005 - 13:49)

Heuuuuuuuu !

En fait, ce qui me gêne, c'est qu'un site puisse être soupçonné d'inaccessibilité sous prétexte qu'il ne suit pas les règles d'accessibilité, ce qui est, à mon avis, une erreur.

Bien entendu, je ne cherche pas à minimiser l'utilité des règles d'accessibilité, ni à influencer vers une démarche médiocre (que je n'ai pas l'intention de suivre).

J'ai assisté à la présentation de l'accessibilité de la spipféria. Ce qui ressort du discours, mais ailleurs aussi, c'est le sentiment qu'un site n'est accessible que s'il respecte strictement les règles... sinon (mais c'est laissé en sous-entendu) le site est inaccessible.

Et là, je ne suis pas d'accord, l'accessibilité ou l'inaccessibilité, ce n'est pas ou tout noir ou tout blanc. Un non voyant, par exemple, même s'il éprouve des difficultés pourra quand même accéder à certains sites qui ne respectent pas le référentiel.

Mon propos n'est pas purement technique là, comprends-tu ?
Modifié par dominique (30 Nov 2005 - 14:14)

dominique a écrit :
Et là, je ne suis pas d'accord, l'accessibilité ou l'inaccessibilité, ce n'est pas ou tout noir ou tout blanc. Un non voyant, par exemple, même s'il éprouve des difficultés pourra quand même accéder à certains sites qui ne respectent pas le référentiel.

Comment faire pour toucher du doigt le problème ? (Jean-Pierre: Help ! )

Comment ton site accessible à un non-voyant sans respecter WCAG va-t-il gérer les demandes d'accessibilité des handicapés moteurs ? des daltoniens avec leurs différents mode de daltonisme ? des seniors tremblotants de la souris ? des novices du web ? des oublieux pathologiques de ce que disait la page d'avant ? des loupeux (utilisateurs de loupe) ?

En répondant spécifiquement à chaque demande avec la complexité que ça suppose ? Et en résolvant les inévitables contradictions entre elles ?

L'accessibilité n'est pas tout noir ou tout blanc, en effet. Mais la mise en oeuvre de l'accessibilité exige une normalisation qui définit le blanc commun à tous, pour être tout simplement réalisable.

En d'autres termes : un site peut être effectivement accessible sans suivre les règles d'accessibilité. Mais la gestion de son accessibilité sera effroyablement coûteuse avec toutes chances de finir dans une impasse. Une norme ne sert qu'à gérer les coûts et la faisabilité, finalement. l'interopérabilité entre les handicaps, si on veut.

Si tu cherches un approche par la non accessibilité de fait, tu vas te perdre dans la multitude des cas particuliers. Un certain niveau (élevé en fait) d'abstraction est nécessaire.
Modifié par Laurent Denis (30 Nov 2005 - 16:09)

Bonjour à toutes et tous

Bon ! Oubliez ce que j'ai écrit, je n'arrive pas à expliquer clairement ma pensée... Peut être des effluves de la féria-spip

Du coup, ça ressemble plus à un troll qu'à un véritable échange, désolé pour la pollution Raphael ... Mais merci d'avoir essayé Laurent

Non, Dominique : ton intervention est au contraire très intéressante. Elle met bien en évidence un des problèmes de l'accessibilité qui n'est sans doute pas assez expliqué : rendre un site acessible ne consiste pas à répondre à chaque besoin, à lever chaque obstacle, ou à lever des obstacles prioritaires. Elle consiste à permettre à chaque utilisateur d'assumer son besoin dans un cadre qui permette aux auteurs de décider vite et bien.
Modifié par Laurent Denis (01 Dec 2005 - 12:22)

Bonjour a tous,

Ben zut alors, y suffit que je m'absente pour que des choses formidablement intéressantes se passe, rezut !

Juste pour vous dire que je prends le temps de lire tout ça et d'y apporter ma modeste contribution.

En attendant, petite réaction à chaud de mon retour, pour alimenter les pistes de ce fil en espérant ne pas trop le pertuber

Je suis en train de suivre la formation accessiweb et j'ai donc été confronté aux réactions des stagiaires présents qui viennent exactement croiser les excellentes remarques de tout le monde sur ce fil...

Il y à une évidence que nous autres "praticiens" avons du mal à expliquer, c'est à la fois une idée simple à comprendre et formidablement compliquée à "intégrer" :

a écrit :
rendre un site acessible ne consiste pas à répondre à chaque besoin

C'est la base, le fondement, la pierre philosophale : avant toute autre considération il faut comprendre et expliquer que l'accessibilité du web ne s'adresse pas à des "handicaps".

Si cette voie avait été choisie alors on aurait développé des techniques consistant à servir des contenus "différents" et adaptés à chaque cas et on se seraient cassé le nez.

Lors de ces trois premières journées de formation, je me suis rendu compte d'un formidable paradoxe : Plus on explique comment un utilisateur handicapé utilise internet, plus on cristallise le sentiment que l'on va apprendre à répondre à des besoins particuliers, et cette idée est très délicate même si elle est évidemment vraie.

A la limite, je dirais au risque de choquer, que la clé serait de faire comprendre que cette idée est "sans importance" ou que c'est juste une "conséquence" et absolument pas un "objectif".

La première réaction des stagiaires "novices" de cette session à été de définir (en feedback de la démo de l'utilisation d'un lecteur d'écran) l'accessibilité comme une "collection" de moyens destinés à "adapter" du contenu à des "utilisateurs particuliers".

Formidable paradoxe puisque l'essentiel de la démonstration était de montrer que cet "utilisateur particulier" avait les outils et les moyens d'être un "utilisateur lambda" à la simple condition que le contenu se prête à une "consultation normale".

Je sais pas mieux dire pour le moment mais je sais qu'il y à quelque chose à creuser là dedans, dans le fait que, même si implémenter une description alternatives aux images est effectivement une "adaptation", l'objectif n'est pas "d'adapter" le contenu ou la consultation mais de le (la) rendre "normalement utilisable".

Idée que l'on va retrouver dans un autre paradoxe : Il à fallu que la formatrice, aidé d'un intervenant passe beaucoup de temps à expliquer la notion de "texte alternatif aux images" (c'est un phénomène que l'on voit bien dans alsa aussi) alors que la notion de "titrage du contenu" à été avalée en deux minutes.

Mais, vous savez bien tous, que titrer un contenu (dans le sens de le structurer avec des titres) est tout aussi "compliqué", la seule différence c'est qu'on envisage la description alternative sous le seul aspect de la "réponse circonstancielle" à un besoin, alors que le titrage est vécu comme une "évidence".

Il faut travailler la dessus, comment produire une pédagogie qui sorte l'apprenant de cette idée qu'on "adapte" alors qu'on va juste essayer de rendre "normal".

Je n'ai pas encore eu le temps (je rentre tout juste) d'approfondir ce fil, en revanche il à fait écho à une chose également importante et dont je me suis rendu compte lors de cette session :

Il faut essayer d'expliquer que les niveaux de priorités A-AAA sont un leurre nécessaire, sentiment que l'on va retrouver confusément chez tous les praticiens, après un certain temps d'expérience.

Il y à eu un moment très symptomatique tout à la fin de la session : un des stagiaires particulièrement "imprégné" de l'idée de "l'adapatation des contenus" à lancé "donc, au final, si on est niveau A on à rendu son site au minimum accessible" et la formatrice c'est exclamé avec une franche spontanéité "Ha mais non, je n'ai jamais dit ça." et c'était vrai elle ne l'avait jamais dit, c'est la phase d'apprentissage technique (comment faire) qui produisait d'elle-même cette fausse idée en occultant le "pourquoi le faire" pour reprendre le gimmick de Laurent qui est une autre idée "fondamentale" de l'accessibilité.

La hiérarchie A-AAA ou Bronze-Or dans accessiweb est tout aussi délicate que l'idée de "l'adaptation des contenus" car elle génère par le même procédé le réflexe que chaque niveau est représentatif de son accessibilité, ce qui est pour le coup absolument faux.

On est en fait plutot dans un système imbriqué où il est techniquement nécessaire de satisfaire au niveau A si on veut implémenter des recommendations de niveau AA, c'est le seul rôle de ces foutus niveaux, mais en faisant ça on à, à priori, aucune garantie que le contenu est réellement accessible, on à juste une bonne raison de croire qu'il peut l'être, rien de plus.

Il faut travailler sur une autre manière d'expliquer ça quelque chose qui ressemblerait à "garantir l'accès au contenu et à tous les contenus", "faciliter l'utilisation" et "Optimiser l'usage" pour reprendre la thématique en trois niveaux, qui est reprise mais de façon très informelle par le cursus de cette formation et que je "sens" dans le projet de billet de raphael.

L'idée étant que, fonction du contenu et de la réalité du site et de sa production, l'un ou l'autre de ces aspect nécessite l'utilisation de tout ou partie des recommandations des niveaux de priorités du WCAG, isoléments ou en les mélangeants.

Toutes ces remarques, à bien y réfléchir n'ont rien de nouveaux, c'est ce qui transparait constamment de la parole de Laurent "monsieur bons mots au bon moment" ou de l'idée "pas claire" mais très pertinente de dominique :

a écrit :
En fait, ce qui me gêne, c'est qu'un site puisse être soupçonné d'inaccessibilité sous prétexte qu'il ne suit pas les règles d'accessibilité, ce qui est, à mon avis, une erreur.

C'est très juste, on peut trouver des sites accessibles qui ne respectent pas toutes les règles d'accessibilité, voire aucune, avec des frames, des tableaux et de la soupe de tags.

En revanche, on ne peut que supposer que ces sites "restent accessibles" dans le temps et en toutes circonstances, alors qu'avec le support de WCAG on créé les conditions les plus favorables pour qu'ils le restent, ce qui fait toute la différence.


Bon c'est encore un peut brouillon tout ça, je vous ai livré ça "à chaud", je vais prendre le temps de relire ce fil et je compte sur vous et "monsieur bon mots au bon moments" pour voir si on peut tirer quelque chose de ce genre d'angle de vue pour alimenter le débat, le projet de billet de raphael ou ce que nous voudrons bien en faire....

Jean-pierre
Modifié par jpv (04 Dec 2005 - 05:50)

Bonjour,

Il est en effet très difficile, mais nécessaire, d'expliquer qu'il faut, d'une certaine manière, commencer par oublier les utilisateurs handicapés pour faire de l'accessibilité.

On peut faire le parallèle suivant :

- pour que les contenus HTML puissent être rendus sur de multiples médias, pour qu'ils puissent évoluer et durer au fil des nouveaux besoins et des nouvelles possibilités, on a compris depuis longtemps qu'il fallait les séparer de leurs données de présentation. C'est à dire qu'il faut que le (X)HTML devienne un format plus abstrait, qui ne préjuge pas des utilisations qui en seront faites, qu'il s'agisse de l'afficher, de le lire, de l'imprimer, de le transformer, de l'indexer, etc. De cette manière, chacune des machines qui assumera l'une ou l'autre de ces fonctions disposera d'un contenu "standard" exploitable au mieux de ses capacités, sans l'impossible gestion de multiples contenus spécifiques et dénués d'interopérabilité.

- de la même manière, pour atteindre ses objectifs d'universalité et de pérennité, l'accessibilité a dû renoncer à se définir comme une somme sans fin de réponses à des handicaps particuliers. Tout comme le XHTML2.0 est un format plus abstrait que le HTML3.01, WCAG2.0 sera plus abstraite que WCAG1.0. On lui en fait déjà le reproche (et ce n'est pas fini), mais c'est en fait sa principale qualité.

Comme le HTML, pour atteindre ses objectifs, l'accessibilité ne devrait pas viser l'utilisation "humaine" qui sera faite du contenu. Elle s'adresse en fait elle aussi à des machines et s'assure que le contenu est formatté de manière à permettre son exploitation "normale" par celles-ci. A charge pour chaque machine de répondre à partir de là aux besoins spécifiques de son utilisateur.

En résumé : tout comme la structure HTML ne préjuge pas de ses utilisations, l'accessibilité ne préjuge pas du handicap.

Là où le bât blesse, cependant, c'est inévitablement dans les questions d'implémentations et d'état actuel des formats : pour l'instant, il arrive que telle ou telle machine n'assume pas comme prévu sa fonction quand on lui fournit ce contenu "standard". Ou bien il arrive également, à l'inverse, que le standard en question ne soit pas encore défini. Par exemple :

- les liens longdesc ont longtemps tardés à être implémentés par les lecteurs d'écran (et ne le sont d'ailleurs que partiellement) : une réponse spécifique a dû être improvisée (le lien "D"). Ce lien assez ésotérique placé à côté des images déroutait en fait de nombreux utilisateurs, handicapés ou non, et contredisait d'autres objectifs d'accessibilité. La réponse spécifique n'était qu'une demi-réponse très insatisfaisante, un "faute de mieux" discutable.

- les menus déroulants et les interfaces enrichis de widgets bricolés via CSS et javascript ne font pas encore l'objet d'une normalisation via un format adapté. Faute de cela, on ne peut implémenter dans les navigateurs des mécanismes gérant leur accessibilité efficacement et à un coût acceptable. On se retrouve donc, là encore, à recourir à des versions alternatives, à des adaptations et des prises en compte spécifiques de tel ou tel handicap, quand c'est possible. Pour limiter la casse.

- Plus parlant, peut-être : les menus de navigation eux-mêmes, quelque-soit leur aspect. Ils posent un problème d'accessibilité évident car, à l'heure actuelle, on ne dispose d'aucun moyen universel pour les formatter de manière à les signaler et les rendre exploitables comme tel aux différentes machines. La navigation dans le site et le contenu de chaque page sont structurées de manière indifférenciée, et ne permettent pas aux applications de repérer, de manipuler et de rendre accessible la navigation à coup sûr. Des possibilités théoriques existent (les link rel), mais ne sont ni implémentées ni définies de manière suffisantes. Résultat : nos liens d'accès directs à la navigation et au contenu, les interminables controverses sur "la navigation en premier versus le contenu en premier", sur les liens d'évitements, sur les listes et les titres ou les <dl>, etc. Avec constamment la référence à telle ou telle situation de handicap spécifique, des contradictions, des dilemnes insolubles... Faute de pouvoir abstraire la navigation du contenu propre de la page, on ne peut abstraire son accessibilité et la gérer efficacement.

Ces limites des implémentations et des normes introduisent évidemment beaucoup de confusion et de frustration, pas nécessairement conscientes. Les "patchs" temporairement nécessaires pour l'accessibilité et les "check-lists" de remédiation prennent rapidement le dessus sur la démarche globale, dans l'esprit de beaucoup de gens, parce qu'ils sont plus immédiats, plus faciles à appréhender, et qu'ils fournissent des réponses réconfortantes. Il n'y a pas lieu d'en faire le reproche aux gens. Mais il faut effectivement réfléchir à la manière de leur en faire prendre conscience.

Tiens, une dernière comparaison dominicale : les hacks CSS relèvent exactement de la même problématique pour ce qui est de la nécessaire volatilité des designs
Modifié par Laurent Denis (04 Dec 2005 - 09:06)

a écrit :
d'une certaine manière, commencer par oublier les utilisateurs handicapés pour faire de l'accessibilité.

Ce qui se rapproche d'une autre règle d'or qui est de ne jamais supposer la manière dont un utilisateur va s'appropier le contenu au profit du seul objectif de lui donner tous les moyens nécessaire pour qu'il se l'approprie à sa guise et selon les possibilités de son outil, handicap ou pas...

a écrit :
Une étudiante aveugle (pas du tout technicienne) nous a fait une jolie démonstration, revenant sur certains a-prioris tenaces.
Au sujet des frames, elle a clairement fait comprendre qu'elle trouvait les cadres... très pratiques !

Situation amusante que cette histoire de frames : imaginons que les trois frames en question aient des tailles ridicules, les handicapés ne seraient plus ceux qu'on croient mais bien les utlisateurs normaux obligés de scroller...

Du coup ce témoignage n'est rien d'autre que la simple expression d'une préférence, rien de plus.

a écrit :
... l'accessibilité ne préjuge pas du handicap.

C'est vrai pour les problématiques associées aux concepts d'accès aux contenus, ça deviens plus compliqué à apréhender dés lors qu'on commence à implémenter des dispositifs à visée plus ergonomiques.

C'est à ce moment là que ce message "premier" se brouille parce que le choix d'une description alternative d'image ou l'implémentation d'aide à la navigation sont déjà des processus hybrides entre la mise à disposition d'un contenu et son ergonomie, on reste dans la problématique universelle "d'accès à tous" mais "particulier à certains".

On le vois bien dans le projet de billet, la première partie concentrée sur l'accès universel est claire, compréhensible, facile à apréhender, et plus on avance dans la liste plus on voit apparaitre des dispositions particulières.

Et fatalement on choisis d'aller vers le plus simple : la liste habituelle qui débute avec les alt des images et se termine avec les aides à la navigation.

Peut-être serait-il tout aussi intéressant de casser cet enchainement et de marquer une séparation plus nette entre ce qui relève de l'accès "premier" aux contenus (l'accessibilité) auquel viennent s'ajouter des dispositifs "essentiels" d'ergonomie et d'utilisabilité.

Pour reprendre le questionnement de raphael (sur un exemple facile : les liens textuels ) :

L'accessibilité :
Qu'est ce qui est vraiment handicapant : des liens incompréhensibles hors contexte.

L'ergonomie :
Qu'est ce qui est simplement génant : des titles insufisants ou ambigus.

La qualité :
Quest-ce qui relève du confort : l'absence de title au profit de liens textes contextualisés.

En essayant de généraliser aux thèmes...

Histoire d'opquaster un peut le billet...

Jean-pierre
Modifié par jpv (06 Dec 2005 - 01:51)

Eh bien, le débat est vraiment très intéressant (presque dommage de le limiter aux seuls modérateurs du forum).
Par contre, on a ouvert plusieurs voies différentes par rapport à l'idée de départ et je ne sais plus trop quoi penser.
Je pense que l'idée (restreinte) de départ est un peu inutile, mais parmi toutes les pistes soulevées, peut-on (doit-on ?) formaliser ça dans un ou plusieurs billets de blog ?

Jean-Pierre ou Laurent, vous avez des idées pour synthétiser tout ça ?

Personnellement, je basculerais directement ce fil de discussion dans la partie publique du forum, avec un message initial explicatif.

Cela dit, on peut envisager un billet sur "Accessibilité Web : commencez par oublier les handicaps". Jean-Pierre, ça te dit ?

(Pour l'articulation accessibilité/ergonomie), va falloir qu'on cause. Parce que ça n'est pas évident du tout )
Modifié par Laurent Denis (06 Dec 2005 - 10:27)