Accessibilité du Web

L'accessibilité du Web est la problématique de l'accès aux services et contenus en ligne pour les handicapés et les seniors. Définie par des normes techniques établies par la Web Accessibility Initiative (WAI) du World Wide Web Consortium (W3C), elle nécessite un traitement tout au long du cycle de vie d'un site Web, par la totalité de ses acteurs, via des méthodes d'applications, des référentiels métiers et une démarche de suivi. Quoiqu'elle soit une composante et un levier d'amélioration de leur qualité globale, le degré d'accessibilité effectif des sites Web reste aujourd'hui particulièrement faible.

Le champ de l'accessibilité

L'accessibilité du Web est définie par la WAI^{[W3C 1]} comme l'une des composantes de l'accessibilité numérique :

«L'accessibilité du web veut dire que les personnes handicapées peuvent l'utiliser. Plus particulièrement, elle veut dire que ces gens peuvent percevoir, comprendre, naviguer, interagir avec le web, et y contribuer. L'accessibilité du Web bénéficie aussi à d'autres, surtout les personnes âgées ayant des capacités diminuées dues au vieillissement.»

Elle est un droit universel, selon l'article 9 de la Convention relative aux droits des personnes handicapées adoptée en 2006 par l'Organisation des Nations unies^{[Note 1]}

«Pour permettre aux personnes handicapées de vivre de façon indépendante et de participer pleinement à l'ensemble des aspects de la vie, les États Parties prennent des mesures appropriées pour leur assurer, sur la base de l'égalité avec les autres, l'accès à l'environnement physique, aux transports, à l'information ainsi qu'à la communication, y compris aux dispositifs et technologies de l'information et de la communication, ainsi qu'aux autres équipements et services ouverts ou apportés au public, tant dans les zones urbaines que rurales. Ces mesures, parmi lesquelles figurent l'identification et l'élimination des obstacles et barrières à l'accessibilité, s'appliquent, entre autres [... ] aux services d'information, de communication et autres services, y compris les services électroniques et les services d'urgence [... ] Les États Parties prennent aussi des mesures appropriées pour [... ] promouvoir l'accès des personnes handicapées aux nouveaux dispositifs et technologies de l'information et de la communication, y compris l'Internet»

Les contextes utilisateur

Même dans cette acception étroitement liée au handicap, l'accessibilité vise une particulièrement grande variété de cas utilisateurs^{[Note 2]}. Celle-ci s'illustre en effet par :

• la diversité des handicaps susceptibles d'affecter la capacité à accéder à un contenu ou à un service en ligne^{[W3C 2]}. Ceux-ci peuvent être visuels (cécité, trouble de la vision, daltonisme), auditifs (surdité totale ou partielle), moteurs, cognitifs ou neurologiques, ou encore liés au vieillissement.
• la variété des périphériques d'entrée et de sortie, et celle des aides techniques^{[W3C 3]} : claviers alternatifs et commutateurs, systèmes braille, lecteurs d'écran (JAWS, Window-Eyes^{[Note 3]}, SRCore pour Gnopernicus) et autres outils de synthèse vocale (Microsoft Windows, Narrator pour Windows 2000), loupes d'écran et autres systèmes d'agrandissement, navigateurs textes, systèmes d'interaction vocale, paramétrages d'accessibilité des navigateurs Web classiques, etc.

L'un des enjeux de la démarche d'accessibilité Web est de s'extraire des contraintes spécifiques à ces multiples contextes utilisateurs, et ainsi atteindre un niveau d'abstraction suffisant pour pouvoir se doter d'outils normatifs et de recommandations utilisables par l'industrie (fabriquants de navigateurs Web, créateurs de contenus, etc).

Les effets induits de l'accessibilité des contenus

Au-delà des bénéfices atteints pour les utilisateurs handicapés, l'accessibilité Web profite plus beaucoup à l'ensemble des utilisateurs et acteurs, surtout en termes d'utilisabilité, de maîtrise de la production des contenus, de retours sur investissement^{[Note 4]} et d'image.

L'accessibilité des contenus rejoint aussi en partie la problématique de l'accès sur les mobiles et les Mobile Web Best Practices 1.0 du W3C son en partie dérivées des normes d'accessibilité des contenus Web^{[Note 5]}. Mais l'essor du Web mobile suscite à son tour de nouveaux usages et des innovations technologiques qui sont tout autant de nouveaux défis en termes d'accessibilité^{[Note 6]}.

Accessibilité des contenus ou accessibilité universelle ?

Certains acteurs de l'accessibilité Web^{[Note 7]} étendent son champ au-delà de la question du handicap, à l'ensemble des contextes utilisateurs, en s'inspirant surtout de l'objectif donné au W3C par Tim Berners-Lee, inventeur du World Wide Web :

«Mettre le web et ses services à la disposition de l'ensemble des individus, quel que soit leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales.»

L'accessibilité des contenus reste cependant, aux points de vue normatif et opérationnel, un aspect spécifique de cette ambition, et ne se confond pas davantage avec la notion de qualité Web dont elle est aussi une composante^{[Note 8]}. Suivant les solutions techniques et de l'état de l'art, des arbitrages peuvent être nécessaires entre optimisation de l'accessibilité et d'autres aspects qualitatifs tels que les contenus eux-mêmes, l'innovation, le référencement, l'ergonomie, l'interopérabilité ou la robustesse, quand ils s'avèrent au moins provisoirement contradictoires dans un contexte de production donné.

Les normes d'accessibilité mondiales

L'accessibilité Web dépend de plusieurs composantes interdépendantes^{[W3C 4]} :

• le contenu Web, c'est-à-dire «la totalité de l'information et de l'expérience sensorielle qui est communiquée à l'utilisateur par le biais d'un agent utilisateur, incluant le code ou le balisage qui définit la structure du contenu, sa présentation et les interactions avec lui»^{[W3C 5]}
• les agents utilisateurs qui exploitent le contenu et le restituent aux internautes : navigateurs, plugins, etc.
• les aides techniques logicielles (lecteurs d'écran, logiciels d'agrandissement, etc. ) et matérielles (claviers adaptés, commutateurs, etc. )
• les outils d'édition du contenu
• les outils d'évaluation de l'accessibilité Web
• les développeurs de contenu, d'agents utilisateurs, d'aides techniques, d'outils d'édition et d'évaluation.

Pour permettre le développement de l'accessibilité à travers ces composants, le W3C a créé des recommandations à travers le projet WAI (Web Accessibility Initiative) créé en 1996. Ces recommandations sont organisées selon trois points de vue :

1. les outils de production de contenu doivent d'une part pouvoir être utilisés par tous, et d'autre part autoriser et faciliter la production d'un contenu accessible. Il s'ensuit qu'ils doivent suivre des lignes de conduite spécifiques ; ces lignes de conduite sont répertoriées dans les Authoring Tools Accessibility Guidelines ;
2. le contenu mis en ligne lui-même doit être accessible ; c'est ce qu'on entend généralement par l'accessibilité du Web et dont les recommandations sont regroupées dans les Web Content Accessibility Guidelines ;
3. pour tirer parti de ce contenu accessible, les outils de consultation (par exemple les navigateurs Internet) doivent être utilisables par tous et exploiter les informations spécifiques qui ont été ajoutées aux contenus pour les rendre accessibles. Les lignes de conduite pour les outils de consultation sont exposées dans les User Agent Accessibility Guidelines.

La WAI intervient aussi lors de l'élaboration de l'ensemble des spécifications du W3C pour s'assurer de leur compatibilité avec les directives d'accessibilité. Son groupe de travail sur les protocoles et les formats est ainsi à l'origine d'améliorations du format HTML^{[W3C 6]} mais aussi des feuilles de style en cascade (CSS) ^{[W3C 7]}. Enfin, d'autres recommandations en chantier sont consacrées surtout au interfaces riches, ou à XML, SVG, SMIL^{[W3C 8]}.

Recommandations pour le contenu

Les recommandations en ce qui concerne le contenu s'adressent à l'ensemble des distributeurs de contenu sur le Web. Ces directives s'appellent les Web Content Accessibility Guidelines. Leur dernière version officielle est celle des WCAG1.0, qui remonte à 1999^{[W3C 9]}. Les travaux continuent dans le cadre d'une nouvelle version en cours d'élaboration, les WCAG2.0^{[W3C 10]}.

Recommandations pour les outils de production de contenu

Les lignes de conduite les plus à jour pour les logiciels d'édition de HTML, les éditeurs de page ou logiciel de publication de site web créant le code HTML, sont les Authoring Tools Accessibility Guidelines dans leur version 1.0, datant de février 2000^{[W3C 11]}.

Depuis la publication des ATAG1.0, sont sortis les dispositifs de gestion de contenu et les blogues pour lesquels les ATAG2.0^{[W3C 12]} sont en chantier. ATAG2.0 distingue deux aspects clés de l'accessibilité des outils de production :

• l'accessibilité de l'interface des d'outils de production, qui renvoie pour la majeure partie aux directives d'accessibilité des contenus Web, et qui dépend :
  • de sa compatibilité avec les aides techniques
  • de sa capacité à être perceptible
  • de sa capacité à être utilisable
  • de sa capacité à être compréhensible
• la capacité des outils à faciliter la production de contenus accessibles, c'est-à-dire :
  • supporter les solutions d'accessibilité que les rédacteurs doivent intégrer aux contenus
  • aider et guider les rédacteurs dans la production d'un contenu accessible, les alerter en cas d'actions générant des problèmes d'accessibilité
  • inciter les rédacteurs à prendre en compte l'accessibilité et faciliter celle-ci en général.

Les solutions de publication de plus en plus utilisées amènent à une séparation accrue entre le travail de production éditorial et les aspects techniques du contenu, et par conséquent entre métiers de rédacteur et d'intégrateur. Par conséquent, une responsabilité croissante incombe aux outils de production pour assurerdans la mesure du possible, et de manière aussi transparente que envisageable, le respect des directives d'accessibilité des contenus^{[Note 9]}. Ils ne peuvent cependant en être les seuls garants : les rédacteurs de contenu jouent un rôle final majeur, illustré par les référentiels métier liés aux compétences éditoriales.

Recommandations pour les outils de consultation

Pour tirer le meilleur parti des sites web accessibles, il est essentiel que les outils de consultation de ces sites soient eux-mêmes utilisables par des personnes handicapées. C'est dans l'intention de définir des recommandations à ce sujet qu'ont été rédigées les User Agent Accessibility Guidelines 1.0 ^{[W3C 13]}. Les travaux continuent dans le cadre d'une nouvelle version en cours d'élaboration, les UAAG2.0^{[W3C 14]}.

UAAG2.0 est organisé autour de 5 principes (décomposés en directives correspondant elles-mêmes à un ou plusieurs critères de succès)  :

1. Respecter les normes et conventions applicables
2. Favoriser l'accès par les technologies d'aide
3. Garantir que l'interface utilisateur soit perceptible
4. Garantir que l'interface utilisateur soit utilisable
5. Garantir que l'interface utilisateur soit compréhensible

Logiciels containers

Actuellement, les applications Web sont rédigées par des professionnels différents de ceux qui contribuent à la production du contenu. Il en résulte que l'unique application de WCAG (1 ou 2) ne suffit plus pour rendre le Web accessible. De plus en plus en plus d'applications de gestion passent du mode client/serveur au mode basé sur le Web^{[réf.  nécessaire]}. Il en résulte que le contenu en ligne provient, le plus fréquemment de bases de données entretenues pour d'autres usages que l'unique publication sur le web. La production du contenu s'automatise et , par conséquent, l'accessibilité ne repose plus uniquement sur l'accessibilité au sens de WCAG, mais également sur la capacité à produire de l'accessibilité de logiciels tels que :

• les agrégateurs de contenus,
• les logiciels de workflow,
• les logiciels métiers (par exemple, les outils de gestion de bibliothèque)
• les gestionnaires de contenu
• les logiciels de portail

ATAG 1.0 et ATAG 2.0 sont peu connus et peu pris en compte par les éditeurs de ce type d'outils^{[réf.  nécessaire]}.

La plupart des applications créées dans les entreprises puisent leurs données dans une base de données (relationnelle, objet ou un équivalent XML) et la présentent au Web pour la maintenance, l'alimentation, ou la consultation. Il en résulte que les bases de données doivent être préparées ou purgées préalablement à toute ambition de projet d'accessibilité. Cette préparation consiste principalement à vérifier que la base ne contient pas de champ fourre-tout (par exemple une case texte de 4 000 caractères) où l'opérateur peut saisir toute donnée qui crée chez lui le doute.

Après cette phase, et si la base contient des objets non-texte (par exemple, un album de photos, une base d'images, etc... ), il faut l'étendre pour recevoir les alternatives textes prévues par les diverses normes. Dans le cas des applications reposant sur l'équivalent XML d'une base de données, la modification du schéma s'impose dans le sens préconisé par la recommandation XAG ^{[W3C 15]} qui revient à ajouter au schéma les balises susceptibles d'accueillir un tel contenu et de les rendre obligatoires.

interfaces dynamiques

L'essor des services et applications en ligne reposant sur l'utilisation croissante de technologies hybrides telles qu'AJAX, DHTML, et SVG, l'élaboration par la WAI de l'Accessible Rich Internet Applications Suite (ARIA) vise à mettre en place le cadre normatif indispensable à l'accessibilité des application Web dynamiques^{[W3C 16]}.

Quelques éditeurs mettent à disposition des acteurs de l'accessibilité des bibliothèques de technologies accessibilisées en tout ou en partie, telle la bibliothèque DOJO d'AJX en partie accessibilisée par la société IBM.

Les cycles d'implémentation de l'accessibilité

L'interdépendance entre les composantes du Web autorise un progrès de l'accessibilité pour l'une d'entre elle d'entraîner des améliorations en chaîne^{[W3C 17]}. Par exemple :

• la prise en compte d'une directive d'accessibilité par les agents utilisateurs incite les utilisateurs eux-mêmes à réclamer sa prise en compte par les éditeurs de contenu,
• la prise en compte d'une directive d'accessibilité par les éditeurs de contenu les incite à réclamer son implémentation dans leurs outils d'édition

Inversement, cette interdépendance conduit à des blocages quand une composante présente des faiblesses : par exemple, une absence d'implémentation dans un navigateur incite les éditeurs de contenu à ne pas tenir compte d'une directive d'accessibilité, ce qui peut conduire à leur tour les développeurs d'outils d'édition à ne pas la prendre en charge. La question peut dans ce cas se poser de son maintien dans les normes techniques du Web, comme par exemple dans le cas des descriptions étendues d'images dans le format HTML5^{[Note 10]}

Les méthodes d'application

Les directives WCAG ne sont cependant pas immédiatement opérationnelles dans le cadre des projets Web : la mise en œuvre de WCAG1.0, dont le contenu a été fixé en 1999, nécessite des adaptations à l'évolution des technologies (sont surtout concernés 5 points de contrôle originellement définis en réponse à des défauts temporaires d'implémentation de la part des agents utilisateurs^{[W3C 18]}). WCAG2.0 renforce ce besoin de par son caractère générique. La prise en compte de ces directives nécessite par conséquent d'adopter une méthode d'évaluation et de déploiement.

Ces méthodes peuvent être définies à l'échelle nationale ou à une échelle géographique plus large, par des organismes privés ou publics. Par exemple :

• Accessiweb^{[Note 11]} (France) et Anysurfer^{[Note 12]} (Belgique) sont des méthodes produites par des organismes de labellisation privés, inspirées des WCAG1.0.
• le RGAA (France) est un référentiel public de déploiement des WCAG1.0.
• la Méthodologie Unifiée d'Évaluation de l'Accessibilité du Web (UWEM) ^{[Note 13]} est une méthode européenne issue de différentes méthodes nationales privées, donnant la possibilité une évaluation de l'application de WCAG aux niveaux A et AA.

Les directives ATAG peuvent s'appuyer partiellement sur les méthodes d'application de WCAG, mais ne disposent d'aucune méthode d'application pour ce qui leur est spécifique.

Une démarche globale

Les recommandations du WAI, de portée mondiale, proposent un ensemble de solutions pour permettre la réalisation de sites web accessibles. Elles supposent cependant une prise en compte à chaque étape de la conception : l'accessibilité des contenus n'est pas une surcouche technique spécifique, mais une démarche intégrée tout au long du cycle de vie d'un site Web.

En amont des contenus

La prise en compte de l'accessibilité du contenu gagne à être faite dès les premiers stades de conception d'un projet Web : «Une réponse habituelles des développeurs après réception d'une évaluation d'accessibilité est qu'il aurait été bien plus facile d'incorporer les changements demandés au début du cycle de vie du site [... ] Intégrer l'accessibilité le plus tôt envisageable lors de la conception d'un site est une économie de temps et d'argent, par comparaison à des corrections après-coup.»^{[Note 14]}.

Ceci peut concerner surtout l'utilisation des bases documentaires, le choix d'un dispositif de gestion de contenus et d'une charte graphique, la définition des cahiers des charges et le choix des prestataires, la politique de formation interne, etc.

En cours de création ou de refonte

Lors de la réalisation du projet, des évaluations d'accessibilité peuvent intervenir surtout aux étapes de^{[réf.  nécessaire]} conception de la charte graphique, des gabarits de page web, ou du recyclage de contenus antérieurs :

La charte graphique a un impact immédiat sur l'accessibilité finale du contenu^{[Note 15]} à travers l'utilisation de la couleur et des éléments graphiques comme véhicule de l'information, ainsi qu'à cause des contraintes d'intégration qu'elle peut induit dans le choix des formats de publication (HTML, Flash) et dans leur utilisation. Son intégration générique à travers des gabarits de page a un rôle clé surtout à travers^{[Note 16]} ses choix de technologies (AJAX, Flash,), et en déterminant la structure sémantique du contenu, l'accessibilité des éléments de navigation et la mise en place des alternatives aux éléments programmables ou graphiques.

En aval, suivi et maintenance

L'accessibilité du contenu n'est pas un état figé assuré d'être conservé une fois atteint^{[réf.  nécessaire]} : chaque nouveau contenu ou service apporté au site nécessite d'être inclus dans une démarche de suivi et d'évaluation.

Les rédacteurs de contenu ont un impact majeur sur l'accessibilité, à travers^{[Note 17]} :

• le choix des illustrations graphiques et la pertinence des alternatives aux éléments non-textuels,
• la mise en ligne de textes clairs et compréhensibles pour les internautes, mais également utilisables par les aides techniques grâce à la qualité de leur structure HTML,
• d'une façon plus générale leur utilisation de la solution de publication et de l'assistance qu'elle leur apporte pour la production de contenu accessibles.

Les outils automatiques

Un certain nombre des points de contrôle des WCAG étant automatisables, de nombreux outils ont été mis au point pour favoriser le développement, ou la validation, de sites web accessibles.

L'automatisation est partiellement applicable :

• a priori, aux outils de production de contenu comme les éditeurs HTML ou les CMS. Au cours de la saisie du contenu, des contrôles peuvent être réalisés en temps réel, et des contraintes établies, pour favoriser la production de contenu accessible (imposer la structure logique du document, séparer la présentation du contenu, forcer la saisie d'alternatives textuelles, etc. )
• a posteriori, avec outils de vérification de l'accessibilité.

Dans les deux cas néanmoins, la majorité des points de contrôle comme la pertinence des intitulés de lien ou des alternatives textuelles, les changements de langue, la dégradation harmonieuse de la présentation et des contenus selon le système de rendu... ne sont pas automatisables, ou ne le sont que partiellement sous forme d'assistance à la validation humaine.

Ces outils automatiques ne peuvent par conséquent être à eux seuls des garants de l'accessibilité ; par contre, ils forment une aide précieuse lors d'une phase d'évaluation ou d'audit, en dégageant l'évaluateur humain de tâches fastidieuses et lui servant à se consacrer aux points de contrôle d'un abord plus délicat.

Parmi les particulièrement nombreux outils disponibles, citons par exemple WAVE^{[Note 18]} (dont les résultats sont donnés sous forme d'icônes ajoutées à la page évaluée), OCAWA^{[Note 19]} (développé en collaboration avec France Telecom).

Les tests utilisateurs

Le recours à des tests d'accessibilité d'un site impliquant des personnes handicapés peut apporter plusieurs bénéfices, dont surtout^{[W3C 19]} :

• permettre aux développeurs d'outils de production ainsi qu'aux rédacteurs de découvrir comment ces personnes interagissent avec le site, quelles difficultés anticipent-elles et quelles sont leurs stratégies et leurs démarches pour les résoudre.
• motiver développeurs, rédacteurs et responsables de sites en mettant en évidence les conséquences concrètes de leur investissement dans l'accessibilité

Cependant, de tels tests utilisateurs ne peuvent déterminer à eux seuls le niveau d'accessibilité effectif d'un site : cette estimation requiert en effet une évaluation systématique aux regards des directives WCAG^{[W3C 20]}.

L'évaluation experte

Evaluer le degré d'accessibilité d'un site Web nécessite davantage que ne peut apporter un outil automatisé. L'évaluation exige en effet une compréhension approfondie des technologies Web, des outils de validation, des directives d'accessibilité, des aides techniques et des agents utilisateurs, mais aussi des stratégies auxquelles recourent les personnes handicapées dans leur usage du Web^{[W3C 21]}.

Compte-tenu des capacités limitées de l'évaluation automatisée et du coût croissant que représenterait l'évaluation experte menée à grand échelle, le passage à l'industrialisation du Web exige le recours à une approche mixte, tirant parti de la rapidité des outils automatisés et de la pertinence du jugement humain : une approche semi-automatisée de l'évaluation d'accessibilité autoriserait ce compromis entre coût et efficacité^{[Note 20]}.

Politiques d'accessibilité, suivi et gestion du risque

Selon la WAI, une politique organisationnelle d'accessibilité se définit par^{[W3C 22]} :

• un niveau de conformité A, AA ou AAA attendu pour les contenus d'une part, et pour les outils de conception des contenus d'autre part,
• un champ d'application dans ces contenus (pages déjà existantes, nouvelles pages, contenus produits par l'entité, contenus apportés par un tiers, etc. ),
• un calendrier de déploiement, qui peut être unique (le site est conforme au niveau A à telle date), progressif (passages successifs par les niveau A puis AA et peut-être AAA) ou sélectif (priorité accordée à certaines parties du site). Il peut aussi s'appliquer à l'intégration de l'accessibilité dans les outils de conception ainsi qu'à la mise en place de ressources internes de formation et de contrôle
• un processus de contrôle, de réclamation sur la conformité et de suivi du niveau d'accessibilité requis
• des mécanismes de révision et de mise à jour de la politique d'accessibilité selon l'évolution des normes de référence

Cette approche est centrée sur une obligation de résultat strictement définie par le respect d'un niveau d'accessibilité donné. Elle était justifiée à une époque où :

• d'une part la production de contenu était toujours beaucoup dominée par un modèle artisanal alors qu'elle est désormais passée à un stade (pré-) industriel ;
• d'autre part la démocratisation massive de l'accès à la production de contenu s'accompagnait de l'arrivée de nombreux développeurs débutants sans connaissance en accessibilité auprès desquels il était indispensable de faire passer des notions de base, et qu'il fallait sensibiliser par des messages mettant clairement en évidence les lacunes de leurs productions.

Elle fait la connaissance de cependant actuellement ses limites en termes de difficultés de mise en œuvre^{[Note 21]} et d'absence de gestion du risque dans le cadre d'une démarche qualité^{[Note 22]} à l'échelle d'importants parcs de sites.

Les États

Différents États adoptent des politiques en faveur de l'accessibilité des contenus et services Web dans le cadre plus général de la législation sur l'égalité des chances ou de la règlementation sur les services publics en ligne. Cette démarche est rarement étendue au secteur privé. Elle peut être soutenue ou réclamée par les acteurs privés du Web^{[Note 23]}. Elle suscite quelquefois des réserves de la part de certains d'entre eux^{[Note 24]}.

Les associations d'usagers et d'acteurs du Web

Des associations agissent pour promouvoir l'accessibilité du web aux personnes handicapées. Voici par exemple, en France Braillenet^{[Note 25]}, HandicapZéro^{[Note 26]} ou encore WebSourd^{[Note 27]}.

Les organismes de labelisation

Des organismes de labelisation privés décernent des labels d'accessibilité. C'est le cas par exemple d'Accessiweb en France, d'Anysurfer en Belgique, de Technosite^{[Note 28]} en Espagne, d'AccessibilitéWeb au Québec, ou encore du label européen Euracert^{[Note 29]}. Certains de ces labels ne transcrivent pas l'intégralité des WCAG, tenant par exemple compte de l'obsolescence de points de contrôle des WCAG 1.0^{[W3C 23]}, et ajoutent des critères supplémentaires élevant le niveau d'exigence.

Les prestataires Web

Certains prestataires de services ou de conseil sont spécialisés dans l'accessibilité. Voici par exemple Vision Australia^{[Note 30]} ou WebAIM^{[Note 31]}.

L'accessibilité est une activité commerciale et un enjeu marketing pour des sociétés et quelquefois des associations qui commercialisent assistance et formations^{[réf.  nécessaire]}.

Législation et règlementation

Aux États-Unis

Une loi a été votée pour contraindre les agences fédérales à respecter les normes en vigueur dans ce pays. Cette loi, la Section 508 ne s'applique par conséquent pas aux services publics locaux. Elle n'est d'autre part pas une méthode d'application des directives mondiales, mais un standard national spécifique.

Au Canada

En mai 2000, le Conseil du Trésor du Canada a accepté les Normes et directives sur la Normalisation des sites Internet (NSI). Elles imposent à l'ensemble des institutions visées aux Parties 1, 1.1 et 2 de la Loi sur la gestion des finances publiques de se conformer aux règles d'accessibilité de la cellule web Accessibility Initiative (WAI/W3C WCAG 1.0) de priorité A et AA.

Dans l'Union européenne

L'accessibilité du web entre dans le cadre plus général de l'accessibilité numérique, sur laquelle la Commission européenne travaille.

Plusieurs États de l'Union européenne ont établi, ou sont sur le point d'établir, des législations plus ou moins contraignantes en matière d'accessibilité du web.

En France

En 1999, une circulaire du Premier ministre déclare que «Les responsables des sites [publics] veilleront tout spécifiquement à faciliter l'accessibilité de l'information à l'ensemble des internautes, surtout les personnes handicapées, non voyantes, malvoyantes ou malentendantes.»^{[Note 32]}.

En décembre 2003, un rapport d'étude mené dans le cadre du plan national de diffusion des nouvelles technologies auprès des personnes handicapées recommande surtout la création d'un «cadre général clair pour une meilleure prise en compte des critères d'accessibilité des sites», d'un «centre ressources pour le conseil et la formation» et enfin d'un «organisme officiel de certification, complètement habilité à effectuer ce type de travail par son indépendance»^{[Note 33]}.

En 2004 s'ouvre une première phase d'incitation à l'accessibilité des sites des services de l'État, des collectivités territoriales et des établissements publics : l'Agence pour le développement de l'administration électronique (ADÆ) adopte un «Référentiel accessibilité des services Internet de l'administration». Ce dernier est issu des travaux du centre de ressources et de recherche Accessiweb créé par l'association BrailleNet sur la base de la norme mondiale WCAG1.0, complétés par des préconisations ergonomiques^{[Note 34]}. Il n'a pas de caractère obligatoire. En 2005, l'obligation d'accessibilité du Web public est légalement créée par l'article 47 de la loi du 11 février (n^o 2005-102) pour «l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées», qui énonce : «Les services de communication publique en ligne des services de l'État, des collectivités territoriales et des établissements publics qui en dépendent doivent être accessibles aux personnes handicapées.»^{[Note 35]}. À cet effet, un nouveau cadre de référence, adapté à ce caractère d'obligation, est indispensable.

La Direction générale de la Modernisation de l'État (DGME) devient le moteur du projet en lançant en 2005 un appel d'offre auquel répondent deux sociétés privées, Temesis et Tektonika, pour la création du référentiel général d'accessibilité des administrations (RGAA). Complément du référentiel général d'interopérabilité, le RGAA est une méthode de déploiement progressif et d'évaluation de l'accessibilité des contenus web telle qu'elle est définie par la norme mondiale WCAG1.0, au niveau le plus élevé (AAA). Il ne prend par contre pas en compte l'impact des outils de production automatisée du Web, tel que le prévoit ATAG 2.0. Le RGAA a été adopté en octobre 2007 par le collège d'experts chargé de sa validation^{[Note 36]}. Il est conçu pour devenir l'arrêté annexe au décret d'application de la loi du 11 février 2005. Ce décret n'a pas toujours été publié.

Au Luxembourg

Au Luxembourg, le référentiel RENO (pour «référentiel de normalisation») adopté en 2008 intègre l'accessibilité dans une démarche qualité globale. Ce référentiel est intégré toujours aux cahiers des charges des projets web de l'État^{[Note 37]}.

L'état de l'accessibilité du Web

En 2005, l'étude eAccessibility of public sector services in the European Union menée par le Cabinet Office britannique et portant sur 436 sites Web d'administration publique des 25 pays membres de l'UE, évalue à 3% le nombre de sites qui répondent aux exigences de niveau A de WCAG1.0^{[Note 38]}. Ces résultats ont été confirmés en 2006 par une étude menée à l'initiative de l'Organisation des Nations unies sur les 100 plus importants sites privés (compagnies aérienne, banques, journaux et boutiques en ligne) ou publics (sites gouvernementaux) à travers 20 pays^{[Note 39]}.

Une étude menée en 2004 sur un échantillon de 1000 sites Web par la Disability Rights Commission britannnique identifiait les principaux manquements aux directives WCAG1.0^{[Note 40]} :

• l'absence d'alternatives pertinentes aux éléments graphiques et au javascript
• la présence de contenus en mouvement non contrôlables par l'utilisateur, et d'ouvertures de liens dans une nouvelle fenêtre du navigateur non anticipables par l'utilisateur,
• la présence de libellés de liens non explicites et de contenus rédigés dans un langage trop complexe selon le contexte.
• la structuration HTML insuffisante du contenu
• l'utilisation non accessible de la couleur comme véhicule de l'information

Aucune étude globale portant sur l'accessibilité des outils de production ou sur celle des agents utilisateurs n'est disponible.

Enfin, au-delà de la diversité des politiques nationales, on note la faiblesse de l'investissement dans les mesures incitatives, la formation des rédacteurs, développeurs et responsables de contenus Web, ou encore l'accréditation de prestataires et la certification de services et de sites. ^{[réf.  nécessaire]}

Références aux documents du W3C

1. ↑ (en) W3C, Introduction to Web Accessibility
2. ↑ (en) Different Disabilities that Can Affect Web Accessibility, How People with Disabilities Use the Web, W3C
3. ↑ (en) Assistive Technologies and Adaptive Strategies, How People with Disabilities Use the Web, W3C
4. ↑ (en) Essential Components of Web Accessibility, W3C
5. ↑ (en) Web Content Accessibility Guidelines 2.0, Appendix A : Glossary, W3C
6. ↑ (en) WAI Resource : HTML 4.0 Accessibility Improvements, W3C
7. ↑ (en) Accessibility Features of CSS, W3C
8. ↑ (en) Accessibility Information for Specific Technologies, W3C
9. ↑ (en) Web Content Accessibility Guidelines 1.0, W3C
10. ↑ (en) Web Content Accessibility Guidelines 2.0, W3C
11. ↑ (en) Authoring Tools Accessibility Guidelines 1.0, W3C
12. ↑ (en) Authoring Tool Accessibility Guidelines 2.0, W3C
13. ↑ (en) User Agent Accessibility Guidelines 1.0, W3C
14. ↑ (en) User Agent Accessibility Guidelines 2.0, W3C
15. ↑ (en) XML Accessibility Guidelines, W3C
16. ↑ (en) WAI-ARIA Overview, W3C
17. ↑ (en) Essential Components of Web Accessibility, W3C
18. ↑ (en) User Agent Support for Accessibility, W3C
19. ↑ (en) Involving Users in Web Accessibility Evaluation, W3C
20. ↑ (en) Conformance Evaluation of Web Sites for Accessibility, W3C
21. ↑ (en) Using Combined Expertise to Evaluate Web Accessibility, W3C
22. ↑ (en) Developing Organizational Policies on Web Accessibility, W3C
23. ↑ (en) Comparison of WCAG 1.0 checkpoints to WCAG 2.0, W3C

Autres références

1. ↑ (fr) Convention relative aux droits des personnes handicapées, ONU
2. ↑ L'accessibilité, de quoi s'agit-il ?, Livre Blanc, Microsoft
3. ↑ (en) Window-Eyes
4. ↑ Elie Sloïm, Laurent Denis, Pourquoi l'accessibilité numérique ? OpenWeb, 25 juillet 2005
5. ↑ (en) Relationship to other Best Practices and recommendations, Mobile Web Best Practices 1.0, W3C
6. ↑ (en) Michæl Cooper,, actes du Forum européen de l'accessibilité numérique, 29 janvier 2007.
7. ↑ C'est le cas surtout, en France, de l'organisme de labellisation Accessiweb. Voir la définition de l'accessibilité du web par Accessiweb
8. ↑ L'e-accessibilité comme composante de la qualité Web, Actes du séminaire Instruments pour faire de l'accessibilité du Web une réalité, Paris, 2006 et Laurent Denis et Elie Sloïm, 2005Pourquoi l'accessibilité numérique ?, Openweb,
9. ↑ (en) Michæl Cooper,, actes du Forum européen de l'accessibilité numérique, 29 janvier 2007.
10. ↑ (fr) La loterie du longdesc, The WHATWG Blog, septembre 2007
11. ↑ Accessiweb
12. ↑ Anysurfer
13. ↑ (en) Unified Web Evaluation Methodology
14. ↑ (en) Chris Law, Julie Jacko, Paula Edwards, Programmer-focused website accessibility evaluations, ACM SIGACCESS Conference on Assistive Technologies, Baltimore, 2005
15. ↑ (en) Rick Ells, University of Washington, Building Accessibility Into The Workflow, Higher Education Web Developers Conference, 2005
16. ↑ (en) Rick Ells, University of Washington, Building Accessibility Into The Workflow, Higher Education Web Developers Conference, 2005
17. ↑ (en) Rick Ells, University of Washington, Building Accessibility Into The Workflow, Higher Education Web Developers Conference, 2005
18. ↑ WAVE
19. ↑ OCAWA
20. ↑ (en) Michæl Cooper,, actes du Forum européen de l'accessibilité numérique, 29 janvier 2007.
21. ↑ Les nouveaux défis de l'accessibilité numérique : 1- la vision actuelle, Elie Sloïm, Openweb, 14 février 2008.
22. ↑ Les nouveaux défis de l'accessibilité numérique : 2- une autre vision de la démarche, Elie Sloïm, Openweb, 14 février 2008
23. ↑ A titre d'exemple, en France : Le Think Tank Renaissance Numérique tire la sonnette d'alarme et nomme le gouvernement à sortir enfin le décret d'application relatif à l'accessibilité des sites Web prévue dans la loi du 11 février 2005, Renaissance numérique, 22 janvier 2008
24. ↑ (en) Andy Clarke, Accessibility and a society of control, 18 juin 2005.
25. ↑ BrailleNet
26. ↑ HandicapZéro
27. ↑ WebSourd
28. ↑ (es) Technosite, Grupo Fundosa
29. ↑ Euracert, European eAccessibility Certification issu de ces trois organismes
30. ↑ (en) Vision Australia
31. ↑ (en) WebAIM
32. ↑ Circulaire du 7 octobre 1999 relative aux sites internet des services et des établissements publics de l'État
33. ↑ Julien Perben, Rapport d'étude sur l'accessibilité de l'Internet-Intranet aux personnes handicapées, Secrétariat d'État aux personnes handicapées, 2003.
34. ↑ (fr) Référentiel accessibilité des services Internet de l'administration française, version 2004 (format RTF)
35. ↑ Loi du 11 février 2005 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées
36. ↑ Validation du RGAA par le collège d'experts accessibilité
37. ↑ Publication de RENO, le nouveau référentiel de normalisation pour les sites web du Gouvernement luxembourgeois, eLuxembourg.
38. ↑ (en) eAccessibility of public sector services in the European Union
39. ↑ (en) Global Audit of Web Accessibility, ONU
40. ↑ (en) The Web : Access and Inclusion for Disabled People. A formal investigation conducted by the Disability Rights Commission, London, Disability Rights Commission, 2004 ISBN 0 11 703287 5

Lien externe

• (en) Web Accessibility Initiative (WAI), W3C

Ce texte est issu de l'encyclopédie Wikipedia. Vous pouvez consulter sa version originale dans cette encyclopédie à l'adresse http://fr.wikipedia.org/wiki/Accessibilit%C3%A9_du_Web.
Voir la liste des contributeurs.
La version présentée ici à été extraite depuis cette source le 11/03/2009.
Ce texte est disponible sous les termes de la licence de documentation libre GNU (GFDL).
La liste des définitions proposées en tête de page est une sélection parmi les résultats obtenus à l'aide de la commande "define:" de Google.
Cette page fait partie du projet Wikibis.