0
L. Denis : "Les standards web forment un socle sur lequel peut se construire une démarche qualitative de contenu, design, navigation, centrée sur l'utilisateur".
AB - Bonjour Laurent Denis. Formateur, blogueur, vous faites de l'accessibilité web une priorité. Quel est votre rôle au sein des communautés Opquast.org et OpenWeb.eu.org ?
LD - Bonjour. Je suis consultant associé pour Temesis, société de formation et de conseil spécialisée sur la qualité, la conformité, et l'accessibilité des sites Internet et Intranet (http://temesis.com).
C'est à ce titre que j'interviens dans le projet Opquast de référentiel "Qualité des services en ligne" initié et dirigé par Elie Sloïm.
Les bonnes pratiques de ce référentiel intègrent les problématiques de conformité, d'accessibilité et d'ergonomie dans une démarche globale de suivi qualité.
Via le site de l'atelier Opquast (http://opquast.org), dont je suis responsable, elles sont élaborées en tant que projet libre, par une communauté ouverte à tous les acteurs du Web : Décideurs, développeurs, utilisateurs.
Leur suivi d'application peut être fait à l'aide d'outils spécifiques, élaborés par Temesis et proposés sur le site Opquast.com (http://mon-opquast.com).
D'autre part, au sein du collectif OpenWeb, qui contribue depuis 2002 à la diffusion des standards Web auprès des décideurs et des développeurs, j'interviens comme rédacteur en chef aux côtés de Tristan Nitot (http://standblog.org) et de Fabrice Bonny, ainsi que comme auteur d'articles, essentiellement sur l'accessibilité et sur les techniques CSS.
AB - A la suite de la publication d'un article dans nos colonnes*, vous avez parlé de "confusions concernant les enjeux de la validité HTML et de la notion d'accessibilité". Pouvez-vous préciser votre pensée ?
LD - La confusion la plus fréquente porte sur l'équation erronée "validité = accessibilité". La validité du code HTML et CSS est effectivement l'un des critères minimaux requis pour l'accessibilité d'un site. Mais ce critère ne fait qu'assurer que ces formats sont correctement utilisés du point de vue syntaxique.
A titre d'exemple, la validité HTML ou XHTML va exiger que chaque élément image de vos pages soit doté de l'attribut servant à lui donner une alternative textuelle (elle sera exploitée en particulier par les lecteurs d'écran qui donneront ainsi une information équivalente à cette image).
Pour être valide, il suffit que l'attribut soit présent, quel que soit son contenu. Le travail d'accessibilité n'est donc pas encore fait, puisqu'il reste à renseigner tous ces attributs de manière pertinente : une page valide n'aura peut-être aucun sens dans un lecteur d'écran si ces informations ne sont pas les bonnes.
La validité n'est donc qu'un outil, indispensable, mais au rôle bien déterminé : garantir que vous ne vous en remettez pas aux processus de récupération d'erreurs des navigateurs pour la restitution de votre contenu, avec toutes les incertitudes que cela suppose quant au résultat.
Une erreur de validité ne sera pas nécessairement obstructive pour l'accès au site, mais en étant valide, vous fondez votre travail d'accessibilité sur une base fiable et certaine.
Une seconde confusion fréquente porte sur la place de ce travail d'accessibilité dans le processus de développement. Trop souvent, c'est une remédiation sur une structure conçue par ailleurs : On va prendre la maquette de site, les critères techniques d'accessibilité de la WAI (WCAG1.0), et procéder aux modifications nécessaires pour atteindre l'un ou l'autre des 3 niveaux d'accessibilité.
En considérant ainsi l'accessibilité comme une sur-couche applicative sur le site, on multiplie souvent les dispositifs d'accessibilité plus ou moins complexes, coûteux à développer, et à l'efficacité souvent partielle.
Un exemple-type : la navigation dans la page pour les personnes qui ne peuvent pas utiliser une souris, et qui doivent passer par le clavier ou un dispositif spécifique.
Dans le cas d'un design complexe, aux colonnes et aux zones multiples, cette navigation au clavier peut s'avérer très difficile quand il faut parcourir toutes les zones répétitives de menus et autres contenus annexes avant d'arriver à l'article proprement dit.
Le développeur peut y remédier en ajoutant à sa structure des contournements qui seront plus ou moins utilisables selon les cas d'utilisateurs.
Mais, si cet aspect de l'accessibilité avait été intégré dès le départ dans le développement, on aurait eu une structure à la fois compatible avec le design recherché et avec une navigation au clavier "naturelle", logique et aisée, à moindre coût et avec une plus grande fiabilité.
L'accessibilité, telle qu'elle est gérée actuellement par les standards Web, est une dimension présente dans chaque format : Le (X)HTML, les CSS, le DOM... tous intègrent des éléments d'accessibilité complémentaires. Cette dimension doit donc être prise en compte à chaque stade de développement d'un site, dans une démarche d'ensemble.
AB - Résumons-nous, la problématique ne serait pas la validation des standards établis par le W3C, XHTML et CSS notamment, mais le rendu : Contenus, accessibilité, navigation, ergonomie ?
LD - L'approche qualitative joue un rôle clé pour traiter cette problématique.
La qualité Web telle qu'elle est abordée en particulier par Temesis comporte en effet deux volets complémentaires : la qualité de l'expérience utilisateur et la qualité de résultats du point de vue du maître d'oeuvre.
C'est la qualité de l'expérience utilisateur qui permet au site d'atteindre durablement les objectifs fixés par le maître d'oeuvre.
Or, comme l'ont montré Elie Sloïm et Vincent Bénard (http://temesis.com/article/sammag1_fr.html), cette qualité perçue par l'utilisateur repose à la fois sur la valeur ajoutée qu'il tire de sa visite, sur la facilité d'accès à cette valeur ajoutée, et sur la confiance générée par le site.
Quel est le rôle des standards et de la validation, à ce stade ? Ces outils apportent certes des bénéfices bien visibles, comme par exemple l'optimisation de coûts de bande passante, satisfaisants pour l'utilisateur comme pour le maître d'oeuvre.
Mais ils permettent surtout de minimiser un large éventail de risques qu'il serait autrement très difficile et coûteux d'anticiper, de mesurer ou de parer. Un code non standard ou non valide est par exemple la source potentielle d'un rendu erroné dans telles ou telles conditions d'accès que maîtres d'oeuvres et concepteurs ne peuvent prévoir, pour des raisons de moyens techniques, de coûts ou de compétences.
Cette non-conformité peut aussi bien créer des difficultés de navigation, rendre le contenu illisible, ou simplement réduire l'ergonomie du site. Elle crée finalement des risques invisibles de non-qualité qui peuvent décrédibiliser le site aux yeux de
l'utilisateur. Il est donc nécessaire d'adopter ces formats standards et d'en respecter les exigences, mais ce n'est pas suffisant. Il reste à les exploiter au mieux de l'expérience utilisateur.
Prenons l'exemple de l'interface de navigation : en faisant le choix d'un menu aux formats XHTML CSS et non d'un contenu Flash, je pare déjà un certain nombre de risques côté utilisateur. Si la syntaxe de ce menu est valide, je diminue encore ces risques. Mais la démarche qualitative ne s'arrête pas là...
Les interfaces de navigation dynamiques sont par exemple très à la mode, sur la foi d'un postulat esthétique : un menu déroulant est souvent réputé dynamiser "magiquement" la page, la rendre "cool" et séduire ainsi l'utilisateur conquis.
Je peux, certes, me précipiter sur ce choix esthétique et réaliser un tel menu en XHTML CSS valide. Mais voilà que j'oublie l'utilisateur. Je cours tout d'abord le risque de parasiter son expérience de navigation avec une esthétique qui n'a peut-être rien d'essentiel ou de remarquable à ses yeux.
J'oublie ensuite que j'ai intégré l'accessibilité à chaque stade de mon développement : ces menus sont, en l'état des moyens disponibles, toujours problématiques pour différentes configurations utilisateurs.
Enfin, si ma navigation comporte une telle quantité de liens qu'il me faut les organiser en sous-menus déroulants pour ne pas encombrer mon interface, je devrai peut-être d'abord revenir sur ce contenu surabondant :
Est-ce le meilleur moyen de mettre à disposition de l'utilisateur les informations qui lui sont vraiment utiles à cet endroit précis du site ?
Ne puis-je revoir ma structure de navigation, et privilégier au contraire des menus limités aux liens pertinents pour chaque section du site ? Je ferai de bien meilleurs choix si je reste guidé constamment par le souci de faciliter l'expérience utilisateur à tous les niveaux.
Nous avons donc un socle de travail : les standards de formats et d'accessibilité, utilisés rationnellement, c'est à dire de manière valide. Sur ce socle peut se construire une démarche qualitative de contenu, de design, de navigation... centrée sur l'utilisateur, pour optimiser la réalisation des objectifs du site.
C'est le coeur de notre métier.
AB - En quoi la conversion des sites "industriels" à l'approche standard est-elle un problème plus complexe que celle des sites "artisanaux" ?
LD - Tout d'abord, les sites des grands comptes peuvent poser des problèmes de volume et donc de coût prohibitif d'une refonte totale. Une démarche sélective et très structurée est indispensable.
Le W3C, dans le cadre du travail du Groupe d'Intérêts sur l'Assurance Qualité, a d'ailleurs publié un guide intitulé "Passer aux standards Web, ou comment améliorer facilement votre site Web" (http://www.w3.org/QA/2003/03/web-kit.html.fr).
Ce guide propose une méthodologie, depuis les choix de priorités jusqu'au suivi de qualité, en passant par l'analyse de l'existant (à l'aide d'outils spécifiques tels le LogValidator du W3C), les stratégies de correction, l'optimisation des outils, etc.
Cette méthodologie répond à une large partie de cette complexité des sites industriels liée aux facteurs d'échelle. D'autre part, dans le cas des sites artisanaux, on fait face à un petit nombre d'acteurs intervenant dans le processus de production de contenu, dans le choix des outils, des formats, dans le suivi du site.
Ces acteurs sont en général en étroite relation et le projet de site lui-même est fédérateur. A l'inverse, dans le cas des grands comptes, on voit fréquemment intervenir de multiples acteurs dans le pilotage de projets qui ne sont pas nécessairement consensuels, et où l'intérêt de la normalisation ne sera pas forcément perçu par tous : Directions informatiques, directions de la communication, voire directions des ressources humaines en tant que demandeuse dans le cas des intranets.
Sans compter les éventuels prestataires de services externes, tels que les agences Web, les référenceurs, etc. La collaboration entre ces acteurs peut être problématique, d'autant que le chef de projet doit assumer des compétences multiples, qui peuvent lui être peu familières, ou relever d'un service sur lequel il n'a pas de pouvoir hiérarchique.
Notons cependant, comme le suggère cet article Openweb (http://openweb.eu.org/articles/mieux_travailler_accessibilite_2/), que l'intégration des objectifs et des normes d'accessibilité peut être un moyen de fédérer l'action de ces acteurs sur un thème consensuel, avec un cadre normatif aidant à la prise de décision.
Les questions de suivi de la normalisation sont également cruciales : Si une structure accessible a été développée, elle dépend encore, par exemple, de l'utilisation qui en sera faite par les rédacteurs de contenus : Vont-ils savoir donner des alternatives textuelles pertinentes pour leurs images ? Renseigner correctement les éléments d'accessibilité de leurs tableaux ?
De même pour une structure valide au départ : même dans le cadre d'un CMS (Content Management System), elle dépendra du comportement des utilisateurs de celui-ci, et un simple copié collé d'un texte rédigé dans une application tierce non conforme peut invalider le résultat - C'est l'exemple classique des textes encodés par MS Word.
De son côté, un designer peut amener des choix de formats non standard, après un développement normalisé...
La prise en compte des compétences et l'investissement des personnes à chaque étape du processus de production standardisé est donc indispensable : Ceci amène à gérer des coûts de formation non négligeables, mêmes s'ils seront compensés par les bénéfices à terme (voir la FAQ décideurs qu'y consacre Openweb, http://openweb.eu.org/articles/faq_decideurs/).
Dans le même ordre d'idée, il peut y avoir des coûts de développement importants côté CMS, si l'on veut y intégrer l'accessibilité (voir notre conférence sur l'accessibilité et les CMS, dans le cadre des Rencontres Mondiales du Logiciel Libre de juillet dernier http://blog.palaci.fr/2005/07/13/138-accessibilite-cms).
AB - Selon vous, quels défis doit-on relever pour que progressent l'accessibilité web et "la société de l'information pour tous" ?
LD - Sans prétendre à l'exhaustivité, voici 3 points particulièrement saillants à mes yeux :
La formation et le conseil sont des défis cruciaux.
Il existe aujourd'hui encore très peu d'organismes ayant la capacité, l'expérience et les compétences pour définir et assurer des formations à plusieurs niveaux, depuis la maîtrise des données de base jusqu'à l'expertise. La dimension "conseil et formation" va répondre à des besoins croissants. Elle doit se développer dans le souci de prestations de qualité.
Un second défi me semble être dans le camp des développeurs d'application en amont du site.
La prise en compte de l'accessibilité dans les outils de production des sites pose des problèmes qui sont très nouveaux pour les développeurs. Il s'agit d'anticiper systématiquement les risques de génération d'un obstacle à l'accessibilité en guidant l'utilisateur du CMS ou de l'application. Il faut, selon les cas, lui fournir une aide contextuelle, lui imposer la saisie des informations vitales pour l'accessibilité, gérer pour lui certains contenus (comme les abréviations), intégrer des outils validant (Tidy, correcteurs orthographiques) etc.
Là encore, la formation et l'information sont incontournables, tant envers les développeurs qu'envers les utilisateurs de leurs outils.
Enfin, une priorité plus politique est de montrer quels sont les bénéfices réels de l'accessibilité.
Celle-ci est encore vue aujourd'hui à tort comme un domaine marginal aux enjeux limités. Or, comme Elie Sloïm et moi-même avons tenté de le montrer dans "Pourquoi l'accessibilité numérique ?" (http://openweb.eu.org/articles/accessibilite_numerique_pourquoi/), elle bénéficie potentiellement à toute la collectivité, bien au-delà du seul public des personnes handicapées.
Prise en compte dans une démarche qualitative globale, elle contribue à la rationalisation des contenus, à l'amélioration de l'ergonomie, de l'interopérabilité, et à une diminution finale des coûts.
L'accessibilité fait partie d'une meilleure gestion globale du Web. Celui-ci entre dans une phase de rationalité industrielle après un premier développement très artisanal. Mais cette évolution va demander aux donneurs d'ordre d'acquérir une nouvelle culture de management Web.
AB - Laurent Denis, merci pour ces éclaircissements.
http://temesis.com/
AB - Bonjour Laurent Denis. Formateur, blogueur, vous faites de l'accessibilité web une priorité. Quel est votre rôle au sein des communautés Opquast.org et OpenWeb.eu.org ?
LD - Bonjour. Je suis consultant associé pour Temesis, société de formation et de conseil spécialisée sur la qualité, la conformité, et l'accessibilité des sites Internet et Intranet (http://temesis.com).
C'est à ce titre que j'interviens dans le projet Opquast de référentiel "Qualité des services en ligne" initié et dirigé par Elie Sloïm.
Les bonnes pratiques de ce référentiel intègrent les problématiques de conformité, d'accessibilité et d'ergonomie dans une démarche globale de suivi qualité.
Via le site de l'atelier Opquast (http://opquast.org), dont je suis responsable, elles sont élaborées en tant que projet libre, par une communauté ouverte à tous les acteurs du Web : Décideurs, développeurs, utilisateurs.
Leur suivi d'application peut être fait à l'aide d'outils spécifiques, élaborés par Temesis et proposés sur le site Opquast.com (http://mon-opquast.com).
D'autre part, au sein du collectif OpenWeb, qui contribue depuis 2002 à la diffusion des standards Web auprès des décideurs et des développeurs, j'interviens comme rédacteur en chef aux côtés de Tristan Nitot (http://standblog.org) et de Fabrice Bonny, ainsi que comme auteur d'articles, essentiellement sur l'accessibilité et sur les techniques CSS.
AB - A la suite de la publication d'un article dans nos colonnes*, vous avez parlé de "confusions concernant les enjeux de la validité HTML et de la notion d'accessibilité". Pouvez-vous préciser votre pensée ?
LD - La confusion la plus fréquente porte sur l'équation erronée "validité = accessibilité". La validité du code HTML et CSS est effectivement l'un des critères minimaux requis pour l'accessibilité d'un site. Mais ce critère ne fait qu'assurer que ces formats sont correctement utilisés du point de vue syntaxique.
A titre d'exemple, la validité HTML ou XHTML va exiger que chaque élément image de vos pages soit doté de l'attribut servant à lui donner une alternative textuelle (elle sera exploitée en particulier par les lecteurs d'écran qui donneront ainsi une information équivalente à cette image).
Pour être valide, il suffit que l'attribut soit présent, quel que soit son contenu. Le travail d'accessibilité n'est donc pas encore fait, puisqu'il reste à renseigner tous ces attributs de manière pertinente : une page valide n'aura peut-être aucun sens dans un lecteur d'écran si ces informations ne sont pas les bonnes.
La validité n'est donc qu'un outil, indispensable, mais au rôle bien déterminé : garantir que vous ne vous en remettez pas aux processus de récupération d'erreurs des navigateurs pour la restitution de votre contenu, avec toutes les incertitudes que cela suppose quant au résultat.
Une erreur de validité ne sera pas nécessairement obstructive pour l'accès au site, mais en étant valide, vous fondez votre travail d'accessibilité sur une base fiable et certaine.
Une seconde confusion fréquente porte sur la place de ce travail d'accessibilité dans le processus de développement. Trop souvent, c'est une remédiation sur une structure conçue par ailleurs : On va prendre la maquette de site, les critères techniques d'accessibilité de la WAI (WCAG1.0), et procéder aux modifications nécessaires pour atteindre l'un ou l'autre des 3 niveaux d'accessibilité.
En considérant ainsi l'accessibilité comme une sur-couche applicative sur le site, on multiplie souvent les dispositifs d'accessibilité plus ou moins complexes, coûteux à développer, et à l'efficacité souvent partielle.
Un exemple-type : la navigation dans la page pour les personnes qui ne peuvent pas utiliser une souris, et qui doivent passer par le clavier ou un dispositif spécifique.
Dans le cas d'un design complexe, aux colonnes et aux zones multiples, cette navigation au clavier peut s'avérer très difficile quand il faut parcourir toutes les zones répétitives de menus et autres contenus annexes avant d'arriver à l'article proprement dit.
Le développeur peut y remédier en ajoutant à sa structure des contournements qui seront plus ou moins utilisables selon les cas d'utilisateurs.
Mais, si cet aspect de l'accessibilité avait été intégré dès le départ dans le développement, on aurait eu une structure à la fois compatible avec le design recherché et avec une navigation au clavier "naturelle", logique et aisée, à moindre coût et avec une plus grande fiabilité.
L'accessibilité, telle qu'elle est gérée actuellement par les standards Web, est une dimension présente dans chaque format : Le (X)HTML, les CSS, le DOM... tous intègrent des éléments d'accessibilité complémentaires. Cette dimension doit donc être prise en compte à chaque stade de développement d'un site, dans une démarche d'ensemble.
AB - Résumons-nous, la problématique ne serait pas la validation des standards établis par le W3C, XHTML et CSS notamment, mais le rendu : Contenus, accessibilité, navigation, ergonomie ?
LD - L'approche qualitative joue un rôle clé pour traiter cette problématique.
La qualité Web telle qu'elle est abordée en particulier par Temesis comporte en effet deux volets complémentaires : la qualité de l'expérience utilisateur et la qualité de résultats du point de vue du maître d'oeuvre.
C'est la qualité de l'expérience utilisateur qui permet au site d'atteindre durablement les objectifs fixés par le maître d'oeuvre.
Or, comme l'ont montré Elie Sloïm et Vincent Bénard (http://temesis.com/article/sammag1_fr.html), cette qualité perçue par l'utilisateur repose à la fois sur la valeur ajoutée qu'il tire de sa visite, sur la facilité d'accès à cette valeur ajoutée, et sur la confiance générée par le site.
Quel est le rôle des standards et de la validation, à ce stade ? Ces outils apportent certes des bénéfices bien visibles, comme par exemple l'optimisation de coûts de bande passante, satisfaisants pour l'utilisateur comme pour le maître d'oeuvre.
Mais ils permettent surtout de minimiser un large éventail de risques qu'il serait autrement très difficile et coûteux d'anticiper, de mesurer ou de parer. Un code non standard ou non valide est par exemple la source potentielle d'un rendu erroné dans telles ou telles conditions d'accès que maîtres d'oeuvres et concepteurs ne peuvent prévoir, pour des raisons de moyens techniques, de coûts ou de compétences.
Cette non-conformité peut aussi bien créer des difficultés de navigation, rendre le contenu illisible, ou simplement réduire l'ergonomie du site. Elle crée finalement des risques invisibles de non-qualité qui peuvent décrédibiliser le site aux yeux de
l'utilisateur. Il est donc nécessaire d'adopter ces formats standards et d'en respecter les exigences, mais ce n'est pas suffisant. Il reste à les exploiter au mieux de l'expérience utilisateur.
Prenons l'exemple de l'interface de navigation : en faisant le choix d'un menu aux formats XHTML CSS et non d'un contenu Flash, je pare déjà un certain nombre de risques côté utilisateur. Si la syntaxe de ce menu est valide, je diminue encore ces risques. Mais la démarche qualitative ne s'arrête pas là...
Les interfaces de navigation dynamiques sont par exemple très à la mode, sur la foi d'un postulat esthétique : un menu déroulant est souvent réputé dynamiser "magiquement" la page, la rendre "cool" et séduire ainsi l'utilisateur conquis.
Je peux, certes, me précipiter sur ce choix esthétique et réaliser un tel menu en XHTML CSS valide. Mais voilà que j'oublie l'utilisateur. Je cours tout d'abord le risque de parasiter son expérience de navigation avec une esthétique qui n'a peut-être rien d'essentiel ou de remarquable à ses yeux.
J'oublie ensuite que j'ai intégré l'accessibilité à chaque stade de mon développement : ces menus sont, en l'état des moyens disponibles, toujours problématiques pour différentes configurations utilisateurs.
Enfin, si ma navigation comporte une telle quantité de liens qu'il me faut les organiser en sous-menus déroulants pour ne pas encombrer mon interface, je devrai peut-être d'abord revenir sur ce contenu surabondant :
Est-ce le meilleur moyen de mettre à disposition de l'utilisateur les informations qui lui sont vraiment utiles à cet endroit précis du site ?
Ne puis-je revoir ma structure de navigation, et privilégier au contraire des menus limités aux liens pertinents pour chaque section du site ? Je ferai de bien meilleurs choix si je reste guidé constamment par le souci de faciliter l'expérience utilisateur à tous les niveaux.
Nous avons donc un socle de travail : les standards de formats et d'accessibilité, utilisés rationnellement, c'est à dire de manière valide. Sur ce socle peut se construire une démarche qualitative de contenu, de design, de navigation... centrée sur l'utilisateur, pour optimiser la réalisation des objectifs du site.
C'est le coeur de notre métier.
AB - En quoi la conversion des sites "industriels" à l'approche standard est-elle un problème plus complexe que celle des sites "artisanaux" ?
LD - Tout d'abord, les sites des grands comptes peuvent poser des problèmes de volume et donc de coût prohibitif d'une refonte totale. Une démarche sélective et très structurée est indispensable.
Le W3C, dans le cadre du travail du Groupe d'Intérêts sur l'Assurance Qualité, a d'ailleurs publié un guide intitulé "Passer aux standards Web, ou comment améliorer facilement votre site Web" (http://www.w3.org/QA/2003/03/web-kit.html.fr).
Ce guide propose une méthodologie, depuis les choix de priorités jusqu'au suivi de qualité, en passant par l'analyse de l'existant (à l'aide d'outils spécifiques tels le LogValidator du W3C), les stratégies de correction, l'optimisation des outils, etc.
Cette méthodologie répond à une large partie de cette complexité des sites industriels liée aux facteurs d'échelle. D'autre part, dans le cas des sites artisanaux, on fait face à un petit nombre d'acteurs intervenant dans le processus de production de contenu, dans le choix des outils, des formats, dans le suivi du site.
Ces acteurs sont en général en étroite relation et le projet de site lui-même est fédérateur. A l'inverse, dans le cas des grands comptes, on voit fréquemment intervenir de multiples acteurs dans le pilotage de projets qui ne sont pas nécessairement consensuels, et où l'intérêt de la normalisation ne sera pas forcément perçu par tous : Directions informatiques, directions de la communication, voire directions des ressources humaines en tant que demandeuse dans le cas des intranets.
Sans compter les éventuels prestataires de services externes, tels que les agences Web, les référenceurs, etc. La collaboration entre ces acteurs peut être problématique, d'autant que le chef de projet doit assumer des compétences multiples, qui peuvent lui être peu familières, ou relever d'un service sur lequel il n'a pas de pouvoir hiérarchique.
Notons cependant, comme le suggère cet article Openweb (http://openweb.eu.org/articles/mieux_travailler_accessibilite_2/), que l'intégration des objectifs et des normes d'accessibilité peut être un moyen de fédérer l'action de ces acteurs sur un thème consensuel, avec un cadre normatif aidant à la prise de décision.
Les questions de suivi de la normalisation sont également cruciales : Si une structure accessible a été développée, elle dépend encore, par exemple, de l'utilisation qui en sera faite par les rédacteurs de contenus : Vont-ils savoir donner des alternatives textuelles pertinentes pour leurs images ? Renseigner correctement les éléments d'accessibilité de leurs tableaux ?
De même pour une structure valide au départ : même dans le cadre d'un CMS (Content Management System), elle dépendra du comportement des utilisateurs de celui-ci, et un simple copié collé d'un texte rédigé dans une application tierce non conforme peut invalider le résultat - C'est l'exemple classique des textes encodés par MS Word.
De son côté, un designer peut amener des choix de formats non standard, après un développement normalisé...
La prise en compte des compétences et l'investissement des personnes à chaque étape du processus de production standardisé est donc indispensable : Ceci amène à gérer des coûts de formation non négligeables, mêmes s'ils seront compensés par les bénéfices à terme (voir la FAQ décideurs qu'y consacre Openweb, http://openweb.eu.org/articles/faq_decideurs/).
Dans le même ordre d'idée, il peut y avoir des coûts de développement importants côté CMS, si l'on veut y intégrer l'accessibilité (voir notre conférence sur l'accessibilité et les CMS, dans le cadre des Rencontres Mondiales du Logiciel Libre de juillet dernier http://blog.palaci.fr/2005/07/13/138-accessibilite-cms).
AB - Selon vous, quels défis doit-on relever pour que progressent l'accessibilité web et "la société de l'information pour tous" ?
LD - Sans prétendre à l'exhaustivité, voici 3 points particulièrement saillants à mes yeux :
La formation et le conseil sont des défis cruciaux.
Il existe aujourd'hui encore très peu d'organismes ayant la capacité, l'expérience et les compétences pour définir et assurer des formations à plusieurs niveaux, depuis la maîtrise des données de base jusqu'à l'expertise. La dimension "conseil et formation" va répondre à des besoins croissants. Elle doit se développer dans le souci de prestations de qualité.
Un second défi me semble être dans le camp des développeurs d'application en amont du site.
La prise en compte de l'accessibilité dans les outils de production des sites pose des problèmes qui sont très nouveaux pour les développeurs. Il s'agit d'anticiper systématiquement les risques de génération d'un obstacle à l'accessibilité en guidant l'utilisateur du CMS ou de l'application. Il faut, selon les cas, lui fournir une aide contextuelle, lui imposer la saisie des informations vitales pour l'accessibilité, gérer pour lui certains contenus (comme les abréviations), intégrer des outils validant (Tidy, correcteurs orthographiques) etc.
Là encore, la formation et l'information sont incontournables, tant envers les développeurs qu'envers les utilisateurs de leurs outils.
Enfin, une priorité plus politique est de montrer quels sont les bénéfices réels de l'accessibilité.
Celle-ci est encore vue aujourd'hui à tort comme un domaine marginal aux enjeux limités. Or, comme Elie Sloïm et moi-même avons tenté de le montrer dans "Pourquoi l'accessibilité numérique ?" (http://openweb.eu.org/articles/accessibilite_numerique_pourquoi/), elle bénéficie potentiellement à toute la collectivité, bien au-delà du seul public des personnes handicapées.
Prise en compte dans une démarche qualitative globale, elle contribue à la rationalisation des contenus, à l'amélioration de l'ergonomie, de l'interopérabilité, et à une diminution finale des coûts.
L'accessibilité fait partie d'une meilleure gestion globale du Web. Celui-ci entre dans une phase de rationalité industrielle après un premier développement très artisanal. Mais cette évolution va demander aux donneurs d'ordre d'acquérir une nouvelle culture de management Web.
AB - Laurent Denis, merci pour ces éclaircissements.
- 'Web-pour-tous' fait de l'accessibilité une priorité http://www.neteco.com/article_20050822150757_web_pour_tous_fait_de_l_accessibilite_une_priorite.html
