Avertissement: la migration du RGAA vers un nouveau site pour la publication de sa version finale étant en cours, les liens ci-dessous ne sont plus disponibles. Vous pouvez cependant vous reporter à la version de l'appel à commentaire au format PDF.

Aujourd'hui est officiellement ouvert en accès public un outil majeur pour l'accessibilité, à la création duquel j'ai eu la chance de participer activement ces derniers mois: le Référentiel Général d'Accessibilité des Administrations, pour lequel la Direction Général de la Modernisation de l'Etat (DGME) avait fait un appel d'offres auquel ont répondu Tektonika et Temesis.

Tout en laissant à Elie Sloim et à Aurélien Levy, qui furent les autres piliers de cette entreprise avec Alain Simeray et Agnès Brouard, le soin de vous décrire la démarche, la philosophie de cet outil et sa structure détaillée, je souhaiterai ici pointer plus précisément, à travers quelques exemples, certains aspects à mes yeux exemplaires, ou au moins significatifs de la méthode de déploiement WCAG que nous avons souhaité proposer.

Les WCAG1.0 intégralement déployées

Vous retrouverez dans le RGAA les 14 directives WCAG1.0 et leurs 65 points de contrôle, jusqu'au niveau AAA et dans une structure identique. Ce choix d'une structure reprenant celle de WCAG1.0 était pour nous un facteur clé de rigueur du document et du respect des normes internationales.

Ceci explique le traitement spécifique des points de contrôles temporaires de WCAG1.0, dont certains ne sont plus justifiés aujourd'hui, en raison des implémentations dans les agents utilisateurs ou des pratiques. Certains points sont donc déclarés explicitement obsolètes (au sens W3C du terme), et en particulier l'utilisation du texte par défaut des champs de formulaire pour en indiquer la fonction : il s'agissait de tenir compte de l'évolution des implémentations dans les aides techniques, mais aussi de la difficulté que l'on peut avoir parfois dans un lecteur d'écran à identifier la présence de contenus par défaut non anticipables dans un champ de formulaire, avec le risque qui en découle d'y ajouter sa propre saisie et de soumettre des données aberrantes. Notons que, de manière complémentaire, le rôle du title des champs de formulaire comme substitut possible des labels a été pris en compte suite aux avancées WCAG2.0

Inversement, certains de ces points temporaires ont fait l'objet d'une remise à jour et non d'une déclassification. Reste donc notamment applicable, mais dans une optique actualisée, la séparation visuelle explicite des liens adjacents. Sur ce dernier point, vous constaterez en effet la disparition du fameux caractère imprimable de séparation des liens adjacents (justifiée par les implémentations), au profit d'une gestion aussi complète que possible de la séparation visuelle et graphique des liens, toujours pertinente pour de nombreux utilisateurs handicapés visuels en particulier.

Pour compléter ce premier trait caractéristique du RGAA, il faut insister ici sur le sens précis des qualifications de tests, tel qu'il est explicité dans le glossaire du référentiel :

Obligatoire

Un test obligatoire pour la version annuelle du référentiel concernée doit être validé.

Recommandé

Un test recommandé pour la version annuelle du référentiel concernée peut ne pas être validé. Cependant, sa validation constituera une amélioration importante, et permettra d'anticiper les exigences ultérieures du référentiel.

En fin du premier cycle de déploiement qui va s'amorcer, les recommandations ne devraient donc être enfreintes que de manière exceptionnelle et motivée par des contraintes de production :

Ce niveau de préconisation signifie qu’il peut exister des raisons valables, dans des circonstances particulières, pour ignorer la règle édictée, mais les conséquences doivent être comprises et pesées soigneusement avant de choisir une voie différente.

Cest bien le niveau AAA qu'il s'agit d'atteindre autant que possible, et de gérer de manière suivie, au plus près.

Niveau de priorité WCAG et déploiement progressif

Les trois niveaux de priorité WCAG sont naturellement inchangés, et ont été l'un des éléments clés dans la répartition des différents tests unitaires sur la durée maximale de 3 ans prévue dans le cadre du RGAA. Il faut cependant souligner que le but de cette répartition n'est pas de faire coïncider les années de déploiement avec un éventuel passage successif par les niveaux A, AA et AAA : le déploiement annuel est en effet un arbitrage nécessaire entre niveau de priorité, difficulté de mise en oeuvre et difficulté de test, tenant compte de contextes de production extrêmement variés.

A titre d'exemple, le déploiement des alternatives textuelles a fait l'objet d'une réflexion particulièrement approfondie, et d'ailleurs de longues discussions au sein du collège d'experts qui ont participé à la première phase de commentaires sur le document. La progression proposée n'exigeant pas la mise en place immédiate d'alternatives pertinentes, en une seule étape, récapitulons ici le déploiement proposé concernant les images :

• année 1, mettre en place les bases techniques:
  • présence de l'attribut alt.
  • alternative vide pour les éléments décoratifs.
• année 2, assurer des contenus perceptibles, compréhensibles et utilisables:
  • pertinences des alternatives d'images, des alternatives fournies par le contexte, et des alternatives spécifiques (images liens, zones d'image map, boutons, images générées via javascript).
• année 3, améliorer l'accès à l'information:
  • présence et pertinence des descriptions longues.
  • gestion plus fine des images n'apportant pas d'information dans leur contexte, et des éventuelles redondances apportées jusque là par certaines alternatives textuelles.

Il s'agit donc d'obtenir le niveau d'accessibilité requis au terme du cycle, via des gains substantiels chaque année. L'accès à l'information est amélioré de manière régulière, en tenant compte de difficultés telles que la formation des rédacteurs de contenus, qui produisent ces alternatives, ou l'évolution des outils de back office qui vont les assister dans cette tâche. Enfin, rappelons que ce cycle de 3 ans n'est qu'une des méthodes de déploiement possibles, et qu'il reviendra à chaque responsable de projet de déterminer ce qui peut être anticipé à chaque étape (parmi les critères "recommandés"), ou d'opter pour une prise en compte immédiate de l'ensemble des critères.

Une démarche globale

Un autre trait important que je souhaiterais relever est l'incitation à la prise en compte globale des problématiques d'accessibilité de contenu. A titre d'exemple, un test précis (1.1.14, Longueur des contenus d'attribut alt.) surprendra peut-être en déterminant que Si le contenu de l'attribut alt est le plus concis possible, le test est validé. Il n'y a donc pas de limite chiffrée de longueur des alternatives d'images, ni d'ailleurs des libellés et title de liens (test 13.1.5, Longueur des intitulés de liens), mais une contrainte qui permet de tenir compte du contexte précis du contenu: être le plus concis possible.

Ce choix a été motivé par :

• l'absence de limite formelle définie par WCAG, ni HTML.
• l'absence de données permettant de trancher par ailleurs en faveur d'une éventuelle limite chiffrée de manière suffisamment précise (60 ? 80 ? 100 ?)
• la prise en compte du problème récurrent des contenus non modifiables par les auteurs, quand il s'agit par exemple d'intitulés officiels, régulièrement invalidants à un ou quelques caractères près.
• et surtout, la prise en compte (Test 13.8.1, Rédaction simple et compréhensible de tous) de la directive WCAG conduisant à placer l'information importante au début de la phrase et du paragraphe, qui garantit donc que l'accès à l'information clé sera immédiat quelle que soit la longueur d'une alternative ou d'un libellé, et quel que soit le périphérique de sortie ou l'aide technique.

Dans le même ordre d'idées, on peut également relever ici le caractère uniquement recommandé du déploiement du balisage abbr et acronym, étant donné les problèmes de gestion rédactionnelle qu'ils posent, à mettre en lien avec le point de contrôle 14.1 Utiliser un langage clair et simple et le rôle du glossaire : la gestion de cette problématique des contenus à expliciter ne doit pas être une série de "patchs" ponctuels, mais une démarche menée à travers l'ensemble de la gestion des contenus, dans laquelle ce glossaire et la prise en compte des alternatives en contexte jouent un rôle essentiel.

Par ailleurs, les contenus Web ne s'arrêtant pas à la page HTML, il faut mentionner la problématique spécifique des documents PDF, ou encore celle de interfaces spécifiques aux objets programmables : ces points de contrôle sont autant de premiers pas vers la vaste entreprise de travail documentaire et pédagogique à mener plus précisément sur ces contenus (entreprise pour l'instant au-delà du champ donné à cette version du RGAA).

Enfin, on ne peut manquer de rappeler que la problématique de l'accessibilité n'est pas uniquement celle des contenus : un travail essentiel s'amorce aujourd'hui par exemple dans le domaine des outils de production de contenu, et notamment des CMS. Pour tout dire, et comme vous y invite d'ailleurs le champ Impact de chaque point du contrôle du RGAA, c'est en réalité l'intégration de l'accessibilité tout au long de la chaîne de production dont le site Web n'est qu'un maillon qui doit être à présent notre objectif majeur, à la fois au bénéfice des utilisateurs et pour les gains induits dans la maîtrise des services en ligne côtés propriétaires et responsables de sites (A ce propos, je vous avouerais être de plus en plus convaincu et passionné par le rôle stratégique des rédacteurs de contenus, de leur formation, et de l'assistance à leur apporter via les outils de workflow et les règles éditoriales).

Notre souhait est, en fait, que le RGAA soit pour vous une invite à ce triple élargissement de la démarche d'accessibilité : à l'échelle de toutes les stratégies complémentaires au sein de WCAG1.0, puis à celle de tous vos contenus Web quelque-soit leur type, et enfin à celle de leur contexte de production et de votre maîtrise de celui-ci.

Une voie réaliste

L'une des ambitions clés de notre démarche a été une certaine forme de réalisme qui, sans faire de concessions sur l'accessibilité réelle, tienne compte du succès mitigé rencontré par les méthodes du "tout ou rien".

Dans le domaine des contenus, la mise en place de descriptions audio synchronisées des contenus multimédias reste au stade de recommandation et n'a pas de caractère obligatoire final : sachant la difficulté et le coût potentiel de mise en oeuvre de cette mesure dans certains contextes, il eût été illusoire d'en faire une obligation formelle, et de courir ainsi le risque de détourner certains acteurs d'une démarche qu'ils jugeraient impraticable à partir de cette seule contrainte. Le RGAA donne à l'inverse aux sites qui en auront la capacité la possibilité de déployer cette mesure d'accessibilité, sans en faire un facteur bloquant pour les autres. Soulignons enfin que l'accessibilité réelle des contenus multimédias est dans tous les cas garantie par la mise en place des transcriptions textuelles des contenus sonores et vidéo.

De même, côté structure, la validité (X)HTML n'est requise qu'au sens de WCAG2.0 : Si les erreurs de validation ne concernent pas l'imbrication des balises dans l'arbre du document ou l'écriture des balises et des attributs, le test est validé. L'invalidité n'est, à coup sûr, pas le chemin ni la démarche la plus avisée pour une gestion aisée de l'accessibilité, mais elle peut être une nécessité face à un blocage dans un contexte de production donné, ou encore face à un risque de surqualité. Il importait donc d'en délimiter le champ de prise en compte.

Pour le graphisme proprement dit, ceci s'illustre également en matière de gestion des contrastes de couleurs : l'outil de mesure de ceux-ci est celui élaboré dans le cadre de WCAG2.0. Cependant, le ratio à atteindre a été réduit par rapport au document du travail actuel de WCAG 2.0, passant de 5 à 4 : cette valeur déterminée en fonction de l'expérience experte ouvre en effet la voie à une plus grande liberté de design, tout en maintenant l'accessibilité selon les différents handicaps visuels.

Enfin, pour l'aspect CSS, on peut mentionner la définition précise du critère de tolérance d'un design à l'agrandissement des tailles des caractères, ou encore... le rappel parfois nécessaire de l'admissibilité des tableaux de présentation en cas d'insuffisance des possibilités offertes par CSS.

Tenir compte des pratiques et développements récents

Le périmètre du référentiel est déterminé par WCAG1.0, puisque celles-ci constituent actuellement la norme internationale en vigueur. Cependant, nous avons naturellement tenu compte à la fois des évolutions en cours d'élaboration dans le document de travail WCAG2.0, et de nos différents constats sur les usages actuels des techniques (X)HTML, CSS, javascript, Flash, etc.

Ainsi, parmi les "bonnes pratiques" récentes d'accessibilité promues par le RGAA, on peut citer l'usage du fil d'ariane, celui des liens d'accès rapide en complément des liens d'évitement, la négociation de contenus internationalisés ou encore la prise en compte systématique du media print.

Inversement, face à certaines "mauvaises pratiques", une attention particulière a été portée au besoin de favoriser des structures (X)HTML signifiantes, pertinentes et efficaces en termes d'accessibilité. C'est pourquoi, par exemple, les éléments de listes de définition sont explicitement réservés aux couples termes/définition, à l'exclusion des nombreux abus que l'on a vu fleurir ces deux dernières années, par pure facilité de codage, et trop souvent au détriment de structures plus utiles telles que les titres hiérarchiques hn et des éléments de listes. De même, le recours aux éléments de citation doit se faire de manière complète, et donc exploiter l'attribut cite pour la mention de la source lorsqu'elle existe.

On peut encore relever ici l'attention particulière qui a été portée aux mésusages des styles CSS, que l'on voit de plus en plus fréquemment devenir des facteurs d'inaccessibilités en dépit de leur rôle théorique, tels que :

• Les contenus générés explicitement en CSS(content) ou surtout implicitement (background).
• Les altérations de l'ordre linéaire de l'information.

CSS n'est en effet pas un synonyme nécessaire d'accessible, loin s'en faut : tout comme la validité du code, la séparation entre la structure et sa mise en forme n'est qu'un outil, dont il convient de faire un usage avisé, dans une démarche globale d'accessibilité reposant avant tout sur une gestion robuste des contenus.

Et maintenant ?

Après le travail passionnant mené initialement avec Aurélien Levy (dont je salue la titanesque puissance de travail), Elie Sloïm et Agnès Brouard pour la rédaction des contenus, ainsi que Fabrice Bonny pour la mise en place de l'outil de gestion de ceux-ci, le tout sous le pilotage d'Elie Sloïm et d'Alain Simeray, un premier appel à commentaires restreint récemment achevé a permis d'affiner et d'enrichir le référentiel. Que tous les experts et intervenants soit ici remerciés pour leur relecture attentive et ce qu'ils ont su débusquer dans ce vaste corpus. Une phase de commentaires publics s'ouvre aujourd'hui, jusqu'à la fin juin : je gage qu'elle nous permettra de nouveaux progrès, certainement au moins du côté de la didactique et de la pédagogie, en vue de la version finale 1.0 du RGAA.

Parallèlement, des premières évaluations d'accessibilité ont déjà été menées à l'aide du RGAA, et mises en parallèle avec les différents outils européens : nous avons pu vérifier la pertinence du déploiement RGAA dans un contexte de validation européenne ou d'éventuelle labellisation nationale. De même, j'ai eu l'occasion de constater la maniabilité du référentiel dans le contexte d'études et d'audits ATAG d'outils de gestion de contenu. Comme tout autre outil, le RGAA est perfectible, mais la démarche collaborative qui a été à sa source nous a permis, il me semble, de mettre en place un outil robuste et fiable.

Je vous invite donc non seulement à découvrir et à commenter le RGAA canal Web (par les moyens qui vous sont proposés par la DGME, ou encore ici-même), mais surtout à le mettre en oeuvre. Nous aurons dans tous les cas l'occasion d'en reparler ici plus précisément dans les semaines à venir