Le choix de structurer le Référentiel général d'Accessibilité pour les Administrations (RGAA) sur le modèle des Directives d'Accessibilité des Contenus Web 1.0 (WCAG1.0) répond à la fois à des contraintes institutionnelles et à un impératif de rigueur. Cependant, cette structure issue des WCAG répond à une logique spécifique, qui ne facilite guère l'approche du référentiel en fonction des profils opérationnels qui seront concernés par sa mise en oeuvre.

C'est pourquoi nous avons dans un premier temps attribué à chaque point de contrôle un champ "impact" qui permet de recenser les champs de compétences et d'intervention qu'il met en jeu, à travers 4 profils types :

• profil graphiste et ergonome
• profil développeur et intégrateur
• profil communiquant
• profil rédacteur et contributeur

Dans un second temps, le site du référentiel permettra d'accéder directement aux points de contrôles et aux tests en fonction de chacun de ces profils, ainsi qu'en fonction de thématiques liées aux contenus (contenus graphiques, contenus programmables, formulaires, etc.).

Dans l'immédiat, voici les points de contrôles RGAA listés (de manière brute) par profils, selon la répartition à la date de ce jour :

Profil graphiste et ergonome

• 2.1 Ne pas utiliser uniquement la couleur pour donner accès à l'information
• 2.2 Proposer des contrastes de couleurs suffisants
• 3.1 Remplacer les éléments non textuels par des styles CSS
• 5.5 Donner des informations complémentaires sur les tableaux de données
• 6.5 Assurer l'accessibilité des contenus dynamiques
• 10.2 Associer visuellement les étiquettes et champs de formulaire
• 10.5 Séparer visuellement les liens adjacents de manière explicite
• 11.4 En dernier recours, fournir une version alternative accessible
• 12.3 Regrouper les informations de même nature
• 12.4 Associer les champs de formulaire à leurs intitulés
• 13.1 Identifier la destination des liens
• 13.3 Fournir des informations sur l'architecture générale du site
• 13.4 Fournir des mécanismes de navigation cohérents
• 13.5 Proposer une barre ou un menu de navigation
• 13.9 Faciliter la navigation sur des groupes de pages
• 14.2 Proposer des illustrations visuelles ou sonores
• 14.3 Proposer une présentation cohérente sur tout le site

Profil développeur et intégrateur

• 1.1 Fournir une alternative textuelle aux éléments non textuels
• 1.2 Doubler les zones cliquables côté serveur
• 1.3 Fournir une description audio des contenus multimédias
• 1.4 Synchroniser les équivalents des contenus multimédias
• 2.1 Ne pas utiliser uniquement la couleur pour donner accès à l'information
• 3.1 Remplacer les éléments non textuels par des styles CSS
• 3.2 Créer des pages valides
• 3.3 Privilégier l'utilisation des feuilles de styles par rapport au balisage pour la présentation
• 3.4 Utiliser des unités relatives pour la présentation
• 3.5 Utiliser la hiérarchie de titres
• 3.6 Utiliser les éléments de liste de manière appropriée
• 3.7 Baliser correctement les citations
• 4.1 Indiquer les changements de langue
• 4.2 Spécifier la forme complète des abréviations et acronymes
• 4.3 Identifier la langue de traitement d'une page et son sens de lecture
• 5.1 Baliser les en-têtes de lignes et de colonnes
• 5.2 Associer les cellules de données aux en-têtes de lignes et de colonnes
• 5.3 Utiliser des tableaux pour la mise en page que si leur linéarisation est correcte
• 5.4 Ne pas utiliser d'éléments de tableaux de données pour des tableaux de mise en page
• 5.5 Donner des informations complémentaires sur les tableaux de données
• 5.6 Proposer des valeurs de remplacement pour les en-têtes de tableaux de données
• 6.1 Maintenir la lisibilité et la compréhension des contenus lorsque les styles sont désactivés
• 6.2 Mettre à jour les alternatives aux contenus dynamiques
• 6.3 Proposer une alternative au code javascript et aux éléments programmables
• 6.4 Assurer l'indépendance du périphérique d'accès aux fonctions javascript
• 6.5 Assurer l'accessibilité des contenus dynamiques
• 7.1 Eviter les changements brusques de luminosité
• 7.2 Eviter les clignotements des éléments
• 7.3 Eviter les mouvements de contenus
• 7.4 Ne pas rafraîchir automatiquement les pages
• 7.5 Ne pas placer de redirections automatiques à partir des pages
• 8.1 Rendre accessibles les éléments programmables
• 9.1 Fournir des images avec zones cliquables côté client
• 9.2 Assurer l'indépendance d'accès aux interfaces spécifiques par les périphériques
• 9.3 Assurer l'indépendance d'accès aux gestionnaires d'évènements par les périphériques
• 9.4 Proposer un ordre logique de parcours au clavier
• 9.5 Proposer des raccourcis clavier
• 10.1 Signaler l'ouverture de nouvelles fenêtres
• 10.5 Séparer visuellement les liens adjacents de manière explicite
• 11.1 Privilégier les technologies du W3C
• 11.2 Ne pas utiliser de composants obsolètes ou dépréciés
• 11.3 Permettre aux utilisateurs de recevoir des documents conformes à leurs préférences
• 11.4 En dernier recours, fournir une version alternative accessible
• 12.1 Donner un titre à chaque cadre
• 12.2 Décrire l'objectif et les interactions entre les cadres
• 12.3 Regrouper les informations de même nature
• 12.4 Associer les champs de formulaire à leurs intitulés
• 13.2 Fournir des méta-données dans les pages
• 13.3 Fournir des informations sur l'architecture générale du site
• 13.4 Fournir des mécanismes de navigation cohérents
• 13.5 Proposer une barre ou un menu de navigation
• 13.6 Regrouper les liens par type de fonction
• 13.7 Faciliter l'usage du moteur de recherche
• 13.9 Faciliter la navigation sur des groupes de pages
• 13.10 Fournir un moyen de passer l'art graphique textuel
• 14.1 Utiliser un langage clair et simple

Profil communiquant

• 1.1 Fournir une alternative textuelle aux éléments non textuels
• 3.1 Remplacer les éléments non textuels par des styles CSS
• 3.5 Utiliser la hiérarchie de titres
• 6.1 Maintenir la lisibilité et la compréhension des contenus lorsque les styles sont désactivés
• 6.2 Mettre à jour les alternatives aux contenus dynamiques
• 6.3 Proposer une alternative au code javascript et aux éléments programmables
• 13.1 Identifier la destination des liens

Profil rédacteur et contributeur

• 1.1 Fournir une alternative textuelle aux éléments non textuels
• 1.3 Fournir une description audio des contenus multimédias
• 1.4 Synchroniser les équivalents des contenus multimédias
• 2.1 Ne pas utiliser uniquement la couleur pour donner accès à l'information
• 3.3 Privilégier l'utilisation des feuilles de styles par rapport au balisage pour la présentation
• 3.5 Utiliser la hiérarchie de titres
• 3.6 Utiliser les éléments de liste de manière appropriée
• 3.7 Baliser correctement les citations
• 4.1 Indiquer les changements de langue
• 4.2 Spécifier la forme complète des abréviations et acronymes
• 5.1 Baliser les en-têtes de lignes et de colonnes
• 5.2 Associer les cellules de données aux en-têtes de lignes et de colonnes
• 5.3 Utiliser des tableaux pour la mise en page que si leur linéarisation est correcte
• 5.4 Ne pas utiliser d'éléments de tableaux de données pour des tableaux de mise en page
• 5.5 Donner des informations complémentaires sur les tableaux de données
• 5.6 Proposer des valeurs de remplacement pour les en-têtes de tableaux de données
• 6.3 Proposer une alternative au code javascript et aux éléments programmables
• 10.1 Signaler l'ouverture de nouvelles fenêtres
• 11.3 Permettre aux utilisateurs de recevoir des documents conformes à leurs préférences
• 13.1 Identifier la destination des liens
• 13.8 Rédiger les contenus de façon simple, logique et ordonnée
• 14.1 Utiliser un langage clair et simple
• 14.2 Proposer des illustrations visuelles ou sonores

Ces listes seront prochainement affinées en tenant des thématiques de contenus. Vos commentaires seront naturellement les bienvenus sur ces profils et la pertinence des entrées ainsi offertes.

Un aspect des tests d'accessibilité du Référentiel Général d'Accessibilité pour les Administrations (RGAA) qui peut parfois paraître déroutant au premier abord est leur caractère unitaire. Il peut donc être utile d'apporter ici quelques précisions rapides à ce sujet.

Prenons l'exemple des tests portant sur la présence et la pertinence de l'alternative textuelle des images HTML. Un premier test (RGAA 1.1.1) vérifie, en toute rigueur, la simple présence de l'attribut alt des éléments img :

1. Si l'un des éléments mentionnés dans le champ d'application est présent dans la page, poursuivre le test, sinon le test est validé.
2. Si l'élément possède un attribut alt, le test est validé, sinon le test invalidé.

Comme tous les tests du RGAA, celui-ci est décomposé en étapes logiques pour permettre un traitement point par point :

1. L'étape 1 permet de valider immédiatement une page ne comportant aucun élément img (ni aucun autre élément du champ d'application de ce test).
2. L'étape 2 permet d'invalider immédiatement une page comportant au moins un élément img (ou autre élément du champ d'application) dénué d'attribut alt.

Un second test (RGAA 1.1.2) s'attache ensuite uniquement aux images dites "décoratives", c'est à dire qui n'apportent pas d'information nécessaire à la compréhension ou à l'utilisation de la page. Ces images doivent recevoir une alternative textuelle vide :

1. Si l'un des éléments mentionnés dans le champ d'application est présent dans la page, poursuivre le test, sinon le test est validé.
2. Si l'élément possède un attribut alt vide, poursuivre le test, sinon le test est validé.
3. Si l'élément est uniquement décoratif, le test est validé, sinon le test est invalidé.

Le test procède à nouveau point par point :

1. L'étape 1 permet à nouveau de valider immédiatement une page ne comportant aucun élément img (ni aucun autre élément du champ d'application de ce test).
2. L'étape 2 "sélectionne" les éléments dotés d'une alternative vide.
3. L'étape 3 permet de valider une page où chaque alternative vide correspond effectivement à un élément décoratif, et de l'invalider dans le cas contraire.

Cependant, la seconde étape de ce test peut aussi conduire à un résultat apparemment surprenant : si ma page comporte une image dénuée d'alternative textuelle, ce qui est un défaut rédhibitoire, elle sera considérée ici comme valide.

Naturellement, il ne s'agit pas, à ce stade précis, de validité du point de vue de l'accessibilité. Mais simplement du mécanisme des tests unitaires :

• La validation d'accessibilité pour la présence des alternatives textuelles alt est traitée par le test 1.1.1, et par lui seul.
• Dès lors, aucun autre test ne doit faire "remonter" un résultat invalidant la page pour le même motif : lorsque j'examine dans le test 1.1.2 la pertinence des alternatives vides, je ne prends donc plus en compte les erreurs d'accessibilité dues à des absences d'attributs alt.

Le terme "valide" est donc à prendre, dans ces tests, en gardant à l'esprit ce mécanisme :

• La ou les étapes initiales d'un test concernent son applicabilité, et "valide" ne signifie pas nécessairement "valide pour l'accessibilité". Un test non applicable sera dit valide à ce stade.
• La ou les étapes finales d'un test concernent son accessibilité, et "valide" y est le résultat d'accessibilité.

L'intérêt majeur de cette démarche est d'obtenir, au terme des tests, un résultat parfaitement significatif, où chaque item dit "invalidé" correspondra effectivement à un type d'erreur unique, donnant ainsi une image chiffrée exacte des problèmes rencontrés.

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 ;)

Si vous me permettez de reprendre l'expression consacrée: P... Deux jours... ;)

Même si tous les participants l'ont déjà dit et redit, redisons-le en effet: ce fut magistralement organisé et mené de main de maître par Éric Daspet, Stéphane Deschamps, Adrien Leygues, Olivier Gendrin et leur entourage. Rigueur, efficacité, gentillesse et souci du moindre détail... je n'ose imaginer ce qu'ils nous concocteront pour Paris Web 2007 !

Si je n'y ai fait, hélas, qu'un passage beaucoup trop court à mon goût, n'ayant pu être présent que le jeudi, il fut tout de même l'occasion de rencontres passionnantes, et peut-être bien de quelques nouveaux projets...

Mon seul autre regret est de n'avoir pu développer comme je l'aurais aimé certains enjeux évoqués dans ma conférence de présentation de l'accessibilité Web, touchant aux stratégies d'accessibilisation des CMS, ayant sous-estimé ma tendance naturelle à prendre mon temps lorsqu'on me donne la parole sur ces sujets. Mais je pense que nous en reparlerons très bientôt ;)

Pour qui souhaiterait consulter les slides de cette présentation : la voici en téléchargement (ZIP - PPT - 3Mo - ouch !).

• Une série d'interviews en 5 parties réalisée par Tristan Nitot, Aurélien Levy et Harmen Christophe auprès de Buisness Interactif, Cosmic Communication, B&DI Eolas et Sqli sur le thème Agences et Standards Web :
  1. Présentation des interviewés ;
  2. Migrer vers les standards ;
  3. Utiliser les standards ;
  4. Communiquer sur les standards ;
  5. L'avenir des standards.
• Un article à la fois iconoclaste et mesuré d'Elie Sloïm, Conformité, validation et surqualité, dont je savoure personnellement cet extrait, à méditer longuement :

  La conformité absolue implique une obligation de moyens, alors que la qualité Web suppose une obligation de résultats.

  Vos utilisateurs n'ont pas besoin d'un site conforme, mais ils demandent que celui-ci s'affiche et fonctionne correctement. Cet objectif peut être atteint entre autre grâce à la conformité, mais pas seulement. L'existence de navigateurs non standards fait que même la conformité absolue d'un site ne suffit pas à garantir le bon affichage.

  La conformité absolue est-elle une priorité au regard des tests multi-navigateurs, du respect des règles d'accessibilité ? du WAI, de l'ergonomie de l'interface, de la capacité de vos utilisateurs à trouver rapidement votre site ou à se faire livrer leurs produits en temps voulu ? La réponse tient dans votre capacité à équilibrer les ressources que vous mobilisez.

  La mise en conformité absolue ne sera pertinente que si elle s'intègre dans une démarche globale d'amélioration de la qualité Web. Si les ressources mobilisées le sont au détriment d'autres aspects essentiels comme l'accessibilité, l'expérience utilisateur, la visibilité du site, la production et la qualité des contenus et services, c'est une démarche incomplète, voire à risques.

J'en viens maintenant au truc qui me fait bondir : la page des fonctionnalités. Pour lire le détails de chaque fonctionnalité, il faut faire un drag and drop d'une image vers une zone d'affichage. Non seulement je ne vois aucun interêt à présenter la chose de cette façon, mais en plus, c'est en matière d'utilisabilité plutôt léger :

• le drag and drop, c'est contraignant à faire, surtout quand c'est juste pour lire un bout de texte. Déjà que certains ont du mal à cliquer (par manque d'experience ou par problèmes aux doigts etc...), alors faire du drag and drop...
• ceux qui zooment le contenu de la page web pour cause de déficience visuel, ne peuvent lire qu'une partie du texte, celui-ci passant sous les images (Avec un style overflow, ça devrait toutefois se résoudre..).

En fait, cet exemple est très révélateur des problèmes de démarches de conception intégrant à la fois l'accessibilité et ces interfaces enrichis depuis peu à la mode.

Quels sont les problèmes rencontrées sur cette page, en l'état ?

• Cet usage du drag and drop crée un nouveau mode de navigation, jusqu'ici peu usité. Il peut dérouter et il nécessite actuellement, en l'absence de signalétique communément admise, de fournir carrément le mode d'emploi de l'interface : To find out more about each feature, drag the screenshot to the 'information well' below: ;
• Il est effectivement obstructif et pose d'évidents et nombreux problèmes d'accessibilité, de gravité variable, que ce soit au clavier ou avec des dispositifs de pointage spécifiques, sans support javascript et/ou CSS, dans une loupe ou un lecteur d'écran, via un terminal braille, un navigateur texte, un ancien navogateur graphique, un navigateur graphique récent mais à l'implémentation javascript imprévue par l'auteur, depuis un mobile, etc.
• Il agace Laurent Jouanneau, qui aimerait bien pouvoir consulter cette page sans devoir en passer par là ;

Mais... A quoi a-t-on affaire, en réalité ? Il me semble qu'il s'agit plus d'une question de démarche de conception que d'abus de fonctionnalité gadget et inutile. En effet :

• La page a été conçue en vue d'un media unique (screen) et de conditions de rendu très spécifiques ;
• l'interface est prioritaire sur le contenu, sa réutilisabilité, son interopérabilité et son accessibilité ;
• l'accessibilité sera inévitablement abordée a posteriori en termes d'améliorations et d'accumulation de patchs plus ou moins disparates et dispendieux.

Reprenons la page par le bon bout, à présent, c'est à dire le contenu. L'auteur pouvait :

• concevoir un ensemble de pages (ou une page unique) fonctionnel et accessible sur la seule base du standard HTML (ce qui nécessitait par exemple des liens cliquables vers les différentes pages détaillant les fonctionnalités) ;
• concevoir un interface (via CSS) "traditionnel" sur cette base ;
• y intégrer son drag and drop en tant que mode de consultation complémentaire.

Comme l'écrivait récemment Molly Holzschlag , reprenant les propos de Jeremy Keith :

When it comes to Ajax and related approaches, Jeremy has an interesting philosophy. He’s focused on the small stuff, the little enhancements that mean a lot. Elegance, intelligence and a light hand in everything we do is the gospel Jeremy preaches, and it’s more than sensible. It allows developers and designers to implement the cool stuff but do so without sacrificing all of the benefits related to Web standards and accessibility.

Dans ce cas, pas de patch, pas de situations d'utilisateurs imprévus à gérer, et la possibilité pour chacun de s'essayer à ce mode de consultation inhabituel mais intéressant.

Il s'agit par exemple :

• De remplacements de contenu (textuel) par des images, jouant sur les background CSS, surtout dans le cas des menus de navigation,
• D'effets de contenu HTML masqués, apparaissant uniquement par des effets de survol d'une autre partie de la page,
• D'interfaces screen paginés, conçus pour n'occuper que les dimensions de la zone d'affichage sans possibilité de scroll,

Dans le pire des cas, on trouvera derrière ces design :

• Des listes de liens de navigation vides, sans aucun intitulé textuel (hormis éventuellement un attribut title à la restitution incertaine), où seule une image d'arrière-plan CSS et un jeu de dimensions appliquées au lien vont créer quelque-chose de cliquable... si tout est affiché et consulté comme prévu, c'est à dire dans quelques navigateurs graphiques et dans des conditions d'accès similaires à celles connues de l'auteur.
• Des images de contenu, qui sont l'information centrale de la page, repoussées en background CSS, dépourvues de toute alternatives textuelle ou contextuelle, et de toute existence sans CSS, uniquement pour réaliser un effet au survol à l'ergonomie incertaine,
• Bref, l'exact inverse d'une séparation du contenu et de la présentation : la confusion complète de ceux-ci, le véritable contenu n'étant plus dans le document HTML mais dans la feuille de style.

L'inaccessibilité de ces pages-là est évidente. Les liens vides, pour ne retenir qu'eux, seront inexistants dans de nombreuses configurations de lecteurs d'écran, de navigateurs textes, de navigateurs sur mobile et PDA, et mêmes de navigateurs graphiques (désactivation des arrières-plans et des couleurs, résolution réduite, loupe d'écran ou simple besoin d'agrandir la taille du texte...), etc.

Mais parfois, on rencontre de ces réalisations combinant une structure HTML où le contenu est bien là (de bonnes vieilles images img alt="...", par exemple), où la structure est en elle-même accessible, correctement restitué et utilisable car jusque-là conforme aux standards d'accessibilité.

Seule la couche CSS (renforcée éventuellement de javascript) est problématique. Telle que la page s'affiche dans un navigateur graphique, ou lorsque certaines propriétés CSS visuelles interviendront dans la restitution par un lecteur d'écran, différents utilisateurs rencontreront :

• des contenus non restitués,
• des difficultés liées à des rognages, ou à une dégradation du rendu provoquées par un scroll que l'auteur a voulu éviter à tous prix, et dont il n'a, du coup, pas anticipé ni géré les effets,
• des difficultés liées au passage obligé par le survol pour faire apparaître le contenu : signalétique souvent obscure, comportements déroutants sous la souris, obligation d'élucider cet interface, nécessité de se servir de la souris avec précision...
• des difficultés liées à l'obligation d'activer la totalité des effets de style pour avoir un rendu cohérent, utilisable ou compréhensible : couleurs, arrière-plan, positionnements et dimensionnements... peuvent pourtant être individuellement compromis par une configuration spécifique répondant aux besoins de l'utilisateurs.

Alors, bien-sûr, devant ces pages-là, il reste la possibilité ultime offerte par CSS : désactiver le tout, ne consulter que le HTML brut (sous réserve des effets d'un javascript certes "DOMisé", mais qui rappelle franchement les excès du DHTML d'antan). Ce n'est pas très beau, c'est parfois un peu touchant quand on voit que l'auteur a poussé le souci de bien faire jusqu'à sémantiser à l'excès, par exemple à coup de listes ul dès que quelque-chose ressemble vaguement à une série d'items. Mais c'est compréhensible, navigable et surtout adaptable à mes contraintes d'utilisateurs.

La grande qualité de CSS, c'est indéniablement de séparer contenu et effets de présentation, et de préserver l'accessibilité en offrant au moins cette ultime solution de repli. Mais est-ce à dire que ces pages sont vraiment accessibles ? Tiens, une question parmi d'autres : combien d'utilisateurs peuvent-ils désactiver CSS à la volée dans leur navigateur ?

Et puis, finalement : ces mises en page poussant l'usage de CSS à ses limites, multipliant les effets de survol, d'interaction à tous prix... mettent-elles réellement en valeur le contenu ? Ce dernier, qui est pourtant l'essentiel d'une page Web, serait-il décidément toujours menacé d'effacement derrière le clinquant du media ? ;)

L'idée de s'adresser aux nombreux acteurs du "phénomène blog" pour inviter à découvrir la démarche d'accessibilité est excellente. Voici les conditions fixées par le règlement du concours :

Voici les critères que les blogs devront respecter pour pouvoir être classés [...] :

• être un blog,
• être un blog accessible (niveau AccessiWeb bronze, Argent ou Or),
• être un blog créatif,
• comporter un minimum de 3 pages HTML distinctes,
• être consultable en ligne sur Internet.

[...]

Blog créatif : c'est un blog qui est graphiquement et ergonomiquement « bien conçu » (l'expression « bien conçu » peut vouloir dire : beau, innovant, intelligent, ...). Cette notion est introduite dans le concours pour éviter les blogs réduits à leur plus simple apparence (du texte par exemple sans mise en page).

Voilà une occasion pour les auteurs et pour les utilisateurs de DotClear et autres Wordpress, de « kits graphiques » ou de « templates », d'aller creuser sous la surface du design et dans les entrailles de leur CMS. Le blog a d'ailleurs quelques points particulièrement sensibles du point de vue de l'accessibilité, et notament (liste non exhaustive) :

• L'inflation des liens de navigation (chronologiques, thématiques...) et des liens en contenu annexe (listes de blogs visités, blogmarks...),
• La fréquente présence de liens aux intitulés non explicites (Lire la suite... lien permanent... commentaires) dans les pages d'accueil et de listes de billets, voir dans les billets eux-mêmes (j'ai lu ici que...
• De même, les titres très souvent non explicites (jouant sur les effets de connivence avec le lecteur)
• Les contenus multimédias (podcast, photoblogs...)
• La gestion de contenu produit par d'autres rédacteurs (les commentaires)
• Le vocabulaire implicite du blog ("trackbacks", "tags", "permalink"...)
• La gestion du format de date et de ses ambiguïtés (confusion possible du mois, du jour...)

Et puisque le concours met aussi l'accent sur la qualité et l'ergonomie des blogs, je ne peux évidemment manquer de suggérer aux éventuels participants un outil complémentaire aux Critères AccessiWeb pour gérer ces aspects de leur réalisation... Vous l'avez deviné, il s'agit bien-sûr de Mon-opquast, qui est tout à fait adapté à une démarche de suivi qualité personnelle d'un weblog, comme le rappelait Elie dans ses scénarios d'usage: ;)

Bloggueur :

Guillaume publie régulièrement ses pensées et recommandations de liens sur un blog personnel.
Soucieux de la qualité de celui-ci, il s'inscrit à Mon-Opquast Perso et effectue une évaluation de son site en fonction des bonnes pratiques Opquast.
C'est également l'occasion pour lui de se former aux différents aspects techniques et ergonomiques de la qualité d'un site Web.
Il en profite pour communiquer sur sa démarche en affichant un logo de soutien au projet sur son blog. Ce logo pointe vers une déclaration qualité publique. Même si cette déclaration montre que tout n'est pas encore parfait, ce bloggueur communique sur sa démarche et dit de manière claire à ses utilisateurs : la qualité de mon blog est importante pour vous et pour moi.

Abonnement recommandé : Mon-Opquast Perso (gratuit)

Bonne chance à tous les participants !

Mais il y a manifestement plus à en dire. Manquant de temps, je liste rapidement quelques points en vrac qui me semblent importants:

• Un rappel: mon avis n'exprime... que mon avis. Il est sans relation avec la fondation Mozilla, Mozilla Europe, Tristan Nitot, FemFox, SpreadFirefox, une confrérie de geeks, un complot masculin ou tout autre site, organisme, entreprise.
• Cette collection d'images, à la réflexion, se prête manifestement à de multiples lectures. La mienne est sous l'angle de l'humour et de l'absurde, mais pour d'autres, ce sera entre-autres l'érotisme, le machisme, l'esthétique, la vulgarité, la banalité, la provocation, etc. Chacune de ces lectures est pertinente : le ressort de cette publicité, ce sont nos représentations personnelles des sexes et de leurs stéréotypes, dans toute leur diversité (elles sont loin d'être binaires). Il ne s'agit plus d'un message univoque (comme l'était le traditionnel argumentaire sécuritaire, par exemple), et à ce titre, je doute qu'il puisse être assumé en dehors d'une initiative privée.
• Vue de plus près, cette série d'images est très loin de former un ensemble homogène et là encore, univoque. Ses auteurs disent clairement que leur démarche a évolué depuis la première image, et qu'elle continuera à évoluer. Qu'elle comporte une part de tâtonnements. Toutes ces images n'ont pas le sens, les mêmes qualités, les mêmes défauts. Je crois que, tous, nous ne les retenons pas dans le même ordre, avec le même poids, et que nos jugements sont souvent le reflet d'un tri, où une ou deux images sont déterminantes. Il faudrait prendre le temps de les parcourir, de distinguer nos réactions à chacune.

A titre d'exemple:

• les deux premières images dans l'ordre chronologique (les contributions d'origine pour SpreadFirefox.com) me semblent franchement médiocres : l'image est crue, aujourd'hui banale ; l'érotisme est plaqué au premier degré sur le thème, il est racoleur.
• les épisodes 1, 2, 3 et 4... sont des caricatures. Elles jouent sur des images qui me rappellent quelque-chose, d'autres publicités dont j'ai un vague souvenir, de ces pubs de lingerie hélas banales où, en effet, le corps féminin instrumentalisé, plastifié, neutralisé, finit par ne plus susciter que mon indifférence ou mon rejet devant son exploitation systématique. Mais là où je juge la caricature réussie et intrigante, c'est qu'elle ne s'applique pas tant au corps lui-même, qu'à cet abus publicitaire qui en est fait. Qu'en juxtapose lingerie et logiciel, qu'on se moque du fantasme préfabriqué, de ces publicités Aubade, tout cela me fait volontier sourire.
• l'épisode 5... le registre est nettement différent, toujours absurde, mais très (trop ?) direct. Oui, c'est drôle mais cette image à elle-seule n'aurait sans doute pas suffit à m'intéresser outre-mesure.
• l'épisode 6 est beaucoup plus réussi, peut-être le plus réussi, et le plus risqué aussi. L'humour y est grinçant. Outre la caricature publicitaire, je le perçois comme une allusion cinématographique. Sans songer à un film précis, ce cliché de la violation d'intimité, de l'irruption agressive, d'une vulnérabilité explicitement posée, construite pour la scène, calculée jusque dans le blanc clinique du lit et le rouge cru du texte... m'effraye finalement peut-être autant qu'il m'intrigue. Mais tout en s'approchant d'une certaine complaisance provocante, il ne me semble pas y céder.

Tout cela en dit autant sur moi-même, sinon plus, que sur ces images (diable, voilà qui n'est pas dans mes habitudes ;) )