Accessibilité du web

L'accessibilité du web est la problématique de l'accès aux contenus et services web par les personnes handicapées (déficients visuels, sourds, malentendants, etc.) et plus généralement par tous les utilisateurs[W3C 1], quels que soient leurs dispositifs d’accès (mobile, tablette, etc.)[W3C 2] ou leurs conditions d’environnement (niveau sonore, éclairement, etc.).

Les pratiques d'accessibilité cherchent à réduire ou supprimer les obstacles qui empêchent les utilisateurs d'accéder à des contenus ou d'interagir avec des services. Par exemple, en ajoutant un texte de remplacement aux images, qui permet aux déficients visuels d'accéder à l'information même sans voir l'image.

L'accessibilité est 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 l'ensemble de ses acteurs, via des méthodes d'applications, des référentiels métiers et une démarche de suivi.

Bien qu'il soit une composante et un levier d'amélioration de leur qualité globale, le degré d'accessibilité effectif des sites web reste très faible en 2008[Note 1].

Champ de l'accessibilité

L'accessibilité du web est définie par la WAI[W3C 3] comme l'une des composantes de l'accessibilité numérique :

« L'accessibilité du web signifie que les personnes handicapées peuvent l'utiliser. Plus spécifiquement, elle signifie que ces gens peuvent percevoir, comprendre, naviguer, interagir avec le web, et y contribuer. L'accessibilité du web bénéficie également à d'autres, notamment les personnes âgées ayant des capacités diminuées dues au vieillissement[1]. »

C'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 2] « afin de permettre aux personnes handicapées de vivre de façon indépendante et de participer pleinement à tous les 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 et à la communication, y compris aux systèmes et technologies de l’information et de la communication, et aux autres équipements et services ouverts ou fournis 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 également des mesures appropriées pour [...] promouvoir l’accès des personnes handicapées aux nouveaux systèmes et technologies de l’information et de la communication, y compris l’Internet[2]. »

Contextes utilisateur
Exemple de technologie d'assistance : une plage braille munie d'un ordinateur embarqué, fonctionnant de manière autonome.
Cette autre plage braille n'offrant qu'une ligne de caractères braille s'utilise avec un ordinateur dont elle va reproduire l'affichage.

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

L'un des enjeux de la démarche d'accessibilité du 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 (fabricants de navigateurs web, créateurs de contenus, etc.).

Effets induits de l'accessibilité des contenus

Au-delà des bénéfices atteints pour les utilisateurs handicapés, l'accessibilité web profite plus largement à tous les utilisateurs et acteurs, notamment en ce qui concerne l'utilisabilité, la maîtrise de la production des contenus, les retours sur investissement[Note 5] et d'image.

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

Accessibilité des contenus ou accessibilité universelle ?

Certains acteurs de l'accessibilité web[Note 8] étendent leur champ au-delà de la question du handicap, à tous les contextes utilisateurs, en s'inspirant en particulier de l'objectif du « web pour tous »[W3C 6] donné au W3C par Tim Berners-Lee, inventeur du World Wide Web :

« Mettre le web et ses services à la disposition de tous les individus, quels que soient leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales[3]. »

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 également une composante[Note 9]. En fonction des solutions techniques et de l'état de l'art, des arbitrages peuvent être nécessaires entre investir dans l'optimisation de l'accessibilité ou dans d'autres aspects qualitatifs tels que les contenus eux-mêmes, l'innovation, le référencement, l'ergonomie ou l'interopérabilité.

Les interfaces vocales comme Google Assistant ou Alexa d'Amazon posent des problèmes spécifiques d'accessibilité. En , Google lance le projet Euphonia afin d'améliorer la reconnaissance vocale pour les personnes ayant un trouble de la parole[4].

Normes d'accessibilité internationales

L'accessibilité web dépend de plusieurs composantes interdépendantes[W3C 7] :

  • le contenu web, c'est-à-dire « l'ensemble 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 8] ;
  • les agents utilisateurs qui exploitent le contenu et le restituent aux internautes : navigateurs, plugins, etc. ;
  • les technologies d'assistance 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, de technologies d'assistance, 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 Web Accessibility Initiative (WAI) 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 favoriser la production d'un contenu accessible. Il s’ensuit qu'ils doivent suivre des lignes de conduite particulières ; 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 que l'on entend habituellement par l'accessibilité du web et dont les recommandations sont regroupées dans les Web Content Accessibility Guidelines ;
  3. afin de tirer parti de ce contenu accessible, les outils de consultation (par exemple les navigateurs web) 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 également lors de l'élaboration de toutes les spécifications du W3C afin de 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 9] ainsi que des feuilles de style en cascade (CSS)[W3C 10]. Enfin, d'autres recommandations en chantier sont consacrées notamment au interfaces riches, ou à XML, SVG et SMIL[W3C 11].

Recommandations pour le contenu

Les recommandations en ce qui concerne le contenu s'adressent à tous les distributeurs de contenu sur le web. Ces directives se nomment les Web Content Accessibility Guidelines. Succédant aux WCAG 1.0 publiées en 1999[W3C 12], les WCAG 2.0 sont la recommandation officielle depuis le [W3C 13].

WCAG 1.0

WCAG 1.0 comporte 14 directives dont les 11 premières visent à assurer une transformation élégante du contenu dans les différents contextes utilisateurs[W3C 14] :

  1. fournir des alternatives équivalentes aux contenus visuels et auditifs (images statiques ou animées, contenus audio et vidéo) ;
  2. ne pas s'en remettre exclusivement aux couleurs ;
  3. utiliser le balisage HTML et les feuilles de styles CSS de façon appropriée ;
  4. clarifier l'utilisation du langage naturel ;
  5. créer des tableaux HTML qui se transforment de façon élégante ;
  6. s'assurer que les pages qui contiennent de nouvelles techniques (objets programmables, styles CSS) se transforment de façon élégante ;
  7. assurer à l'utilisateur le contrôle des changements du contenu lorsque ce dernier varie dans le temps (clignotements, mouvements, rafraîchissement du contenu, redirections) ;
  8. assurer un accès direct aux interfaces utilisateur intégrées (objets Flash, applets JAVA) ;
  9. concevoir de manière indépendante du périphérique (souris, clavier, tactile , etc.) ;
  10. utiliser des solutions intermédiaires en attendant que les agents utilisateurs aient un meilleur support de l'accessibilité ;
  11. utiliser les technologies et directives du W3C.

Les trois visent à rendre le contenu compréhensible et navigable :

  1. fournir des informations de contexte et d'orientation ;
  2. fournir des mécanismes de navigation clairs ;
  3. s'assurer que les pages sont claires et simples.

Chaque directive détermine un ou plusieurs points de contrôles. Par exemple, la directive 2 demande de « ne pas s'en remettre exclusivement aux couleurs »[W3C 15] et prévoit à cet effet deux points de contrôle :

  1. « s’assurer que toute information convoyée par des couleurs est également accessible sans couleur, par exemple à partir du contexte ou de balises » ;
  2. « s’assurer que la combinaison de couleurs entre le premier plan et l’arrière-plan utilise suffisamment de contraste lorsqu’elle est utilisée par des personnes souffrant d’un déficit de perception des couleurs ou sur un écran noir et blanc ».

Les 65 points de contrôle WCAG 1.0 concernent les thématiques des contenus (images, objets programmables, objets multimédia), des structures (tableaux, cadres, titres), du graphisme et de la mise en forme (couleurs, séparation de la structure et de la présentation), de l'interactivité et de la navigation (liens, formulaires, redirections).

Chaque point de contrôle s'est vu attribuer un degré de priorité, en fonction des impossibilités ou des difficultés d'accès qu'il permet de lever. La validation de tous les points de contrôle d'un degré donné et des degrés inférieurs détermine le niveau d'accessibilité du site concerné :

Les niveaux d'accessibilité WCAG 1.0
Priorité Obligation Portée Niveau d'accessibilité Exemple
1 Ce qui doit être fait. Lève les barrières obstructives à l'accès aux contenus Niveau A (respect des points de contrôle de priorité 1) Toute information véhiculée par la couleur est également perceptible sans couleur.
2 Ce qui devrait être fait Lève d'autres barrières significatives Niveau AA (respect des points de contrôle de priorité 1 et 2) Les contrastes de couleurs entre avant-plan et arrière-plan sont suffisants dans les images.
3 Ce qui peut être fait Améliore le confort d'accès Niveau AAA (respect des points de contrôle de priorité 1, 2 et 3) Les contrastes de couleurs entre avant-plan et arrière-plan sont suffisants dans les textes.

L'exemple de la couleur illustre la manière de répartir des points de contrôle par niveau de priorité :

  • au niveau de priorité le plus élevé : une information véhiculée uniquement par une couleur, telle que dans la légende d'une carte, ne sera pas perceptible pour de nombreux types d'utilisateurs (par exemple, les personnes aveugles utilisant un lecteur d'écran) ;
  • au niveau intermédiaire, un degré de contraste insuffisant dans une image rendra celle-ci difficilement compréhensible pour des utilisateurs daltoniens ou plus généralement malvoyants, bien qu'une technologie d'assistance puisse éventuellement améliorer le rendu de l'image. Par exemple, une écriture sur un fond de même intensité lumineuse sera invisible pour un achromate ;
  • au niveau de priorité le moins élevé, assurer un degré de contraste suffisant dans les textes HTML évite aux utilisateurs malvoyants d'avoir à désactiver les styles de présentation du site pour être certains de pouvoir lire aisément ceux-ci.

Les points de contrôle sont donc la base de la validation WCAG 1.0.

WCAG 2.0

Alors que les WCAG 1.0 concernent principalement les contenus HTML, les WCAG 2.0 font abstraction de la technologie spécifiquement utilisée et ont pour objectifs d'être[W3C 16] :

  • applicables à toutes les technologies actuelles et futures de conception de pages web, qu'il s'agisse de technologies du W3C comme CSS, XML et SMIL ou d'autres technologies telles que Flash, Silverlight ou PDF. WCAG 2.0 adopte à cet effet le concept de « technologie compatible avec l'accessibilité », défini par le fait qu'une technologie est conçue de manière à permettre aux agents utilisateurs d'accéder à toute l'information nécessaire pour restituer le contenu à l'utilisateur de manière appropriée, et que les agents utilisateurs et les technologies d'assistance aient été adaptés à l'usage de cette technologie[W3C 17]. WCAG 2.0 tient ainsi compte de l'évolution des services web et de l'émergence des interfaces enrichies : une des ruptures les plus notables avec WCAG 1.0 est que JavaScript est désormais reconnu comme une technologie compatible avec l'accessibilité, qui ne nécessite donc plus d'alternative pour les agents utilisateurs n'en ayant pas le support[W3C 18]. Là où WCAG 1.0 recourait au bannissement de technologies considérées comme non accessibles, WCAG 2.0 privilégie le développement de l'interopérabilité[Note 10] et autorise l'utilisation de technologies non accessibles dans la mesure où elles n'interfèrent pas avec l'information équivalente fournie par ailleurs via les technologies accessibles ;
  • plus aisées à comprendre et à utiliser. Pour cela, les WCAG 2.0 sont dotées d'un guide d'implémentation, Understanding WCAG 2.0[W3C 19] et d'un exemple de méthode d'application dans le cadre XHTML CSS, les Techniques for WCAG 2.0 ;
  • plus aptes à l'évaluation humaine ou logicielle grâce à des critères de succès explicites et testables, afin de répondre aux besoins en matière de préconisations lors de la conception de site, d'évaluation de la conformité des solutions, de règlementation et d'accords contractuels[W3C 20].

WCAG 2.0 adopte également une approche thématique plus rigoureuse en structurant 12 directives principales selon 4 principes fondamentaux :

  1. Des contenus perceptibles :
    • fournir des alternatives textuelles à tous les contenus non textuels, de sorte qu'ils puissent être adaptés sous une forme répondant aux besoins des utilisateurs,
    • fournir des alternatives synchronisées aux médias synchronisés,
    • créer du contenu qui puisse être mis en forme de différentes manières sans perte d'information ou de structure,
    • permettre aux utilisateurs de voir et d'entendre plus facilement le contenu, notamment en séparant avant-plan et arrière-plan ;
  2. Des contenus utilisables :
    • rendre toutes les fonctionnalités utilisables au clavier,
    • garantir aux utilisateurs handicapés un temps suffisant pour comprendre et utiliser le contenu,
    • ne pas mettre en forme le contenu d'une manière connue comme entraînant des dommages,
    • fournir des aides aux utilisateurs handicapés pour naviguer, rechercher du contenu et se situer dans ceux-ci ;
  3. Des contenus compréhensibles :
    • fournir des textes lisibles et compréhensibles,
    • permettre aux pages web d'apparaître et de se comporter de manière prévisible,
    • aider les utilisateurs à rectifier leurs erreurs ;
  4. Des contenus robustes :
    • optimiser la compatibilité avec les agents utilisateurs actuels et futurs, y compris les technologies d'assistance.

Chacune des douze directives se décompose en un ou plusieurs « critère de succès » de niveau A, AA ou AAA, qui deviennent la base d'évaluation d'accessibilité du site. Pour chaque critère de succès, WCAG 2.0 indique des « techniques suffisantes et indicatives » qui fournissent un guide limité à XHTML CSS, sans pour autant faire dépendre la conformité ni de l'emploi exclusif de ces formats, ni des techniques spécifiquement détaillées pour ceux-ci[W3C 21].

La définition des trois niveaux d'accessibilité tient désormais compte de leur faisabilité :

Les niveaux d'accessibilité WCAG 2.0
Niveau Objectif Faisabilité Exemple
A Atteindre un niveau d'accessibilité minimal. Critères de succès essentiels pouvant raisonnablement s'appliquer à toutes les ressources web. La couleur n'est pas le seul moyen visuel de véhiculer l'information.
AA Améliorer le niveau d'accessibilité Critères de succès supplémentaires pouvant raisonnablement s'appliquer à toutes les ressources web. Les textes de petite taille ont un ratio de contraste au moins égal à 4.5
AAA Atteindre un niveau supérieur d'accessibilité. Critères de succès ne s'appliquant pas à toutes les ressources web. Les textes de petite taille ont un ratio de contraste au moins égal à 7

WCAG 2.0 entérine enfin le choix du niveau AA comme objectif des politiques d'accessibilité globale, le niveau AAA n'étant pertinent que pour certains projets, en fonction des contenus spécifiques qui sont concernés[W3C 22].

Cette évolution a été contestée par certains experts, à l'initiative de Joe Clark[Note 11] qui a récusé le mode de fonctionnement de la WAI pour privilégier une mise à jour de WCAG 1.0, sous la forme d'un errata WCAG 1.0 réalisé indépendamment de la WAI par le projet WCAG Samurai[Note 12].

Recommandations pour interfaces riches

L'essor des services et applications en ligne reposant sur l'utilisation croissante de technologies hybrides telles que JavaScript, AJAX et SVG, l'élaboration par la WAI de l'Accessible Rich Internet Applications Suite (ARIA) vise à mettre en place le cadre normatif nécessaire à l'accessibilité des applications web dynamiques[W3C 23].

Quelques éditeurs mettent à disposition des acteurs de l'accessibilité des bibliothèques de techniques accessibilisées en tout ou en partie. C'est notamment le cas de Dojo, de jQuery (avec notamment une implémentation d'ARIA dans le module jQuery Mobile, dans le code généré par l'API) ou encore de YUI[Note 13].

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, logiciels de publication de site web créant le code HTML, systèmes de gestion de contenu et blogues sont les Authoring Tools Accessibility Guidelines dans leur version 2.0, datant de [W3C 24].

ATAG 2.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 l'essentiel aux directives d'accessibilité des contenus web, et qui dépend :
    • de sa compatibilité avec les technologies d'assistance,
    • de sa capacité à être perceptible,
    • de sa capacité à être utilisable,
    • de sa capacité à être compréhensible ;
  • la capacité des outils à favoriser 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 favoriser celle-ci d'une manière générale.

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 donc entre métiers de rédacteur et d'intégrateur. Dès lors, une responsabilité croissante incombe aux outils de production pour assurer autant que possible, et de manière aussi transparente que possible, le respect des directives d'accessibilité des contenus[Note 14]. 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

Afin de 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é écrites les User Agent Accessibility Guidelines 1.0[W3C 25]. Les travaux continuent dans le cadre d'une nouvelle version en cours d'élaboration, les UAAG 2.0[W3C 26].

UAAG 2.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.

Cycles d'implémentation de l'accessibilité

L'interdépendance entre les composantes du web permet à une amélioration de l'accessibilité pour l'une d'entre elles d'entraîner des améliorations en chaîne[W3C 27]. 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 lorsqu'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 alors se poser de son maintien dans les normes techniques du web, comme dans le cas des descriptions étendues d'images dans le format HTML5[Note 15].

Déploiement, évaluation et suivi

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 WCAG 1.0, dont le contenu a été fixé en 1999, nécessite des adaptations à l'évolution des technologies (sont en particulier concernés 5 points de contrôle initialement définis en réponse à des défauts temporaires d'implémentation de la part des agents utilisateurs[W3C 28]). WCAG 2.0 renforce ce besoin de par son caractère générique. La prise en compte de ces directives nécessite donc 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 16] (France) et Anysurfer[Note 17] (Belgique) sont des méthodes produites par des organismes de labellisation privés, inspirées des WCAG 2.0 ;
  • le référentiel général d'accessibilité pour les administrations (RGAA) (France) est un référentiel public de déploiement des WCAG 2.0 ;
  • la « méthodologie unifiée d'évaluation de l'accessibilité du web » (UWEM)[Note 18] est une méthode européenne permettant une évaluation de l'application de WCAG 1.0 aux niveaux A et AA.

Les directives ATAG peuvent s'appuyer partiellement sur les méthodes d'application de WCAG. Une méthode d'application ATAG 1.0 a été développée en France au sein d'Accessiweb[Note 19]. Concernant ATAG 2.0, des techniques d'implémentation sont en cours de rédaction[W3C 29].

Démarche globale

Les recommandations du WAI, de portée internationale, 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 fréquentes des développeurs après réception d'une évaluation d'accessibilité est qu'il aurait été beaucoup 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 possible lors de la conception d'un site est une économie de temps et d'argent, par comparaison à des corrections après-coup. »[Note 20].

Ceci peut concerner notamment l'utilisation des bases documentaires, le choix d'un système 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 en particulier 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 21] à travers l'utilisation de la couleur et des éléments graphiques comme véhicule de l'information, mais aussi en raison des contraintes d'intégration qu'elle peut induire 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é en particulier à travers[Note 22] ses choix de technologies (AJAX, Flash, JavaScript), 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 : 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 23] :

  • 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 aussi utilisables par les technologies d'assistance grâce à la qualité de leur structure HTML ;
  • plus généralement leur utilisation de la solution de publication et de l'assistance qu'elle leur apporte pour la production de contenu accessibles.

Outils automatiques
Cette section ne cite pas suffisamment ses sources (mai 2010). 
Pour l'améliorer, ajoutez des références vérifiables [comment faire ?] ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

Un certain nombre des points de contrôle des WCAG étant automatisables, de nombreux outils ont été mis au point afin de faciliter 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, afin de faciliter 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, à l'aide des outils de vérification de l'accessibilité. Ceux-ci sont le plus souvent des services en ligne. Certains fournissent un retour sous forme d'icônes ajoutées à la page évaluée (par exemple, WAVE[Note 24]), tandis que d'autres fournissent un rapport textuel (OCAWA, développé en collaboration avec France Télécom[Note 25]). L'évaluation, le plus souvent limitée en nombre de pages, est davantage destinée à des audits d'échantillon qu'au suivi des contenus. Cependant, quelques solutions comme IBM Rational Policy Tester[Note 26] permettent une évaluation systématique et continue des contenus de l'ensemble d'un site ou d'un parc de sites.

Dans les deux cas d'automatisation néanmoins, la plupart 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 dispositif de rendu... ne sont pas automatisables, ou ne le sont que partiellement sous forme d'assistance à la validation humaine. Le nombre d'alertes de principe sur les points nécessitant une vérification peut être très élevé, et rendre difficile l'exploitation des résultats en masquant les signalements d'erreurs les plus pertinents.

Ces outils automatiques ne peuvent donc être à eux seuls des garants de l'accessibilité ; en revanche, ils constituent 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 permettant de se consacrer aux points de contrôle d'un abord plus délicat. Ils permettent également de mettre en place des indicateurs globaux : ainsi l'EIAO (European Internet Accessibility Observatory) a pu mener en 2008 une étude sur l'accessibilité de 2 317 sites web européens grâce à un moteur d'évaluations automatisées sur la base de 26 tests issus de WCAG 1.0 (indicateur WAM ou Web Accessibility Metric)[Note 27]. L'intérêt et les limites de ce processus automatisé sont ainsi résumées[Note 28] :

« Un processus entièrement automatisé d'évaluation de l'accessibilité a plusieurs avantages évidents sur les évaluations purement manuelles. L'EIAO a pu traiter et évaluer un bien plus grand nombre de sites que n'aurait pu le faire un expert. En outre, les évaluations sont répétables, ce qui autorise la comparaison d'un mois sur l'autre. Enfin, contrairement au travail de l'expert, les résultats ne sont pas influencés par des facteurs humains tels que l'expérience du site acquise par l'expert.

En revanche, l'EIAO a ses désavantages. Principalement, il ne peut apporter le même niveau de détail qu'un expert. Ensuite, le robot ne peut évaluer des pages protégées par un mot de passe. Enfin, l'évaluation des contenus Web nécessitant une interaction utilisateur (Flash, Javascript) n'est pas supportée. »

Tests utilisateurs

Le recours à des tests d'accessibilité d'un site impliquant des personnes handicapés peut apporter plusieurs bénéfices, dont en particulier[W3C 30] :

  • permettre aux développeurs d'outils de production et 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é.

Ces tests utilisateurs sont au cœur de certaines procédures de labellisation, telles que celle du label suisse « Accès pour Tous »[Note 29]. 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 31].

Évaluation experte

Évaluer le degré d'accessibilité d'un site web nécessite davantage que ne peut fournir un outil automatisé. L'évaluation exige en effet une compréhension approfondie des techniques web, des outils de validation, des directives d'accessibilité, des technologies d'assistance et des agents utilisateurs, ainsi que des stratégies auxquelles recourent les personnes handicapées dans leur usage du web[W3C 32].

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 à grande é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 30].

Définition d'une politique d'accessibilité selon la WAI

Selon la WAI, une politique d'accessibilité se définit par[W3C 33] :

  • 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 fournis 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 niveaux A puis AA et éventuellement AAA) ou sélectif (priorité accordée à certaines parties du site). Il peut également s'appliquer à l'intégration de l'accessibilité dans les outils de conception et à 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é en fonction de 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 encore largement dominée par un modèle artisanal alors qu'elle est maintenant 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 nécessaire 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 rencontre cependant aujourd'hui ses limites sur le plan des difficultés de mise en œuvre[Note 31] et d'absence de gestion du risque dans le cadre d'une démarche qualité[Note 32] à l'échelle d'importants parcs de sites.

Déclarations de conformité

La politique d'accessibilité définie par la WAI repose sur une auto-déclaration de conformité optionnelle. Celle-ci est datée et porte sur une page ou un ensemble de pages, et non globalement sur le site. Son contenu minimal est défini par le standard WCAG 2.0 et comporte en particulier[W3C 34] :

  • la référence précise aux règles WCAG concernées et à leur version ;
  • la liste ou le descriptif des pages évaluées ;
  • la liste des technologies dont dépend l'utilisation des contenus et dont l'utilisation doit être compatible avec l'accessibilité ;
  • le niveau de conformité atteint (A, AA ou AAA).

Cette démarche est reprise par plusieurs politiques publiques d'accessibilité. Ainsi, en France, l'attestation de conformité RGAA est également une auto-déclaration faite par les responsables du site. Elle reprend l'essentiel des éléments précédents, et y ajoute la liste des agents utilisateurs et technologies d'assistance utilisées pour vérifier l'accessibilité des contenus ainsi que la justification des éventuelles dérogations[Note 33]

Certifications d'accessibilité

Des certifications d'accessibilité d'un site, ou labels, accordées par un tiers de confiance, existent dans plusieurs pays. Étant en dehors des processus de certification normalisés usuels, elles reposent sur[Note 34] :

  • un référentiel qui peut être le standard WCAG 2.0 lui-même (par exemple le label suisse Accès pour tous) ou une méthode d'application de celui-ci (par exemple le label français Accessiweb) ;
  • l'organisme certificateur chargé de contrôler l'application du référentiel et de délivrer le certificat. Sa réputation et sa crédibilité jouent un rôle majeur dans la valeur du label.

Ces certifications sont établies à partir d'un audit initial des contenus. Accordées pour une durée de deux ans en général, elles comportent des visites de contrôles et exigent le plus souvent la mise en place d'un canal de plainte. Elles n'imposent pas d'obligation de moyens et ne valident que le résultat en ligne.

Acteurs de l'accessibilité

É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[Note 35]. 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 36]. Elle suscite parfois des réserves de la part de certains d'entre eux[Note 37].

Associations d'usagers et d'acteurs du web

Des associations agissent pour promouvoir l'accessibilité du web aux personnes handicapées. En France il s’agit notamment de Braillenet[Note 38], HandicapZéro[Note 39], l’association Valentin Haüy[Note 40] ou encore Websourd[Note 41].

Organismes de formation

La formation des développeurs et des contributeurs web est l'une des clés pour améliorer l'accessibilité. La plateforme France Université Numérique et l'INRIA learning lab ont créé le MOOC "Accessibilité numérique" afin de former l'ensemble des acteurs francophones de l'accessibilité du web[5] et de mettre à disposition un certain nombre de ressources pédagogiques[6]

Organismes de labellisation

Des organismes de labellisation privés décernent des labels d'accessibilité. En Europe, c'est le cas du RNIB[Note 42] au Royaume-Uni, de BrailleNet (avec son label Accessiweb) en France, d'Anysurfer[Note 43] en Belgique, de Technosite[Note 44] en Espagne ou encore du label européen Euracert[Note 45]. Aux États-Unis, des certifications sont proposées par WebAIM[Note 46] ou encore la National Federation of the Blind[Note 47].

Dans leurs premières versions, certains de ces labels ne transcrivaient pas l'intégralité des WCAG, tenant par exemple compte de l'obsolescence de points de contrôle des WCAG 1.0[W3C 35], ou ajoutaient des critères supplémentaires élevant le niveau d'exigence. La publication de WCAG 2.0 conduit à des mises à jour qui s'accompagnent d'une volonté de prise en compte plus complète de la norme internationale[Note 48].

Prestataires web

Certains prestataires de services ou de conseil sont spécialisés dans l'accessibilité, ou proposent des services destinés à améliorer l'accès à l'information pour les personnes en situation de handicap.

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

Responsables de sites

Les responsables de sites web ont un rôle majeur dans la pérennisation de l'accessibilité du web.

Ils doivent, en se basant sur un référentiel spécifique WCAG, AccessiWeb ou RGAA, veiller à la bonne application des normes internationales du W3C.

Des compétences en matière de développement web et une expertise certifiée dans l'accessibilité numérique sont nécessaires pour maintenir une accessibilité de qualité, notamment lors du développement d'un site web, afin que les personnes déficientes visuelles puissent accéder à l’information normalement.

Le responsable de sites web est donc le garant d'une information correctement distribuée et présentée pour des internautes ayant ou non un handicap, et ceux, sans que cette information présente une perte, une altération et/ou une difficulté d'accès.

Grand public

Chaque personne (simple particulier, salarié d’une entreprise, agent d’une administration...) amenée à alimenter un site personnel, un blog, ou les pages d’un site professionnel dans le cadre d’un système de gestion de contenu (CMS) a un rôle à jouer pour contribuer à l’accessibilité du web. Cela a conduit l’association Valentin Haüy à mettre à disposition du grand public des recommandations visant d’une part à l’accessibilité du web[Note 49], d’autre part à l’accessibilité des documents[Note 50] échangés par courriel ou téléchargés depuis des sites web.

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 donc pas aux services publics locaux. Elle n'est d'autre part pas une méthode d'application des directives internationales, mais un standard national spécifique.

Au Canada

En , le conseil du Trésor du Canada a approuvé les normes et directives sur la normalisation des sites Internet (NSI). Elles imposent à toutes les 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 particulièrement à favoriser l'accessibilité de l'information à tous les internautes, notamment les personnes handicapées, non voyantes, malvoyantes ou malentendantes. »[Note 51].

En , un rapport d'étude mené dans le cadre du plan national de diffusion des nouvelles technologies auprès des personnes handicapées recommande notamment 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, totalement habilité à effectuer ce type de travail par son indépendance »[Note 52].

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 (ADAE) adopte un « Référentiel accessibilité des services Internet de l’administration ». Celui-ci est issu des travaux du centre de ressources et de recherche Accessiweb créé par l'association BrailleNet sur la base de la norme internationale WCAG 1.0, complétés par des préconisations ergonomiques. 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 (no 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 53].

La direction générale de la modernisation de l'État (DGME), actuelle direction interministérielle de la transformation publique, devient le moteur du projet pour la création du référentiel général d'accessibilité pour les administrations (RGAA), publié dans sa version finale en [Note 54]. Complément du référentiel général d'interopérabilité, le RGAA est une traduction en français de la norme WCAG 2.0, complétée par un guide d'accompagnement. Celui-ci présente une méthode de déploiement par critère de succès WCAG et un référentiel de tests d'évaluation de l'accessibilité des contenus web. Le RGAA ne prend en revanche pas en compte l'impact des outils de production automatisée du web, tel que le prévoit ATAG 2.0. Par l'arrêté[Note 55] du , la version 3.0 du RGAA est adoptée. Elle est une évolution majeure du référentiel, en fournissant notamment de nombreux documents d’accompagnement.

En 2016, une étude montre que les sites web des entreprises françaises sont encore peu accessibles pour les internautes handicapés[7].

Au Luxembourg

Au Luxembourg, le Référentiel Renow (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é systématiquement aux cahiers des charges des projets web de l'État[Note 56].

En Suisse

Les offices fédéraux sont contraints par la loi LHand et la constitution de respecter la norme W3C WCAG 2.0 du niveau de conformité AA pour tous les sites Internet, qui sont contrôlés régulièrement par l’administration fédérale. Pour les cantons et les communes, les standards sont variables[8].

Si la Constitution de la Confédération suisse interdit la discrimination en raison d'un handicap physique, intellectuel ou psychique, les institutions publiques et les entreprises privées n'ont pas les mêmes contraintes. Hormis les entreprises conventionnées et les entreprises de transports publics, soumises à une obligation de validation de la part de la Confédération, les entreprises privées sont légalement moins sollicitées pour rendre leurs sites accessibles[8].

É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 WCAG 1.0[Note 57]. 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ériennes, banques, journaux et boutiques en ligne) ou publics (sites gouvernementaux) à travers 20 pays[Note 58].

Une étude menée en 2004 sur un échantillon de 1 000 sites web par la Disability Rights Commission britannique identifiait les principaux manquements aux directives WCAG 1.0[Note 59] :

  • 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 en fonction du 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[Note 60].[réf. incomplète]

Notes et références

Références aux documents du W3C
  1. (en) W3C, Web Content Accessibility Guideline 1.0(1999), traduction française Directives pour l’accessibilité aux contenus Web (version 1.0).
  2. (en) W3C, Mobile Web Best Practices 1.0 (2008).
  3. (en) W3C, Introduction to Web Accessibility.
  4. (en) Different Disabilities that Can Affect Web Accessibility – How People with Disabilities Use the Web, W3C.
  5. (en) Assistive Technologies and Adaptive Strategies – How People with Disabilities Use the Web, W3C.
  6. (en) W3C Mission.
  7. (en) Essential Components of Web Accessibility, W3C.
  8. (en) Web Content Accessibility Guidelines 2.0 – Appendix A: Glossary, W3C.
  9. (en) WAI Resource: HTML 4.0 Accessibility Improvements, W3C.
  10. (en) Accessibility Features of CSS, W3C.
  11. (en) Accessibility Information for Specific Technologies, W3C.
  12. (en) Web Content Accessibility Guidelines 1.0, W3C.
  13. (en) Web Content Accessibility Guidelines 2.0, W3C.
  14. (en) Themes of Accessible Design – WCAG1.0, W3C.
  15. (en) Guideline 2, WCAG1.0, W3C.
  16. (en) Requirements for WCAG 2.0 – W3C Working Group Note 25 April 2006.
  17. (en) Understanding WCAG 2.0 – Understanding Accessibility Support.
  18. (en) Comparison of WCAG 1.0 Checkpoints to WCAG 2.0, in Numerical Order.
  19. (en) Understanding WCAG 2.0 – A guide to understanding and implementing WCAG 2.0.
  20. (en) Web Content Accessibility Guidelines (WCAG) 2.0 – WCAG 2.0 Layers of Guidance.
  21. (en) Understanding WCAG 2.0 – Sufficient and Advisory Techniques.
  22. (en) Web Content Accessibility Guidelines (WCAG) 2.0 – Conformance Requirements.
  23. (en) WAI-ARIA Overview, W3C.
  24. (en) Authoring Tools Accessibility Guidelines 2.0, W3C.
  25. (en) User Agent Accessibility Guidelines 1.0, W3C.
  26. (en) User Agent Accessibility Guidelines 2.0, W3C.
  27. (en) Essential Components of Web Accessibility, W3C.
  28. (en) User Agent Support for Accessibility, W3C.
  29. (en) Implementing ATAG 2.0 – A guide to understanding and implementing Authoring Tool Accessibility Guidelines 2.0.
  30. (en) Involving Users in Web Accessibility Evaluation, W3C.
  31. (en) Conformance Evaluation of Web Sites for Accessibility, W3C.
  32. (en) Using Combined Expertise to Evaluate Web Accessibility, W3C.
  33. (en) Developing Organizational Policies on Web Accessibility, W3C.
  34. (en) Web Content Accessibility Guidelines (WCAG) 2.0 – Conformance Claims.
  35. (en) Comparison of WCAG 1.0 checkpoints to WCAG 2.0, W3C.

Références
  1. (en) Voir par exemple le rapport Measuring Progress of eAccessibility in Europe publié en mai 2008.
  2. (fr) Convention relative aux droits des personnes handicapées, ONU.
  3. « L'accessibilité, de quoi s'agit-il ? », Livre Blanc, Microsoft.
  4. (en) Window-Eyes.
  5. Élie Sloïm, Laurent Denis, « Pourquoi l'accessibilité numérique ? » OpenWeb, 25 juillet 2005.
  6. (en) Relationship to other Best Practices and recommendations, Mobile Web Best Practices 1.0, W3C.
  7. (en) Michael Cooper, Web Accessibility in the Future « Copie archivée » (version du 21 octobre 2007 sur l'Internet Archive), actes du Forum européen de l'accessibilité numérique, 29 janvier 2007.
  8. C'est le cas notamment, en France, de l'organisme de labellisation Accessiweb.
  9. 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. Laurent Denis et Élie Sloïm, 2005 « Pourquoi l'accessibilité numérique ? », Openweb, 25 juillet 2005.
  10. (fr) Richard Schwerdtfeger, L'accessibilité des applications Web et des services en ligne riches (ARIA) « Copie archivée » (version du 21 octobre 2007 sur l'Internet Archive), actes du Forum européen de l'accessibilité numérique, 29 janvier 2007.
  11. (en) Joe Clark, « To Hell with WCAG 2 », Alist Apart, 23 mai 2006.
  12. (en) WCAG Samurai.
  13. (en) Steve Faulkner, WAI-ARIA Implementation in JavaScript UI Libraries - updated, The Paciello Group Blog, juillet 2009.
  14. (en) Michael Cooper, Web Accessibility in the Future « Copie archivée » (version du 21 octobre 2007 sur l'Internet Archive), actes du Forum européen de l'accessibilité numérique, 29 janvier 2007.
  15. (fr) « La loterie du longdesc », The WHATWG Blog, septembre 2007.
  16. Accessiweb.
  17. Anysurfer.
  18. (en) Unified Web Evaluation Methodology.
  19. « Référentiel AccessiWeb CMS 1.0 », braillenet.org, octobre 2009.
  20. (en) Chris Law, Julie Jacko, Paula Edwards, Programmer-focused website accessibility evaluations, ACM SIGACCESS Conference on Assistive Technologies, Baltimore, 2005.
  21. (en) Rick Ells, University of Washington, Building Accessibility Into The Workflow, Higher Education Web Developers Conference, 2005.
  22. (en) Rick Ells, University of Washington, Building Accessibility Into The Workflow, Higher Education Web Developers Conference, 2005.
  23. (en) Rick Ells, University of Washington, Building Accessibility Into The Workflow, Higher Education Web Developers Conference, 2005.
  24. WAVE.
  25. OCAWA.
  26. Rational Policy Tester Accessibility Edition, IBM.
  27. (en) European Internet Accessibility Observatory.
  28. (en) [PDF] Christian Bühler, Helmut Heck, Annika Nietzio, Morten Goodwin Olsen et Mikael Snapru, Monitoring Accessibility of Governmental Web Sites in Europe, EIAO, 2008.
  29. « Procédure de test - Label de sites Web accessibles »(Archive • Wikiwix • Archive.is • Google • Que faire ?), Accès pour Tous.
  30. (en) Michael Cooper, Web Accessibility in the Future « Copie archivée » (version du 21 octobre 2007 sur l'Internet Archive), actes du Forum européen de l'accessibilité numérique, 29 janvier 2007.
  31. Élie Sloïm, « Les nouveaux défis de l'accessibilité numérique : 1- la vision actuelle », Openweb, 14 février 2008.
  32. Élie Sloïm, « Les nouveaux défis de l'accessibilité numérique : 2- une autre vision de la démarche », Openweb, 14 février 2008.
  33. [PDF] Guide d’accompagnement au RGAA, DGME, 2009 (PDF - 0,7 Mo).
  34. Élie sloïm, Temesis, « Certifications de sites et labels », 29 novembre 2007.
  35. « Lois, législations et politiques sur l'accessibilité du Web (secteur public et privé) », Ressources accessibilité, Ideose.
  36. À titre d'exemple, en France : « Le Think Tank Renaissance Numérique tire la sonnette d'alarme et appelle 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.
  37. (en) Andy Clarke, « Accessibility and a society of control », 18 juin 2005.
  38. BrailleNet.
  39. HandicapZéro.
  40. Association Valentin Haüy accessibilité numérique.
  41. WebSourd.
  42. (en) « Site audits », RNIB.
  43. Anysurfer.
  44. (es) Technosite, Grupo Fundosa.
  45. Euracert, European eAccessibility Certification.
  46. (en) WebAIM.
  47. (en) « « NFB Nonvisual Accessibility Web Certification », NFB »(Archive • Wikiwix • Archive.is • Google • Que faire ?).
  48. « http://www.braillenet.org/accessibilite/referentiel-aw21/#intro AccessiWeb, méthode de vérification de conformité »(Archive • Wikiwix • Archive.is • Google • Que faire ?) et (nl) AnySurfer 2.0 (en nééerlandais).
  49. Association Valentin Haüy accessibilité Internet.
  50. Association Valentin Haüy accessibilité des documents et des courriels.
  51. Circulaire du 7 octobre 1999 relative aux sites Internet des services et des établissements publics de l'État.
  52. 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.
  53. « Loi du 11 février 2005 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées ».
  54. « RGAA - Accessibilité – Présentation du référentiel général d'accessibilité pour les administrations », ministère du Budget, des Comptes publics et de la Fonction publique.
  55. Arrêté du 29 avril 2015 relatif au référentiel général d'accessibilité pour les administrations
  56. « Publication de RENO, le nouveau référentiel de normalisation pour les sites web du Gouvernement luxembourgeois », eLuxembourg.
  57. (en) eAccessibility of public sector services in the European Union.
  58. (en) Global Audit of Web Accessibility, ONU.
  59. (en) The Web: Access and Inclusion for Disabled People. A formal investigation conducted by the Disability Rights Commission, Disability Rights Commission, Londres, 2004 (ISBN 978-0-11-703287-3).
  60. Concernant la France : [PDF] Rapport au Premier Ministre de l’Observatoire interministériel de l’Accessibilité et de la Conception universelle (PDF, 1,7Mo), La Documentation française, mai 2011, p.  114-120.

Autres références
  1. (en) W3C Web Accessibility Initiative (WAI), « Introduction to Web Accessibility », sur w3.org (consulté le ).
  2. http://www.un.org/esa/socdev/enable/rights/convtextf.htm.
  3. http://www.w3.org/Consortium/mission.
  4. James Vincent, « Google’s Project Euphonia helps make speech tech more accessible to people with disabilities », sur The Verge, (consulté le )
  5. « Accessibilité numérique - session 1 », sur FUN-MOOC (consulté le )
  6. « Complément MOOCACCESS – Site de ressources participatif sur l'accessibilité numérique » (consulté le )
  7. FLORIAN DEBES, « Handicap : le chemin de croix existe aussi sur le Web », sur Les Echos Executives, (consulté le )
  8. Bureau fédéral de l‘égalité pour les personnes handicapées (BFEH), « Étude 2011 sur l'accessibilité des sites Web suisses Bilan de l'accessibilité aux personnes handicapées des considérables sites Web suisses », BFEH,‎ (lire en ligne)

Voir aussi

Bibliographie
  • Armony Altinier, L'accessibilité web. Normes et bonnes pratiques pour des sites plus accessibles, Eyrolles, , 332 p. (ISBN 9-782212-128895).

Articles connexes

Liens externes
  • Portail du handicap
  • Portail d’Internet
  • Portail du Web sémantique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.