<page> <title>Accessibilité du Web</title> <id>2978950</id> <revision> <id>31771250</id> <timestamp>2008-07-21T19:04:07Z</timestamp> <contributor> <username>David Berardan</username> <id>26481</id> </contributor> <minor /> <comment>Correction des [[Projet:Liens vers les pages d'homonymie|liens vers les pages d'homonymie]]</comment> <text xml:space="preserve">L''''accessibilité du Web''' est la problématique de l'accès aux [[World Wide Web|services et contenus en ligne]] pour les [[handicapés]] et les [[Vieillesse|seniors]]. Définie par des normes techniques établies par la [[Web Accessibility Initiative|{{lang|en|Web Accessibility Initiative}}]] (WAI) du [[World Wide Web Consortium|{{lang|en|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'elle soit une composante et un levier d'amélioration de leur qualité globale, le degré d'accessibilité effectif des sites Web reste actuellement très faible. == Le champ de l'accessibilité == L'accessibilité du Web est définie par la WAI<ref group="W3C">{{en}}[http://www.w3.org/WAI/intro/accessibility.php {{lang|en|W3C, Introduction to Web Accessibility}}]</ref> comme l'une des composantes de l'[[accessibilité numérique]] : <blockquote cite="http://www.w3.org/WAI/intro/accessibility.php">{{Citation|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.}}</blockquote> 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]]<ref group="Note">{{fr}} [http://www.un.org/esa/socdev/enable/rights/convtextf.htm Convention relative aux droits des personnes handicapées, ONU]</ref> <blockquote cite="http://www.un.org/esa/socdev/enable/rights/convtextf.htm">{{Citation|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 }}</blockquote> === Les contextes utilisateur === [[Image:Plage-braille-avec-touches-speciales.jpg|thumb|Exemple d'aide technique: une [[plage braille]].]] Même dans cette acception étroitement liée au handicap, l'accessibilité vise une très grande variété de cas utilisateurs<ref group="Note">[http://www.microsoft.com/downloads/details.aspx?familyid=B7864E09-BE31-49D4-A608-9907D72E8720&displaylang=fr L'accessibilité, de quoi s'agit-il ?], Livre Blanc, Microsoft</ref>. Celle-ci s'illustre en effet par : * la diversité des [[handicap]]s susceptibles d'affecter la capacité à accéder à un contenu ou à un service en ligne<ref group="W3C">{{en}} [http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/#diff {{lang|en|Different Disabilities that Can Affect Web Accessibility, How People with Disabilities Use the Web, W3C}}]</ref>. 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<ref group="W3C">{{en}} [http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web/#tools {{lang|en|Assistive Technologies and Adaptive Strategies, How People with Disabilities Use the Web, W3C}}]</ref> : claviers alternatifs et commutateurs, dispositifs braille, [[Lecteur d'écran|lecteurs d'écran]] ([[Jaws (logiciel pour déficients visuels)|JAWS]], {{lang|en|Window-Eyes}}<ref group="Note">{{en}} [http://www.gwmicro.com/Window-Eyes/ {{lang|en|Window-Eyes}}]</ref>, {{lang|en|SRCore}} pour [[Gnopernicus]]) et autres outils de synthèse vocale ([[Microsoft Windows]], Narrator pour [[Windows 2000]]), loupes d'écran et autres dispositifs d'agrandissement, navigateurs textes, dispositifs 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 largement à tous les utilisateurs et acteurs, notamment en termes d'utilisabilité, de maîtrise de la production des contenus, de retours sur investissement<ref group="Note">[http://openweb.eu.org/articles/accessibilite_numerique_pourquoi/ Elie Sloïm, Laurent Denis, Pourquoi l'accessibilité numérique ? OpenWeb, 25 juillet 2005]</ref> et d'image. L'accessibilité des contenus rejoint également en partie la problématique de l'accès sur les [[Téléphonie mobile|mobiles]] et les ''{{lang|en|Mobile Web Best Practices 1.0}}'' du W3C son en partie dérivées des normes d'accessibilité des contenus Web<ref group="Note">{{en}} [http://www.w3.org/TR/mobile-bp/#iddiv2126633736 {{lang|en|Relationship to other Best Practices and recommendations, Mobile Web Best Practices 1.0, W3C}}]</ref>. Mais l'essor du Web mobile suscite à son tour de nouveaux usages et des innovations technologiques qui sont autant de nouveaux défis en termes d'accessibilité<ref group="Note">{{en}} Michael Cooper, [http://inova.snv.jussieu.fr/evenements/colloques/servonline/Actes/description_ang.php?id=39&num=45 {{{lang|en|Web Accessibility in the Future}}], actes du Forum européen de l'accessibilité numérique, 29 janvier 2007.</ref>. === Accessibilité des contenus ou accessibilité universelle ? === Certains acteurs de l'accessibilité Web<ref group="Note">C'est le cas notamment, en France, de l'organisme de labellisation Accessiweb. Voir la [http://www.accessiweb.org/fr/Label_Accessibilite/ définition de l'accessibilité du web par Accessiweb]</ref> étendent son champ au-delà de la question du handicap, à tous les contextes utilisateurs, en s'inspirant en particulier de l'objectif donné au [[World Wide Web Consortium|W3C]] par [[Tim Berners-Lee]], inventeur du [[World Wide Web]]: <blockquote cite="http://www.w3.org/Consortium/mission">{{Citation|Mettre le web et ses services à la disposition de tous les individus, quel que soit leur [[matériel informatique|matériel]] ou [[logiciel]], leur infrastructure réseau, leur [[langue maternelle]], leur [[culture]], leur localisation géographique, ou leurs aptitudes physiques ou mentales.}}</blockquote> 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 <em>qualité Web</em> dont elle est également une composante<ref group="Note">[http://inova.snv.jussieu.fr/actes/colloques/Instruments/ 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, 2005[http://openweb.eu.org/articles/accessibilite_numerique_pourquoi/ Pourquoi l'accessibilité numérique ?], Openweb, </ref>. En fonction des 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, lorsqu'ils s'avèrent au moins temporairement contradictoires dans un contexte de production donné. == Les normes d'accessibilité internationales == L'accessibilité Web dépend de plusieurs composantes interdépendantes<ref group="W3C">{{en}} [http://www.w3.org/WAI/intro/components.php {{lang|en|Essential Components of Web Accessibility, W3C}}]</ref> : * le contenu Web, c'est à dire {{citation|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}}<ref group="W3C">{{en}} [http://www.w3.org/TR/WCAG20/#glossary {{lang|en|Web Content Accessibility Guidelines 2.0, Appendix A: Glossary, W3C}}]</ref> * 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 [[World Wide Web Consortium|W3C]] a créé des recommandations à travers le projet [[WAI]] ({{lang|en|[[Web Accessibility Initiative]]}}) créé en [[1996]]. Ces recommandations sont organisées selon trois points de vue : # 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 {{lang|en|Authoring Tools Accessibility Guidelines}} ; # 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 {{lang|en|Web Content Accessibility Guidelines}} ; # afin de tirer parti de ce contenu accessible, les outils de consultation (par exemple les [[Navigateur web|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 {{lang|en|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]]<ref group="W3C">{{en}} [http://www.w3.org/WAI/References/HTML4-access {{lang|en|WAI Resource: HTML 4.0 Accessibility Improvements, W3C}}]</ref> ainsi que des [[feuilles de style en cascade]] (CSS)<ref group="W3C">{{en}} [http://www.w3.org/WAI/EO/NOTE-css-access-19990309 {{lang|en|Accessibility Features of CSS, W3C}}]</ref>. Enfin, d'autres recommandations en chantier sont consacrées notamment au interfaces riches, ou à [[XML]], [[SVG]], [[SMIL]]<ref group="W3C">{{en}} [http://www.w3.org/WAI/specific-techs {{lang|en|Accessibility Information for Specific Technologies, W3C}}]</ref>. === Recommandations pour le contenu === Les recommandations en ce qui concerne le contenu s'adressent à tous les distributeurs de contenu sur le [[World Wide Web|Web]]. Ces directives se nomment les {{lang|en|Web Content Accessibility Guidelines}}. Leur dernière version officielle est celle des WCAG1.0, qui remonte à [[1999]]<ref group="W3C">{{en}} [http://www.w3.org/TR/WCAG10/ {{lang|en|Web Content Accessibility Guidelines 1.0, W3C}}]</ref>. Les travaux continuent dans le cadre d'une nouvelle version en cours d'élaboration, les WCAG2.0<ref group="W3C">{{en}} [http://www.w3.org/TR/WCAG20/ {{lang|en|Web Content Accessibility Guidelines 2.0, W3C}}]</ref>. ==== WCAG 1.0 ==== WCAG1.0 comporte 14 directives dont les 11 premières visent à assurer une transformation élégante du contenu dans les différents contextes utilisateurs :<ref group="W3C">{{en}} [http://www.w3.org/TR/WAI-WEBCONTENT/#themes {{lang|en|Themes of Accessible Design, WCAG1.0, W3C}}]</ref>: # Fournir des alternatives équivalentes aux contenus visuels et auditifs (images statiques ou animées, contenus audio et vidéo). # Ne pas s'en remettre exclusivement aux couleurs # Utiliser le balisage HTML et les feuilles de styles CSS de façon appropriée # Clarifier l'utilisation du langage naturel # Créer des tableaux HTML qui se transforment de façon élégante # S'assurer que les pages qui contiennent de nouvelles technologies (objets programmables, styles CSS) se transforment de façon élégante # Assurer à l'utilisateur le contrôle des changements du contenu lorsque ce dernier varie dans le temps (clignotements, mouvements, refraîchissement du contenu, redirections) # Assurer un accès direct aux interfaces utilisateur intégrées (objets [[Adobe Flash|Flash]], applets [[Java (langage)|JAVA]]) # Concevoir de manière indépendante du périphérique (souris, clavier, etc.) # Utiliser des solutions intermédiaires en attendant que les agents utilisateurs aient un meilleur support de l'accessibilité # Utiliser les technologies et directives du W3C Les 3 dernières visent à rendre le contenu compréhensible et navigable: <ol start="12"> <li>Fournir des informations de contexte et d'orientation</li> <li>Fournir des mécanismes de navigation clairs</li> <li>S'assurer que les pages sont claires et simples</li> </ol> Chaque directive détermine un ou plusieurs points de contrôles. Par exemple, la directive 2 demande de {{citation|ne pas s'en remettre exclusivement aux couleurs}}<ref group="W3C">{{en}} [http://www.w3.org/TR/WCAG10/wai-pageauth.html#gl-color {{lang|en|Guideline 2, WCAG1.0, W3C}}]</ref> et prévoit à cet effet deux points de contrôle : # {{citation|S’assurer que toute information convoyée par des couleurs est également accessible sans couleur, par exemple à partir du contexte ou de balises}}. # {{citation|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 WCAG1.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é : {| class="wikitable" width="90%" |+ Les niveaux d'accessibilité WCAG1.0 ! scope="col" | Priorité ! scope="col" | Obligation ! scope="col" | Portée ! scope="col" | Niveau d'accessibilité ! scope="col" | Exemple |- | 1 | Ce qui <strong>doit</strong> ê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 <strong>devrait</strong> être fait | Lève d'autres barrières significatives | Niveau AA (respect des points de contrôle de priorité 1 et 2) | Les constrates de couleurs entre avant-plan et arrière-plan sont suffisants dans les images. |- | 3 | Ce qui <strong>peut</strong> être fait | Améliore le confort d'accès | Niveau AAA (respect des points de contrôle de priorité 1, 2 et 3) | Les constrates 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 constraste insuffisant dans une image rendra celle-ci difficilement compréhensible pour des utilisateus daltoniens ou plus généralement malvoyants, bien qu'une aide technique puisse éventuellement améliorer le rendu de l'image. * 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 WCAG1.0. ==== WCAG 2.0 ==== Alors que les WCAG1.0 concernent principalement les contenus HTML, les WCAG2.0 font abstraction de la technologie spécifiquement utilisée et ont pour objectifs d'être<ref group="W3C">{{en}} [http://www.w3.org/TR/wcag2-req/ {{lang|en|Requirements for WCAG 2.0, W3C Working Group Note 25 April 2006}}]</ref>: * applicables à toutes les technologies actuelles et futures de conception de pages Web, qu'il s'agisse de technologies du W3C comme [[Feuilles de style en cascade|CSS]], [[XML]] et [[SMIL]] ou potentiellement de technologies non W3C telles que [[Adobe Flash|Flash]], [[Microsoft Silverlight|Silverlight]] ou [[PDF]]. WCAG2.0 adopte à cet effet le concept de « technologie supportant 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 aides techniques aient été adaptés à l'usage de cette technologie<ref group="W3C">{{en}} [http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/conformance.html#uc-accessibility-support-head {{lang|en|Understanding WCAG 2.0, Understanding Accessibility Support}}]</ref>. Là où WCAG1.0 recourait au bannissement de technologies considérées comme non accessibles, WCAG2.0 privilégie le développement de l'interoperabilité.<ref group="Note">{{fr}} Richard Schwerdtfeger, [http://inova.snv.jussieu.fr/evenements/colloques/servonline/Actes/description_fr.php?id=48&num=45 L'accessibilité des applications Web et des services en ligne riches (ARIA)], actes du Forum européen de l'accessibilité numérique, 29 janvier 2007.</ref> 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 à utiliser et à comprendre. Pour cela, les WCAG2.0 sont dotées d'un guide d'implémentation<ref group="W3C">{{en}} [http://www.w3.org/TR/UNDERSTANDING-WCAG20/ {{lang|en|Understanding WCAG 2.0, A guide to understanding and implementing WCAG 2.0}}]</ref> * plus aptes à l'évaluation humaine ou logicielle grâce à des critères de succès explicites. WCAG2.0 adopte également une approche thématique plus rigoureuse en structurant 12 directives principales selon 4 principes fondamentaux : # 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édia synchronisés #* Créer du contenu qui puisse être mis en forme de différentes manière 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 # 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 pour entraîner des dommages #* Fournir des aides aux utilisateurs handicapés pour naviguer, rechercher du contenu et se situer dans ceux-ci # Des contenus compréhensibles #* Fournir des textes lisibles et compréhensibles #* Permettre aux pages Web d'apparaître et d'e se comporter de manière prévisible #* aider les utilisateurs à rectifier leurs erreurs # Des contenus robustes #* Optimiser la compatibilité avec les agents utilisateurs actuels et futurs, y compris les aides techniques Chacune des 12 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, WCAG2.0 indique des « techniques suffisantes et indicatives » qui fournissent un guide sans pour autant associer exclusivement la norme à l'utilisation de formats ou de technologies spécifiques<ref group="W3C">{{en}} [http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/intro.html#introduction-layers-head {{lang|en|Understanding WCAG 2.0, Sufficient and Advisory Techniques}}]</ref> La définition des trois niveaux d'accessibilité tient désormais compte de leur faisabilité: {| class="wikitable" width="90%" |+ |+ Les niveaux d'accessibilité WCAG2.0 ! scope="col" | Niveau ! scope="col" | Objectif ! scope="col" | Faisabilité ! scope="col" | Exemple |- | A | Atteindre un niveau d'accessibilité minimum. | 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éliorez 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 à 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 |} WCAG2.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<ref group="W3C">{{en}} [http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/conformance.html#uc-levels-head {{lang|en|Understanding WCAG 2.0, Understanding Levels of Conformance}}]</ref>. L'adoption finale de la recommandation WCAG2.0 est envisagée par le WC3 pour le courant de l'année [[2008]]<ref group="W3C">{{en}} [http://www.w3.org/WAI/intro/wcag.php#version {{lang|en|Web Content Accessibility Guidelines (WCAG) Overview, W3C}}]</ref>. Cette évolution est contestée par certains experts, à l'initiative de Joe Clark<ref group="Note">{{en}} Joe Clark, [http://alistapart.com/articles/tohellwithwcag2 {{lang|en|To Hell with WCAG 2}}], Alist Apart, 23 mai 2006</ref> qui récuse le mode de fonctionnement de la WAI et privilégie une mise à jour de WCAG1.0. Celle-ci a été publiée en février 2008 sous forme d'un errata réalisé indépendamment de la WAI par le projet {{lang|en|WCAG Samurai}}<ref group="Note">{{en}} [http://wcagsamurai.org/ {{lang|en|WCAG Samurai}}].</ref>. === Recommandations pour les outils de production de contenu === Les lignes de conduite les plus à jour pour les [[logiciel]]s d’édition de [[Hypertext markup language|HTML]], les éditeurs de page ou [[logiciel]] de publication de [[site web]] créant le code [[Hypertext markup language|HTML]], sont les ''{{lang|en|Authoring Tools Accessibility Guidelines}}'' dans leur version 1.0, datant de février 2000<ref group="W3C">{{en}} [http://www.w3.org/TR/ATAG10/ {{lang|en|Authoring Tools Accessibility Guidelines 1.0, W3C}}]</ref>. Depuis la publication des ATAG1.0, sont sortis les [[système de gestion de contenu|systèmes de gestion de contenu]] et les [[weblog|blogues]] pour lesquels les ATAG2.0<ref group="W3C">{{en}} [http://www.w3.org/TR/ATAG20/ {{lang|en|Authoring Tool Accessibility Guidelines 2.0, W3C}}]</ref> 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 l'essentiel 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 à 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. Avec la popularité croissante du Web et des solutions de publication utilisées par des non-professionnels ([[weblog]], [[wiki]], etc.), 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<ref group="Note">{{en}} Michael Cooper, [http://inova.snv.jussieu.fr/evenements/colloques/servonline/Actes/description_ang.php?id=39&num=45 {{{lang|en|Web Accessibility in the Future}}], actes du Forum européen de l'accessibilité numérique, 29 janvier 2007.</ref>. 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 {{lang|en|User Agent Accessibility Guidelines 1.0}} <ref group="W3C">{{en}} [http://www.w3.org/TR/UAAG10/ {{lang|en|User Agent Accessibility Guidelines 1.0, W3C}}]</ref>. Les travaux continuent dans le cadre d'une nouvelle version en cours d'élaboration, les UAAG2.0<ref group="W3C">{{en}} [http://www.w3.org/TR/UAAG20/ {{lang|en|User Agent Accessibility Guidelines 2.0, W3C}}]</ref>. 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) : # Respecter les normes et conventions applicables # Favoriser l'accès par les technologies d'aide # Garantir que l'interface utilisateur soit perceptible # Garantir que l'interface utilisateur soit utilisable # Garantir que l'interface utilisateur soit compréhensible === Recommandations pour les applications Web industrielles et les interfaces dynamiques === ==== Logiciels containers==== De nos jours, les applications Web sont écrites par des professionnels différents de ceux qui contribuent à la production du contenu. Il en résulte que la seule application de WCAG (1 ou 2) ne suffit plus pour rendre le Web accessible. {{Référence nécessaire|De plus en plus en plus d'applications de gestion passent du mode client/serveur au mode ''basé sur le Web''}}. Il en résulte que le contenu en ligne provient, le plus souvent de bases de données entretenues pour d'autres usages que la seule publication sur le web. La production du contenu s'automatise et, de ce fait, l'accessibilité ne repose plus seulement sur l'accessibilité au sens de WCAG, mais également sur la capacité à produire de l'accessibilité de logiciels tels que : * les [[Agrégateur|agrégateurs de contenus]], * les logiciels de [[workflow]], * les [[logiciel métier|logiciels métiers]] (par exemple, les [[Système intégré de gestion de bibliothèque|outils de gestion de bibliothèque]]) * les [[Système de gestion de contenu|gestionnaires de contenu]] * les logiciels de [[Portail web|portail]] {{Référence nécessaire|ATAG 1.0 et ATAG 2.0 sont peu connus et peu pris en compte par les éditeurs de ce type d'outils}}. La plupart des applications créées dans les entreprises puisent leurs données dans une [[base de données]] ([[Base de données relationnelle|relationnelle]], [[Base de données orientée objet|objet]] ou un équivalent [[Extensible Markup Language|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 essentiellement à vérifier que la base ne contient pas de champ fourre-tout (par exemple une case texte de {{formatnum:4000}} 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 <ref group="W3C">{{en}} [http://www.w3.org/TR/xag {{lang|en|XML Accessibility Guidelines, W3C}}]</ref> 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]], [[JavaScript]] et [[SVG]], l'élaboration par la WAI de l'<i>{{lang|en|Accessible Rich Internet Applications Suite}}</i> (ARIA) vise à mettre en place le cadre normatif nécessaire à l'accessibilité des {{lang|en|[[Rich Internet Application|application Web dynamiques]]}}<ref group="W3C">{{en}} [http://www.w3.org/WAI/intro/aria {{lang|en|WAI-ARIA Overview, W3C}}]</ref>. 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 permet à une amélioration de l'accessibilité pour l'une d'entre elle d'entraîner des améliorations en chaîne<ref group="W3C">{{en}} [http://www.w3.org/WAI/intro/components.php {{lang|en|Essential Components of Web Accessibility, W3C}}]</ref>. 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 par exemple dans le cas des descriptions étendues d'images dans le format HTML5<ref group="Note">{{fr}} [http://blog.whatwg.org/2007/09 La loterie du longdesc, The WHATWG Blog, septembre 2007]</ref> == Déploiement, évaluation et suivi == === 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 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<ref group="W3C">{{en}} [http://www.w3.org/WAI/Resources/WAI-UA-Support {{lang|en|User Agent Support for Accessibility, W3C}}]</ref>). WCAG2.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<ref group="Note">[http://www.accessiweb.org/ Accessiweb]</ref> (France) et Anysurfer<ref group="Note">[http://www.anysurfer.be/ Anysurfer]</ref> (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)<ref group="Note">{{en}} [http://www.wabcluster.org/uwem1_2/ {{lang|en|Unified Web Evaluation Methodology}}]</ref> est une méthode européenne issue de différentes méthodes nationales privées, permettant 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 internationale, proposent un ensemble de solutions pour permettre la réalisation de [[site web|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 : {{citation|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.}}<ref group="Note">{{en}} Chris Law, Julie Jacko, Paula Edwards, [http://portal.acm.org/citation.cfm?id=1090792 {{lang|en|Programmer-focused website accessibility evaluations}}], {{lang|en|ACM SIGACCESS Conference on Assistive Technologies}}, Baltimore, 2005</ref>. Ceci peut concerner notamment l'utilisation des bases documentaires, le choix d'un [[système de gestion de contenu]]s et d'une [[charte graphique]], la définition des [[cahier des charges|cahiers des charges]] et le choix des [[Sous-traitance|prestataires]], la politique de [[Formation professionnelle continue|formation interne]], etc. ==== En cours de création ou de refonte ==== Lors de la réalisation du projet, des évaluations d'accessibilité {{Référence nécessaire|peuvent intervenir en particulier aux étapes de}} conception de la [[charte graphique]], des [[template|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<ref group="Note">{{en}} {{lang|en|Rick Ells, University of Washington}}, [http://highedweb.org/2005/presentations/ {{lang|en|Building Accessibility Into The Workflow}}], {{lang|en|Higher Education Web Developers Conference}}, 2005</ref> à travers l'utilisation de la [[Couleurs du Web|couleur]] et des éléments graphiques comme véhicule de l'information, mais aussi en raison des contraintes d'intégration qu'elle peut induit dans le choix des formats de publication ([[HTML]], [[Adobe Flash|Flash]]) et dans leur utilisation. Son intégration générique à travers des gabarits de page a un rôle clé en particulier à travers<ref group="Note">{{en}} {{lang|en|Rick Ells, University of Washington}}, [http://highedweb.org/2005/presentations/ {{lang|en|Building Accessibility Into The Workflow}}], {{lang|en|Higher Education Web Developers Conference}}, 2005</ref> ses choix de technologies ([[AJAX]], [[Adobe Flash|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 {{Référence nécessaire|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<ref group="Note">{{en}} {{lang|en|Rick Ells, University of Washington}}, [http://highedweb.org/2005/presentations/ {{lang|en|Building Accessibility Into The Workflow}}], {{lang|en|Higher Education Web Developers Conference}}, 2005</ref> : * 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 aides techniques 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. === L'évaluation === ==== Les outils automatiques ==== 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 [[Hypertext Markup Language|HTML]] ou les [[système de gestion de contenu|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é. Dans les deux cas 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. 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. Parmi les très nombreux outils disponibles, citons par exemple {{lang|en|WAVE}}<ref group="Note">[http://wave.webaim.org/ {{lang|en|WAVE}}]</ref> (dont les résultats sont donnés sous forme d'icônes ajoutées à la page évaluée), OCAWA<ref group="Note">[http://www.ocawa.com/ OCAWA]</ref> (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 en particulier<ref group="W3C">{{en}} [http://www.w3.org/WAI/eval/users.html {{lang|en|Involving Users in Web Accessibility Evaluation, W3C}}]</ref>: * 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é 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<ref group="W3C">{{en}} [http://www.w3.org/WAI/eval/conformance {{lang|en|Conformance Evaluation of Web Sites for Accessibility, W3C}}]</ref>. ==== L'évaluation experte ==== Evaluer 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 technologies Web, des outils de validation, des directives d'accessibilité, des aides techniques et des agents utilisateurs, ainsi que des stratégies auxquelles recourent les personnes handicapées dans leur usage du Web<ref group="W3C">{{en}} [http://www.w3.org/WAI/eval/reviewteams.html {{lang|en|Using Combined Expertise to Evaluate Web Accessibility, W3C}}]</ref>. 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é<ref group="Note">{{en}} Michael Cooper, [http://inova.snv.jussieu.fr/evenements/colloques/servonline/Actes/description_ang.php?id=39&num=45 {{{lang|en|Web Accessibility in the Future}}], actes du Forum européen de l'accessibilité numérique, 29 janvier 2007.</ref>. === Politiques d'accessibilité, suivi et gestion du risque === Selon la WAI, une politique organisationnelle d'accessibilité se définit par<ref group="W3C">{{en}} [http://www.w3.org/WAI/impl/pol {{lang|en|Developing Organizational Policies on Web Accessibility, W3C}}]</ref>: * 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 niveau 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'acessibilité 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 en termes de difficultés de mise en Å“uvre<ref group="Note">[http://openweb.eu.org/articles/nouveaux_defis_accessibilite_numerique_1/ Les nouveaux défis de l'accessibilité numérique : 1- la vision actuelle, Elie Sloïm, Openweb, 14 février 2008].</ref> et d'absence de gestion du risque dans le cadre d'une démarche qualité<ref group="Note">[http://openweb.eu.org/articles/nouveaux_defis_accessibilite_numerique_2/ 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]</ref> à l'échelle d'importants parcs de sites. == Les acteurs de l'accessibilité == === 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<ref group="Note">A titre d'exemple, en France: [http://www.renaissancenumerique.org/CP_accessibilite.html 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</ref>. Elle suscite parfois des réserves de la part de certains d'entre eux<ref group="Note">{{en}} Andy Clarke, [http://www.stuffandnonsense.co.uk/archives/accessibility_and_a_society_of_control.html {{lang|en|Accessibility and a society of control}}], 18 juin 2005.</ref>. === Les associations d'usagers et d'acteurs du Web === {{...}} Des associations agissent pour promouvoir l'accessibilité du web aux personnes handicapées. Citons par exemple, en France Braillenet<ref group="Note">[http://www.braillenet.org/ BrailleNet]</ref>, HandicapZéro<ref group="Note">[http://www.handicapzero.org/ HandicapZéro]</ref> ou encore WebSourd<ref group="Note">[http://www.websourd.org/ WebSourd]</ref>. === Les organismes de labelisation === {{...}} Des organismes de labelisation privés décernent des labels d'accessibilité. C'est le cas par exemple d'[[BrailleNet|Accessiweb]] en France, d'Anysurfer en Belgique, de Technosite<ref group="Note">{{es}} [http://www.technosite.es {{lang|es|Technosite, Grupo Fundosa}}]</ref> en Espagne, ou encore du label européen Euracert<ref group="Note">[http://www.euracert.org/fr/apropos/label/ {{lang|en|Euracert, European eAccessibility Certification}}] issu de ces trois organismes</ref>. 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<ref group="W3C">{{en}} [http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixD.html {{lang|en|Comparison of WCAG 1.0 checkpoints to WCAG 2.0, W3C}}]</ref>, 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é. Citons par exemple {{lang|en|Vision Australia}}<ref group="Note">{{en}} [http://www.visionaustralia.org {{lang|en|Vision Australia}}]</ref> ou {{lang|en|WebAIM}}<ref group="Note">{{en}} [http://www.webaim.org/ {{lang|en|WebAIM}}]</ref>. {{Référence nécessaire|L'accessibilité est une activité commerciale et un enjeu marketing pour des sociétés et parfois des associations qui commercialisent assistance et formations}}. === Les responsables de sites === {{...}} == 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 [http://www.section508.gov/ 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 mai 2000, 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 {{Citation|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.}}<ref group="Note">[http://admi.net/jo/19991012/PRMX9903708C.html Circulaire du 7 octobre 1999 relative aux sites internet des services et des établissements publics de l'État]</ref>. 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 notamment la création d'un {{citation|cadre général clair pour une meilleure prise en compte des critères d'accessibilité des sites}}, d'un {{citation|centre ressources pour le conseil et la formation}} et enfin d'un {{citation|organisme officiel de certification, totalement habilité à effectuer ce type de travail par son indépendance}}<ref group="Note">Julien Perben, [http://www.ladocumentationfrancaise.fr/brp/notices/044000032.shtml Rapport d'étude sur l'accessibilité de l'Internet-Intranet aux personnes handicapées], Secrétariat d'État aux personnes handicapées, 2003.</ref>. 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 WCAG1.0, complétés par des préconisations ergonomiques<ref group="Note">{{fr}} [http://www.accessiweb.org/_repository/files/referentiel_accessibilite_version_2004.rtf Référentiel accessibilité des services Internet de l’administration française, version 2004] (format [[RTF]])</ref>. 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 ({{numéro}}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. »<ref group="Note">{{Légifrance|base=JORF|numéro=SANX0300217L|texte=Loi du 11 février 2005 pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées}}</ref>. À cet effet, un nouveau cadre de référence, adapté à ce caractère d'obligation, est nécessaire. 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 internationale WCAG1.0, au niveau le plus élevé (AAA). Il 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. Le RGAA a été adopté en octobre 2007 par le collège d'experts chargé de sa validation<ref group="Note">[http://www.synergies-publiques.fr/article.php?id_article=853 Validation du RGAA par le collège d’experts accessibilité]</ref>. Il est destiné à devenir l'arrêté annexe au décret d'application de la loi du 11 février 2005. Ce décret n'a pas encore é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é systématiquement aux cahiers des charges des projets web de l'État<ref group="Note">[http://www.eluxembourg.public.lu/actualites/2007/11/reno/index.html Publication de RENO, le nouveau référentiel de normalisation pour les sites web du Gouvernement luxembourgeois], eLuxembourg.</ref>. == L'état de l'accessibilité du Web == En [[2005]], l'étude ''{{lang|en|eAccessibility of public sector services in the European Union}}'' menée par le ''{{lang|en|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<ref group="Note">{{en}} [http://archive.cabinetoffice.gov.uk/e-government/resources/eaccessibility/content.asp {{lang|en|eAccessibility of public sector services in the European Union}}]</ref>. 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<ref group="Note">{{en}} [http://www.un.org/esa/socdev/enable/gawanomensa.htm {{lang|en|Global Audit of Web Accessibility, ONU}}]</ref>. Une étude menée en [[2004]] sur un échantillon de 1000 sites Web par la ''{{lang|en|Disability Rights Commission}}'' britannnique identifiait les principaux manquements aux directives WCAG1.0<ref group="Note">{{en}} {{lang|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</ref> : * 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. {{Référence nécessaire|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.}} == Notes et références == ===Références aux documents du [[World Wide Web Consortium|W3C]]=== <references group="W3C" /> ===Autres références=== <references group="Note" /> ==Voir aussi== * [[Accessibilité numérique]] ==Lien externe== * {{en}} [http://www.w3.org/WAI/ {{lang|en|Web Accessibility Initiative (WAI), W3C}}] [[Catégorie:Accessibilité numérique]] [[Catégorie:World Wide Web]] [[ca:Accessibilitat web]] [[de:Barrierefreies Internet]] [[en:Web accessibility]] [[es:Accesibilidad web]] [[eu:Web irisgarritasun]] [[fa:قابلیت دسترسی وب]] [[mk:Веб-приÑтапноÑÑ‚]] [[pl:DostÄ™pność (WWW)]] [[th:Web accessibility]] [[zh:ç¶²é 親和力]]</text> </revision> </page>