Votre navigateur n'accepte pas les coockies
Accueil

Accessibilité : Le cadre normatif et réglementaire : du WCAG au RGAA

1-W3C, Web Accessibility Initiative et norme WCAG

L’acronyme WCAG signifie Web Content Accessibility Guidelines, c‘est-à-dire l’ensemble des directives pour l’accessibilité des contenus Web. Ce standard fut développé à la fin du siècle dernier par la WAI (Web Accessibility Initiative), un groupe de travail du W3C (World Wide Web Consortium). Le W3C est un consortium international d’acteurs influents dans le domaine des nouvelles technologies de l’information et des communications qui édictent bon nombre des standards liés au Web.

La version 2.0 du standard WCAG présente 61 critères de succès distincts classés en 14 directives, permettant de rendre les contenus davantage accessibles aux personnes handicapées. L’application de ces mêmes critères de succès présente également un impact positif et direct sur l’utilisation des contenus Web par les populations vieillissantes.

Les règles et les critères de succès des WCAG 2.0 sont souvent de portée plus générale que ce que l’on pouvait lire dans la version 1.0. Cela tient au fait que la version 2.0 s’adresse à l’ensemble des technologies utilisées sur le Web alors que les WCAG 1.0 étaient beaucoup plus centrées sur les technologies HTML et CSS.

2-Les méthodes d‘applications de WCAG

Les présentes directives expliquent comment rendre les contenus Web accessible aux personnes handicapées.
Ces directives ont été écrites à l’attention de tous les créateurs de contenu pour le Web (auteurs de pages et concepteurs de sites) et des développeurs d’outils de création de contenu.
L’objectif principal de ces directives est de promouvoir l‘accessibilité [aux personnes handicapées]. Cependant, en les suivant, le contenu Web s’en trouvera plus accessible à tous les utilisateurs, indépendamment du programme utilisateur (par exemple, logiciel de consultation bureautique [browser], logiciel vocal, téléphone mobile, ordinateur personnel embarqué dans une automobile, etc.) et quelques soient les contingences imposées par l’environnement d’utilisation (par exemple, lieu bruyant, sur- ou sous-éclairé, en gardant les mains libres etc).
En suivant ces directives, on permettra également aux utilisateurs de trouver de l’information sur le Web plus rapidement.
Ces directives ne cherchent pas à décourager l’utilisation par les créateurs de contenu d’images, de vidéo, etc, mais expliquent plutôt comment rendre les contenus multimédias plus accessibles à une large audience.

Chaque directive détermine un ou plusieurs points de contrôles.

Chaque point de contrôle a un niveau de priorité assigné par le groupe de travail basé sur son impact sur l‘accessibilité.

[Priorité 1]

Un développeur de contenu web doit respecter ce point de contrôle. Sinon, un ou plusieurs groupes se trouveront dans l‘impossibilité d‘accéder à l‘information contenue dans le document. Respecter ce point de contrôle est une condition de base pour permettre à certains groupes d‘utiliser des documents Web.

[Priorité 2]

Un développeur de contenu web devrait respecter ce point de contrôle. Sinon, un ou plusieurs groupes vont éprouver des difficultées pour accéder à l‘information contenue dans le document. Respecter ce point de contrôle supprimera des barrières importantes à l‘accessibilité des documents web.

[Priorité 3]

Un développeur de contenu web peut répondre à ce point de contrôle. Sinon, un ou plusieurs groupes vont éprouver dans une certaine mesure des difficultées pour accéder à l‘information contenue dans le document. Respecter ce point de contrôle améliorera l‘accessibilité des documents web.

Certains points de contrôle spécifient un niveau de priorité qui peut changer dans certaines conditions (indiquées).

Directive 1. Fournir des alternatives équivalentes au contenu visuel et auditif

Directive 2. Ne pas s’en remettre exclusivement aux couleurs

Directive 3. Utiliser le balisage HTML et les feuilles de style CSS de façon appropriée

Directive 4. Clarifier l’utilisation du langage naturel

Directive 5. Créer des tableaux qui se transforment de façon élégante

Directive 6. S’assurer que les pages qui contiennent de nouvelles technologies se transforment de façon élégante

Directive 7. Assurer à l‘utilisateur le contrôle des changements du contenu lorsque ce dernier varie dans le temps

Certaines personnes souffrant d‘incapacités mentales ou visuelles ne peuvent pas lire un texte lorsqu‘il bouge. Les mouvements peuvent causer une telle distraction que le reste d‘une page peut devenir illisible pour des gens souffrant de handicap cognitif. Les dispositifs vocaux de lecture d‘écran ne peuvent lire un texte en mouvement. Certaines personnes souffrant de handicap physique pourraient ne pas être en mesure de bouger suffisemment vite ou précisément pour interagir avec des objets en mouvement.

Directive 8. Assurer un accès direct aux interfaces utilisateur intégrées

Directive 9. Concevoir en respectant l’indépendance par rapport au périphérique

Directive 10. Utiliser des solutions intermédiaires en attendant que les agents utilisateurs aient un meilleur support de l‘accessibilité.

Directive 11. Utiliser les technologies et directives du W3C

Les directives actuelles recommandent l‘utilisation des technologies du W3C (Par ex. HTML, CSS, etc.) pour plusieurs raisons :

Plusieurs standards non-W3C (par ex. PDF, Shockwave, etc.) reposent sur l‘utilisation de plug-ins ou de logiciels séparés pour la visualisation. Souvent, on ne peut consulter ou regrader le contenu à ces formats avec les agents-utilisateurs courants (y compris les technologies d‘assistance). En évitant d‘utiliser des technologies non-W3C ou non-standard (éléments, attributs, propriétés et extension propriétaires) on pourra produire des pages plus accessibles, et accessibles à plus de gens utilisant une plus grande variété de matériel et de logiciels. Lorsque l‘on doit utiliser des technologies non-accessibles (propriétaires ou non), on devra prévoir des pages accessibles équivalentes.

Même lorsqu‘on utilise des technologies du W3C, on doit respecter les directives d‘accessibilité. Lorsque on utilise des technologies récentes, on s‘assurera qu‘elles se transforment de façon élégante. (Voir également la directive 6.)

Note. Convertir des documents (à partir de PDF, PostScript, RTF, etc.) en un langage de balisage du W3C (HTML, XML) ne permet pas toujours de créer un document accessible. Ainsi, validez chaque page pour vérifier l‘accessibilité et l‘utilisabilité après la conversion (voir la section sur la validation). Si une page n‘est pas valide directement, modifiez la page jusqu‘à ce que la représentation originale soit convertie correctement ou fournissez une version HTML ou texte seul.

Directive 12. Fournir des informations de contexte et d’orientation

Directive 13. Fournir des mécanismes de navigation clairs

Des mécanismes de navigation clairs et cohérents sont primordiaux pour les personnes souffrant de difficultés de compréhension ou de vision

Un mécanisme de navigation est n‘importe quel moyen par lequel un utilisateur peut naviguer à l‘intérieur d‘une page ou d‘un site. Quelques mécanismes caractéristiques :

Barres de navigation
Une barre de navigation rassemble les liens vers les parties les plus importantes d‘un document ou d‘un site.
Cartes de site
Une carte d‘un site fournit une vue générale de l‘organisation d‘une page ou d‘un site.
Table des matières
Une table des matières liste généralement les parties les plus importantes d‘un document ou d‘un site et fournit des liens y conduisant

Directive 14. S’assurer que les pages sont claires et simples

Une mise en page cohérente, des graphismes identifiables et un langage facile à comprendre pourront bénéficier à tous les utilisateurs. En particulier, ils aideront les personnes souffrant de difficulté de compréhension, ou qui ont des problèmes de lecture. (Cependant assurez vous que les images ont des équivalents textuels pour les non-voyants, les mal voyants, ou pour les utilisateurs qui ne peuvent pas ou ont choisi de ne pas voir les images. Voir également la directive 1.)

Une communication efficace passe par l‘utilisation d‘un langage clair et simple. L‘accès à l‘information écrite peut être difficile pour les personnes souffrant de problèmes de compréhension ou d‘apprentissage. Les personnes dont la langue maternelle diffère de la votre, ou ceux qui utilisent le langage des signes tireront avantage d‘une langue claire et simple.

3-Le cadre réglementaire en France : le RGAA

Le 7 octobre 1999, la circulaire du Premier ministre relative aux sites Internet des services et des établissements publics de l‘État, 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 ».

En décembre 2003, Julien PERBEN du Secrétariat d‘État aux personnes handicapées, écrit un rapport d‘étude sur l‘accessibilité de l‘Internet-Intranet aux personnes handicapées. Cette étude est menée dans le cadre du plan national de diffusion des nouvelles technologies auprès des personnes handicapées.
Il recommande notamment la création d‘un d‘un « centre ressources pour le conseil et la formation », d‘un « cadre général clair pour une meilleure prise en compte des critères d‘accessibilité des sites », et enfin d‘un « organisme officiel de certification, totalement habilité à effectuer ce type de travail par son indépendance ».

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 (www.braillenet.org) sur la base de la norme internationale WCAG1.0, complétés par des préconisations ergonomiques. Il n‘a pas de caractère obligatoire.

En 2005, l‘obligation d‘accessibilité du Web public est légalement créée par l‘article 47 de la loi n° 2005-102 du 11 février 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. ».

La direction générale de la modernisation de l‘État (DGME) devient le moteur du projet pour la création du référentiel général d‘accessibilité pour les administrations (RGAA), publié dans sa version finale en octobre 2009. Complément du référentiel général d‘interopérabilité, le RGAA est une traduction en français de la norme WCAG2.0, complétée par un guide d‘accompagnement. Celui-ci présente une méthode de déploiement par critère de succès WCAG et un référentiel de tests d‘évaluation de l‘accessibilité des contenus web. Le RGAA ne prend en revanche pas en compte l‘impact des outils de production automatisée du Web, tel que le prévoit ATAG 2.0.

La loi n°2005-102 du 11 février 2005, son décret d‘application n°2009-546 du 14 mai 2009 et l’arrêté au journal officiel publié le 29 octobre 2009, obligent les administrations françaises à se référer au Référentiel Général d’Accessibilité des Administrations ( RGAA, version V2.2 en date du 23/10/09) pour attester de la conformité de leurs services en ligne aux WCAG 2.0, selon les niveaux A et AA.

Priorités

Chaque point de contrôle a un niveau de priorité assigné par le groupe de travail basé sur son impact sur l‘accessibilité.

[Priorité 1]
Un développeur de contenu web doit respecter ce point de contrôle. Sinon, un ou plusieurs groupes se trouveront dans l‘impossibilité d‘accéder à l‘information contenue dans le document. Respecter ce point de contrôle est une condition de base pour permettre à certains groupes d‘utiliser des documents Web.
[Priorité 2]
Un développeur de contenu web devrait respecter ce point de contrôle. Sinon, un ou plusieurs groupes vont éprouver des difficultées pour accéder à l‘information contenue dans le document. Respecter ce point de contrôle supprimera des barrières importantes à l‘accessibilité des documents web.
[Priorité 3]
Un développeur de contenu web peut répondre à ce point de contrôle. Sinon, un ou plusieurs groupes vont éprouver dans une certaine mesure des difficultées pour accéder à l‘information contenue dans le document. Respecter ce point de contrôle améliorera l‘accessibilité des documents web.

Certains points de contrôle spécifient un niveau de priorité qui peut changer dans certaines conditions (indiquées).

Points de contrôle de priorité 1

En général (Priorité 1) Oui Non N/A
1.1 Fournissez un texte équivalent pour chaque élément non textuel (i.e., via "alt", "longdesc", ou dans le contenu de l‘élément). Ceci inclut : des images, des représentations graphiques de textes (incluant des symboles), des régions d‘hyperimages, des animations (i.e., des GIFs animés), des applets et des objets, de l‘art ascii, des frames, des scripts, des images utilisées comme des puces, des séparateurs, des boutons graphiques, des sons (joués avec ou sans l‘interaction de l‘utilisateur), des fichiers audios autonomes, des pistes audios de vidéos, et des vidéos.      
2.1 Assurez-vous que toute l‘information transportée par la couleur est également disponible sans, par exemple par le contexte ou des balises.      
4.1 Identifiez clairement les changements de langue du texte d‘un document et de tous les équivalents textuels (i.e., les légendes).      
6.1 Organizez les documents de façon à ce qu‘il puissent être lus sans feuille de style. Par example, quand un document HTML est affiché sans feuille de style associée, il doit être encore possible de le lire.      
6.2 Assurez-vous que les équivalents pour le contenu dynamique sont mis à jour quand ce contenu change.      
7.1 Tant que les agents utilisateurs (navigateurs) n‘autorisent pas les utilisateurs à contrôler le scintillement, évitez de faire scintiller l‘écran (clignotements, animations).      
14.1 Employez le langage le plus clair et le plus simple, de la manière la plus appropriée au contenu d‘un site.      
Et si vous utilisez des images et des hyperimages (Priorité 1) OuiNonN/A
1.2 Fournissez du texte redondant pour chaque région active côté serveur d‘une hyperimage .      
9.1 Fournissez des images avec régions actives côté client plutôt que côté serveur sauf si ces zones ne peuvent pas être définies avec une forme géométrique disponible.      
Et si vous utilisez des tableaux (Priorité 1) OuiNonN/A
5.1 Pour des tableaux de données, identifiez les entêtes des lignes et des colonnes.      
5.2 Pour des tableaux de données qui ont deux ou plusieurs niveaux logiques d‘entêtes de lignes et de colonnes, utilisez des balises pour associer les cellules de données avec les cellules d‘entêtes.      
Et si vous utilisez des frames (Priorité 1) OuiNonN/A
12.1 Donnez un titre à chaque frame pour faciliter leur identification ainsi que la navigation.      
Et si vous utilisez des applets et des scripts (Priorité 1) OuiNonN/A
6.3 Assurez-vous que les pages sont utilisables quand les scripts, applets, ou tout autre objets programmés sont désactivés ou non supportés. Si ce n‘est pas possible, fournissez une information équivalente sur une page alternative et accessible.      
Et si vous utilisez des documents multimédia (Priorité 1) OuiNonN/A
1.3 Tant que les agents utilisateurs ne peuvent pas lire à voix haute le texte équivalent d‘une piste visuelle, fournissez une desciption auditive des informations importantes de la piste visuelle d‘une présentation multimédia.      
1.4 Pour n‘importe quelle présentation multimédia basée sur le temps (i.e., un film ou une animation), synchronisez les alternatives équivalentes (i.e., sous-titres ou descriptions auditives d‘une piste visuelle) avec la présentation.      
Et si tout ça échoue (Priorité 1) OuiNonN/A
11.4 Si, après vos plus grands efforts, vous ne pouvez pas créer une page accessible, fournissez un lien vers une page alternative qui utilise les technologies du W3C, qui est accessible, a une information équivalente (ou une fonctionnalité), et qui est mise à jour aussi souvent que la page inaccessible (originale).      

Points de contrôle de priorité 2

En général (Priorité 2) Oui Non N/A
2.2 Assurez-vous que la combinaison des couleurs d‘arrière plan et d‘avant plan fournit un contraste suffisant lorsqu‘elle est vue par quelqu‘un ayant une déficience au niveau des couleurs ou lorsqu‘elle est vue sur un écran noir et blanc. [Priorité 2 pour les images, Priorité 3 pour le texte].      
3.1 Quand une balise du langage existe, utilisez la balise plutôt que des images pour transmettre de l‘information.      
3.2 Créez des documents qui soient validés par la grammaire formelle publiée.      
3.3 Utilisez des feuilles de styles pour contrôlez la mise en page et la présentation.      
3.4 Utilisez des unités relatives plutôt qu‘absolues dans les valeurs des attributs du langage de balises et dans les valeurs des propriétés des feuilles de styles.      
3.5 Utilisez des entêtes d‘éléments pour indiquer la structure d‘un document et utilisez-les selon les spécifications.      
3.6 Balisez correctement les listes et leurs éléments.      
3.7 Balisez les citations. N‘utilisez pas les balises de citations pour réaliser des effets de formattage tels que l‘indentation.      
6.5 Assurez-vous que le contenu dynamic est accessible ou qu‘une page ou une présentation alternative soit fournie.      
7.2 Tant que les agents utilisateurs ne permettent pas à l‘utilisateur de contrôler le clignotement, éviter de faire clignoter le contenu (i.e., changer la présentation régulièrement, en l‘allumant et en l‘éteignant).      
7.4 Tant que les agents utilisateurs ne fournissent pas la possibilité d‘arrêter le raffraîchissement, ne créez pas de pages se raffraîchissant toutes seules périodiquement.      
7.5 Tant que les agents utilisateurs ne fournissent pas la possibilité d‘arrêter les auto-redirections, n‘utilisez-pas de balises pour rediriger les pages automatiquement. À la place, configurez le serveur pour effectuer les redirections.      
10.1 Tant que les agents utilisateurs ne fournissent pas la possibilité d‘empêcher l‘ouverture de fenêtres, ne provoquez pas l‘apparition de pop-ups ou d‘autres fenêtres et ne changez pas la fenêtre courante sans en informer l‘utilisateur.      
11.1 Utilisez les technologies du W3C quand elles sont disponibles et appropriées pour une tâche, et utilisez les dernières versions dès quelles sont supportées.      
11.2 Evitez les fonctionnalités dépréciées des technologies du W3C.      
12.3 Divisez les grands blocs d‘information en groupes plus maniables quand c‘est naturel et approprié.      
13.1 Identifiez clairement la cible de chaque lien.      
13.2 Fournissez des métadonnées pour ajouter des informations sémantiques aux pages et aux sites.      
13.3 Fournissez des informations à propos de la structure générale d‘un site (e.g., un plan du site ou une table des matières).      
13.4 Utilisez les mécanismes de navigation de manière cohérente.      
Et si vous utilisez des tableaux (Priorité 2) OuiNonN/A
5.3 N‘utilisez pas de tableaux pour la mise en page à moins que le tableau garde un sens une fois linéarisé. Sinon, si le tableau n‘est pas compréhensible, fournissez un équivalent alternatif (qui peut être une version linéarisée).      
5.4 Si un tableau est utilisé pour la mise en page, n‘utilisez aucune balise structurelle pour faire du formatage visuel.      
Et si vous utilisez des frames (Priorité 2) OuiNonN/A
12.2 Décrivez l‘objectif des frames et comment elles sont reliées les unes aux autres si ce n‘est pas clair avec leurs titres seuls.      
Et si vous utilisez des formulaires (Priorité 2) OuiNonN/A
10.2 Tant que les agents utilisateurs ne supportent pas explicitement l‘association entre les libellés et les contrôles de formulaires, pour tous les contrôles de formulaire avec un libellé implicitement associé, assurez-vous que le libellé est correctement positionné.      
12.4 Associés explicitement les libellés avec leurs contrôles.      
Et si vous utilisez des applets et des scripts (Priorité 2) OuiNonN/A
6.4 Pour les scripts et les applets, assurez-vous que les gestionnaires d‘évènements sont indépendants du périphérique d‘entrée.      
7.3 Tant que les agents utilisateurs ne permettent pas aux utilisateurs de geler un contenu mobile, évitez les mouvements dans les pages.      
8.1 Réalisez des éléments programmés tels les scripts et les applets directement accessibles ou compatibles avec les technologies d‘assistance [Priorité 1 si la fonctionnalité est importante et non présente ailleurs, sinon Priorité 2.]      
9.2 Assurez-vous que tout élément qui a sa propre interface peut-être opéré d‘une façon indépendante des périphériques.      
9.3 Pour les scripts, spécifiez des gestionnaires d‘évènements logiques plutôt que des gestionnaires d‘évènements indépendants des périphériques.      

Points de contrôle de priorité 3

En général (Priorité 3) Oui Non N/A
4.2 Indiquez la forme développée de chaque abréviation ou acronyme dans un document lors de sa première occurence.      
4.3 Indiquez la langue naturelle principale d‘un document.      
9.4 Créez un ordre de tabulation logique pour circuler entre les liens, contrôles de formulaires, et objets.      
9.5 Fournissez des raccourcis clavier pour les éléments importants, liens (en incluant ceux qui se trouvent dans les hyperimages côté client), contrôles de formulaires, et groupes de contrôles de formulaires.      
10.5 Tant que les agents utilisateurs (incluant les technologies d‘assistance) n‘afficheront pas les liens adjacents distinctement, incluez des non-liens, des caractères imprimables (entourrés par des espaces) entre deux liens adjacents.      
11.3 Fournissez de l‘information de manière à ce que les utilisateurs reçoivent les documents d‘après leurs préférences (e.g., langue, type de contenu, etc.)      
13.5 Fournissez des barres de navigation pour mettre en évidence et donner accès au mécanisme de navigation.      
13.6 Groupez les liens apparentés, identifiez le groupe (pour les agents utilisateurs), et, tant que les agents utilisateurs ne le font pas, fournissez un moyen de contourner le groupe.      
13.7 Si des fonctions de recherche sont fournies, activez différent types de recherches pour différents niveaux et différentes préférences d‘utilisateurs.      
13.8 Placez les informations caractéristiques au début des entêtes, paragraphes, listes, etc.      
13.9 Fournissez de l‘information à propos des collections de documents (i.e., des documents comprenants de multiples pages).      
13.10 Fournissez un moyen de sauter de l‘art ASCII sur plusieurs lignes.      
14.2 Complétez le texte avec des graphiques ou des présentations auditives quand cela facilitera la compréhension de la page.      
14.3 Créez un style de présentation qui est cohérent à travers les pages.      
Et si vous utilisez des images et des hyperimages (Priorité 3) OuiNonN/A
1.5 Tant que les agents utilisateurs n‘affichent pas de textes équivalents pour les liens d‘hyperimages côté client, fournissez des liens textuels redondants pour chaque région active d‘une hyperimage côté client.      
Et si vous utilisez des tableaux (Priorité 3) OuiNonN/A
5.5 Fournissez des résumés pour les tableaux.      
5.6 Fournissez des abréviations pour les libellés des entêtes.      
10.3 Tant que les agents utilisateurs (incluant les technologies d‘assistance) n‘afficheront pas correctement les textes côte à côte, fournissez une alternative texte linéaire (sur la page courante ou sur d‘autres) pour tous les tableaux qui mettent en page du texte en parallèle, des colonnes qui renvoient du texte à la ligne.      
Et si vous utilisez des formulaires (Priorité 3) OuiNonN/A
10.4 Tant que les agents utilisateurs ne traitent pas correctement des contrôles vides, incluez des valeurs par défaut, caractères place-holding dans les boîtes d‘édition et les zones de texte.