Accessibilite du Web

ÔĽŅ
Accessibilite du Web

Accessibilité du Web

L'accessibilité du Web est la problématique de l'accès aux services et contenus en ligne pour les handicapés et les seniors. Définie par des normes techniques établies par la Web Accessibility Initiative (WAI) du World Wide Web Consortium (W3C), elle nécessite un traitement tout au long du cycle de vie d'un site Web, par 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[Note 1].

Sommaire

Le champ de l'accessibilité

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

¬ę L'accessibilit√© du web 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. ¬Ľ

Elle est un droit universel, selon l'article 9 de la Convention relative aux droits des personnes handicapées adoptée en 2006 par l'Organisation des Nations unies[Note 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. ¬Ľ

Les contextes utilisateur

Plage braille comportant une ligne de 40 caractères brailles et plusieurs touches spéciales
Exemple d'aide technique : une plage braille munie d'un ordinateur embarqu√©, fonctionnant de mani√®re autonome
Plage braille comportant une ligne de 40 caractères braille
Cette autre plage braille n'offrant qu'une ligne de caractères brailles 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 utilisateurs[Note 3]. Celle-ci s'illustre en effet par :

  • la diversit√© des handicaps susceptibles d'affecter la capacit√© √† acc√©der √† un contenu ou √† un service en ligne[W3C 2]. Ceux-ci peuvent √™tre visuels (c√©cit√©, trouble de la vision, daltonisme), auditifs (surdit√© totale ou partielle), moteurs, cognitifs ou neurologiques, ou encore li√©s au vieillissement.
  • la vari√©t√© des p√©riph√©riques d'entr√©e et de sortie, et celle des aides techniques[W3C 3] : claviers alternatifs et commutateurs, dispositifs braille, lecteurs d'√©cran (JAWS, Window-Eyes[Note 4], 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[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 termes d'accessibilité[Note 7].

Accessibilit√© des contenus ou accessibilit√© universelle ?

Certains acteurs de l'accessibilit√© Web[Note 8] √©tendent son champ au-del√† de la question du handicap, √† tous les contextes utilisateurs, en s'inspirant en particulier de l'objectif donn√© au W3C par Tim Berners-Lee, inventeur du World Wide Web :

¬ę Mettre le web et ses services √† la disposition de tous les individus, quel que soit leur mat√©riel ou logiciel, leur infrastructure r√©seau, leur langue maternelle, leur culture, leur localisation g√©ographique, ou leurs aptitudes physiques ou mentales. ¬Ľ

L'accessibilité des contenus reste cependant, aux points de vue normatif et opérationnel, un aspect spécifique de cette ambition, et ne se confond pas davantage avec la notion de qualité Web dont elle est également une composante[Note 9]. 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[W3C 4] :

  • 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 5]
  • les agents utilisateurs qui exploitent le contenu et le restituent aux internautes : navigateurs, plugins, etc.
  • les aides techniques logicielles (lecteurs d'√©cran, logiciels d'agrandissement, etc.) et mat√©rielles (claviers adapt√©s, commutateurs, etc.)
  • les outils d'√©dition du contenu
  • les outils d'√©valuation de l'accessibilit√© Web
  • les d√©veloppeurs de contenu, d'agents utilisateurs, d'aides techniques, d'outils d'√©dition et d'√©valuation.

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

  1. les outils de production de contenu doivent d'une part pouvoir √™tre utilis√©s par tous, et d'autre part autoriser et 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 Internet) doivent être utilisables par tous et exploiter les informations spécifiques qui ont été ajoutées aux contenus pour les rendre accessibles. Les lignes de conduite pour les outils de consultation sont exposées dans les User Agent Accessibility Guidelines.

La WAI intervient é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 6] ainsi que des feuilles de style en cascade (CSS)[W3C 7]. Enfin, d'autres recommandations en chantier sont consacrées notamment au interfaces riches, ou à XML, SVG, SMIL[W3C 8].

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 WCAG1.0 publiées en 1999[W3C 9], les WCAG2.0 sont la recommandation officielle depuis le 11 décembre 2008[W3C 10].

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 :[W3C 11]:

  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 technologies (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, 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 3 dernières 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 12] 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 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√© :

Les niveaux d'accessibilité WCAG1.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 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[W3C 13]:

  • 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. WCAG2.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 aides techniques aient √©t√© adapt√©s √† l'usage de cette technologie[W3C 14]. WCAG2.0 tient ainsi compte de l'√©volution des services Web et de l'√©mergence des interfaces enrichies : une des ruptures les plus notables avec WCAG1.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 15]. 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√©[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 WCAG2.0 sont dot√©es d'un guide d'impl√©mentation, Understanding WCAG 2.0[W3C 16] 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 17].

WCAG2.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√©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
  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 pour entra√ģner 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 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 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 18]

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

Les niveaux d'accessibilité WCAG2.0
Niveau Objectif Faisabilité 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 à 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

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[W3C 19].

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 WCAG1.0, sous la forme d'un errata WCAG1.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 application Web dynamiques[W3C 20].

Quelques √©diteurs mettent √† disposition des acteurs de l'accessibilit√© des biblioth√®ques de technologies accessibilis√©es en tout ou en partie.[r√©f. n√©cessaire]

Recommandations pour les outils de production de contenu

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

Depuis la publication des ATAG1.0, sont sortis les systèmes de gestion de contenu et les blogues pour lesquels les ATAG2.0[W3C 22] 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.

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 13]. 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 23]. Les travaux continuent dans le cadre d'une nouvelle version en cours d'élaboration, les UAAG2.0[W3C 24].

UAAG2.0 est organis√© autour de 5 principes (d√©compos√©s en directives correspondant elles-m√™mes √† un ou plusieurs crit√®res de succ√®s) :

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

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[W3C 25]. 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[Note 14].

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[W3C 26]). 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[Note 15] (France) et Anysurfer[Note 16] (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 WCAG.
  • la M√©thodologie Unifi√©e d'√Čvaluation de l'Accessibilit√© du Web (UWEM)[Note 17] 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 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 18].

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 19] √† 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 20] 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 21] :

  • 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 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√©.

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 WAVE[Note 22] (dont les r√©sultats sont donn√©s sous forme d'ic√īnes ajout√©es √† la page √©valu√©e), OCAWA[Note 23] (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[W3C 27]:

  • 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[W3C 28].

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[W3C 29].

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 24].

Politiques d'accessibilité, suivi et gestion du risque

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

  • 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'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 en termes de difficult√©s de mise en Ňďuvre[Note 25] et d'absence de gestion du risque dans le cadre d'une d√©marche qualit√©[Note 26] √† 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[Note 27]. Elle suscite parfois des r√©serves de la part de certains d'entre eux[Note 28].

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[Note 29], HandicapZéro[Note 30] ou encore WebSourd[Note 31].

Les organismes de labelisation

Des organismes de labelisation priv√©s d√©cernent des labels d'accessibilit√©. C'est le cas par exemple de BrailleNet (avec son label Accessiweb) en France, d'Anysurfer en Belgique, de Technosite[Note 32] en Espagne, d'Accessibilit√©Web au Qu√©bec, ou encore du label europ√©en Euracert[Note 33]. Certains de ces labels ne transcrivent pas l'int√©gralit√© des WCAG, tenant par exemple compte de l'obsolescence de points de contr√īle des WCAG 1.0[W3C 31], 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 Vision Australia[Note 34] ou WebAIM[Note 35].

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].

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 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 ¬ę 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 36].

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 ¬ę 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 37].

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[Note 38]. 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 (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 39].

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√© pour les 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 WCAG2.0. 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.

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[Note 40].

L'état de l'accessibilité du Web

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

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

  • 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.[r√©f. n√©cessaire]

Notes et références

Références aux documents du W3C

  1. ‚ÜĎ (en)W3C, Introduction to Web Accessibility
  2. ‚ÜĎ (en) Different Disabilities that Can Affect Web Accessibility, How People with Disabilities Use the Web, W3C
  3. ‚ÜĎ (en) Assistive Technologies and Adaptive Strategies, How People with Disabilities Use the Web, W3C
  4. ‚ÜĎ (en) Essential Components of Web Accessibility, W3C
  5. ‚ÜĎ (en) Web Content Accessibility Guidelines 2.0, Appendix A: Glossary, W3C
  6. ‚ÜĎ (en) WAI Resource: HTML 4.0 Accessibility Improvements, W3C
  7. ‚ÜĎ (en) Accessibility Features of CSS, W3C
  8. ‚ÜĎ (en) Accessibility Information for Specific Technologies, W3C
  9. ‚ÜĎ (en) Web Content Accessibility Guidelines 1.0, W3C
  10. ‚ÜĎ (en) Web Content Accessibility Guidelines 2.0, W3C
  11. ‚ÜĎ (en) Themes of Accessible Design, WCAG1.0, W3C
  12. ‚ÜĎ (en) Guideline 2, WCAG1.0, W3C
  13. ‚ÜĎ (en) Requirements for WCAG 2.0, W3C Working Group Note 25 April 2006
  14. ‚ÜĎ (en) Understanding WCAG 2.0, Understanding Accessibility Support
  15. ‚ÜĎ (en) Comparison of WCAG 1.0 Checkpoints to WCAG 2.0, in Numerical Order
  16. ‚ÜĎ (en) Understanding WCAG 2.0, A guide to understanding and implementing WCAG 2.0
  17. ‚ÜĎ (en) Web Content Accessibility Guidelines (WCAG) 2.0, WCAG 2.0 Layers of Guidance
  18. ‚ÜĎ (en) Understanding WCAG 2.0, Sufficient and Advisory Techniques
  19. ‚ÜĎ (en) Web Content Accessibility Guidelines (WCAG) 2.0, Conformance Requirements
  20. ‚ÜĎ (en) WAI-ARIA Overview, W3C
  21. ‚ÜĎ (en) Authoring Tools Accessibility Guidelines 1.0, W3C
  22. ‚ÜĎ (en) Authoring Tool Accessibility Guidelines 2.0, W3C
  23. ‚ÜĎ (en) User Agent Accessibility Guidelines 1.0, W3C
  24. ‚ÜĎ (en) User Agent Accessibility Guidelines 2.0, W3C
  25. ‚ÜĎ (en) Essential Components of Web Accessibility, W3C
  26. ‚ÜĎ (en) User Agent Support for Accessibility, W3C
  27. ‚ÜĎ (en) Involving Users in Web Accessibility Evaluation, W3C
  28. ‚ÜĎ (en) Conformance Evaluation of Web Sites for Accessibility, W3C
  29. ‚ÜĎ (en) Using Combined Expertise to Evaluate Web Accessibility, W3C
  30. ‚ÜĎ (en) Developing Organizational Policies on Web Accessibility, W3C
  31. ‚ÜĎ (en) Comparison of WCAG 1.0 checkpoints to WCAG 2.0, W3C

Autres 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. ‚ÜĎ Elie 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, 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. Voir la d√©finition de l'accessibilit√© du web par 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 Elie 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), 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) Michael Cooper, Web Accessibility in the Future, actes du Forum europ√©en de l'accessibilit√© num√©rique, 29 janvier 2007.
  14. ‚ÜĎ (fr) La loterie du longdesc, The WHATWG Blog, septembre 2007
  15. ‚ÜĎ Accessiweb
  16. ‚ÜĎ Anysurfer
  17. ‚ÜĎ (en) Unified Web Evaluation Methodology
  18. ‚ÜĎ (en) Chris Law, Julie Jacko, Paula Edwards, Programmer-focused website accessibility evaluations, ACM SIGACCESS Conference on Assistive Technologies, Baltimore, 2005
  19. ‚ÜĎ (en) Rick Ells, University of Washington, Building Accessibility Into The Workflow, Higher Education Web Developers Conference, 2005
  20. ‚ÜĎ (en) Rick Ells, University of Washington, Building Accessibility Into The Workflow, Higher Education Web Developers Conference, 2005
  21. ‚ÜĎ (en) Rick Ells, University of Washington, Building Accessibility Into The Workflow, Higher Education Web Developers Conference, 2005
  22. ‚ÜĎ WAVE
  23. ‚ÜĎ OCAWA
  24. ‚ÜĎ (en) Michael Cooper, Web Accessibility in the Future, actes du Forum europ√©en de l'accessibilit√© num√©rique, 29 janvier 2007.
  25. ‚ÜĎ Les nouveaux d√©fis de l'accessibilit√© num√©rique : 1- la vision actuelle, Elie Slo√Įm, Openweb, 14 f√©vrier 2008.
  26. ‚ÜĎ 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
  27. ‚ÜĎ A 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
  28. ‚ÜĎ (en) Andy Clarke, Accessibility and a society of control, 18 juin 2005.
  29. ‚ÜĎ BrailleNet
  30. ‚ÜĎ HandicapZ√©ro
  31. ‚ÜĎ WebSourd
  32. ‚ÜĎ (es) Technosite, Grupo Fundosa
  33. ‚ÜĎ Euracert, European eAccessibility Certification issu de ces trois organismes
  34. ‚ÜĎ (en) Vision Australia
  35. ‚ÜĎ (en) WebAIM
  36. ‚ÜĎ Circulaire du 7 octobre 1999 relative aux sites internet des services et des √©tablissements publics de l'√Čtat
  37. ‚ÜĎ 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.
  38. ‚ÜĎ (fr) R√©f√©rentiel accessibilit√© des services Internet de l‚Äôadministration fran√ßaise, version 2004 (format RTF)
  39. ‚ÜĎ Loi du 11 f√©vrier 2005 pour l'√©galit√© des droits et des chances, la participation et la citoyennet√© des personnes handicap√©es
  40. ‚ÜĎ Publication de RENO, le nouveau r√©f√©rentiel de normalisation pour les sites web du Gouvernement luxembourgeois, eLuxembourg.
  41. ‚ÜĎ (en) eAccessibility of public sector services in the European Union
  42. ‚ÜĎ (en) Global Audit of Web Accessibility, ONU
  43. ‚ÜĎ (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

Voir aussi

Lien externe

  • Portail sur Internet Portail sur Internet
Ce document provient de ¬ę Accessibilit%C3%A9 du Web ¬Ľ.

Wikimedia Foundation. 2010.

Contenu soumis à la licence CC-BY-SA. Source : Article Accessibilite du Web de Wikipédia en français (auteurs)

Regardez d'autres dictionnaires:

  • Accessibilit√© Du Web ‚ÄĒ L accessibilit√© du Web est la probl√©matique de l acc√®s aux services et contenus en ligne pour les handicap√©s et les seniors. D√©finie par des normes techniques √©tablies par la Web Accessibility Initiative (WAI) du World Wide Web Consortium (W3C),… ‚Ķ   Wikip√©dia en Fran√ßais

  • Accessibilit√© du web ‚ÄĒ L accessibilit√© du Web est la probl√©matique de l acc√®s aux services et contenus en ligne pour les handicap√©s et les seniors. D√©finie par des normes techniques √©tablies par la Web Accessibility Initiative (WAI) du World Wide Web Consortium (W3C),… ‚Ķ   Wikip√©dia en Fran√ßais

  • Accessibilit√© du Web ‚ÄĒ L accessibilit√© du Web est la probl√©matique de l acc√®s aux services et contenus en ligne pour les handicap√©s et les seniors. D√©finie par des normes techniques √©tablies par la Web Accessibility Initiative (WAI) du World Wide Web Consortium (W3C),… ‚Ķ   Wikip√©dia en Fran√ßais

  • Accessibilit√© Web ‚ÄĒ Accessibilit√© du Web L accessibilit√© du Web est la probl√©matique de l acc√®s aux services et contenus en ligne pour les handicap√©s et les seniors. D√©finie par des normes techniques √©tablies par la Web Accessibility Initiative (WAI) du World Wide… ‚Ķ   Wikip√©dia en Fran√ßais

  • Web accessibility ‚ÄĒ Accessibilit√© du Web L accessibilit√© du Web est la probl√©matique de l acc√®s aux services et contenus en ligne pour les handicap√©s et les seniors. D√©finie par des normes techniques √©tablies par la Web Accessibility Initiative (WAI) du World Wide… ‚Ķ   Wikip√©dia en Fran√ßais

  • Accessibilite aux personnes handicapees ‚ÄĒ Accessibilit√© aux personnes handicap√©es L accessibilit√© aux personnes handicap√©es concerne la possibilit√© pour les personnes handicap√©es d acc√©der √† un lieu physique ou √† des informations. Cette passerelle est munie de deux ascenceurs pour… ‚Ķ   Wikip√©dia en Fran√ßais

  • Accessibilit√© Aux Personnes Handicap√©es ‚ÄĒ L accessibilit√© aux personnes handicap√©es concerne la possibilit√© pour les personnes handicap√©es d acc√©der √† un lieu physique ou √† des informations. Cette passerelle est munie de deux ascenceurs pour permettre aux personnes handicap√©es de… ‚Ķ   Wikip√©dia en Fran√ßais

  • Accessibilite numerique ‚ÄĒ Accessibilit√© num√©rique L accessibilit√© num√©rique consiste en la mise √† la disposition de tous les individus, quel que soit leur mat√©riel ou logiciel, leur infrastructure r√©seau, leur langue maternelle, leur culture, leur localisation… ‚Ķ   Wikip√©dia en Fran√ßais

  • Accessibilit√© Num√©rique ‚ÄĒ L accessibilit√© num√©rique consiste en la mise √† la disposition de tous les individus, quel que soit leur mat√©riel ou logiciel, leur infrastructure r√©seau, leur langue maternelle, leur culture, leur localisation g√©ographique, ou leurs aptitudes… ‚Ķ   Wikip√©dia en Fran√ßais

  • Web Design ‚ÄĒ Le web design d√©signe la conception de l interface web : l‚Äôarchitecture interactionnelle, l‚Äôorganisation des pages, l‚Äôarborescence et la navigation d‚Äôun site web. Il s‚Äôagit d‚Äôune phase essentielle dans la conception d‚Äôun tel site. La… ‚Ķ   Wikip√©dia en Fran√ßais


Share the article and excerpts

Direct link
… Do a right-click on the link above
and select ‚ÄúCopy Link‚ÄĚ

We are using cookies for the best presentation of our site. Continuing to use this site, you agree with this.