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.

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.

Lire la suite de Eclairage sur le RGAA: les profils d'impact opérationnel du Référentiel général d'Accessibilité pour les Administrations
(2 commentaires et trackbacks)

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.

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.

Lire la suite de Eclairage sur le RGAA: la logique des tests unitaires
(3 commentaires et trackbacks)

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

Lire la suite de Le Référentiel Général d'Accessibilité des Administrations (RGAA), quelques points saillants
(27 commentaires et trackbacks)

Ah... Tout comme l'ami Aurélien Levy avec lequel j'ai travaillé sur ce projet majeur concernant l'accessibilité Web, il va me falloir attendre lundi pour réveiller ce blog et vous en parler officiellement.

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

Lire la suite de Teasing: vivement lundi
(6 commentaires et trackbacks)

Ah... Il fallait bien Paris Web 2006 pour me faire sortir de ma retraite et revenir sur ce Blog & Blues souvent délaissé

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 !).

Lire la suite de Paris Web 2006
(12 commentaires et trackbacks)

Agacé par les abus d'Ajax et de DHTML, Laurent Jouanneau cite dans un récent billet l'exemple d'une page de description du CMS de blog logahead :

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.

Lire la suite de Ajax, DHTML et conception accessible: une question de démarche
(9 commentaires et trackbacks)

Le titre de ce billet est un raccourci volontaire : ce n'est pas une feuille de style qui peut ou non être "accessible", mais une page Web dont chaque couche HTML CSS javascript Flash AJAX etc. favorise ou limite l'accessibilité. Mais il s'agit ici de pointer un cas de figure bien particulier, que je rencontre de plus en plus souvent sur des forums de conception Web tels qu'Alsacréations : lorsque qu'une page Web est incontestablement accessible (au moins jusqu'à un certain point) parce que l'utilisateur a la possibilité d'en désactiver les effets de style réalisés à la limite de ce que peut ou devrait faire CSS.

Lire la suite de Quand CSS est accessible... une fois désactivé !
(11 commentaires et trackbacks)

L'association BrailleNet lance son concours des trophées AccessiWeb 2006 (ouvert uniquement aux étudiants) qui sera consacré aux blogs accessibles et créatifs.

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 :

Lire la suite de Lancement du concours des Trophées AccessiWeb 2006 : Blogs et Accessibilité
(7 commentaires et trackbacks)

Je rebondis sur ce témoignage de Tanguy Loheac (Chargé de projet accessibilité à l'association BrailleNet) signalé par Matthieu Faure :

Lire la suite de L'accessibilité Web n'est pas une somme de réponses spécifiques à des handicaps
(2 commentaires et trackbacks)

Lu chez Matthieu Faure, à propos de la technique décrite par Colin Lieberman dans The Accessibility Hat Trick: Getting Abbreviations Right, cette affirmation quelque-peu surprenante, qui mériterait de plus amples précisions :

Lire la suite de La tentation du hack pour l'accessibilité
(8 commentaires et trackbacks)

Pêle-mêle, à propos d'accessibilité, de validité et de wikiflow :

Lire la suite de Pêle-mêle de la semaine
(6 commentaires et trackbacks)

Quand un expert tel qu'Aaron Leventhal, le « monsieur Accessibilité » de la Fondation Mozilla, accorde un long interview au magazine italien Bazzmann, cela mérite qu'on s'y arrête. En voici donc l'essentiel :

Lire la suite de Aaron Leventhal, l'accessibilité en général et Firefox en particulier
(2 commentaires et trackbacks)

En passant par le Yahoo! Search Blog, qui annonce que je ne sais plus quelle barre d'outil bénéficie de l'auto-détection des fils RSS, une discussion d'il y a quelques mois me revient à l'esprit : on m'y faisait remarquer que les liens relatifs link rel="alternate" apparaissent en début de page dans des navigateurs textes comme Lynx.

Le rapport avec l'autodétection des fils RSS ? Simple, quand on y pense :

Lire la suite de Lien d'auto-découverte de vos fils RSS et navigateurs textes: pensez à des intitulés accessibles
(3 commentaires et trackbacks)

Il est d'usage, selon les recommandations d'accessibilité, d'éviter ce que l'on appelle les liens adjacents, c'est à dire deux éléments a qui se succèdent dans le code (X)HTML sans être séparés par au moins un caractère imprimable ou une image doté d'un attribut alt. En effet, dans diverses configurations de lecteurs d'écran, il sera difficile pour l'utilisateur de distinguer deux liens adjacents, faute d'un séparateur audible. Que ces liens soient éventuellement contenus dans des éléments parents distincts ne change rien au problème, la seule exception étant lorsque ces liens sont contenus dans des items de liste li.

Le souci louable de respecter cette règle d'accessibilité se double souvent de préoccupations esthétiques tout aussi louables : plutôt que la traditionnelle barre verticale |, de nombreux sites utilisent une combinaison de signes de ponctuation ou d'autres caractères plus ou moins exotiques. Quelques exemples, rencontrés au fil de mes lectures :

Lire la suite de Séparateurs de liens adjacents, fantaisie et sobriété
(11 commentaires et trackbacks)

Je ne suis pas handicapé visuel. Du moins, pas encore tout à fait. Mais il se trouve qu'après avoir bénéficé très longtemps d'une excellente vision, je suis amené de plus en plus souvent à utiliser des outils de navigation orale, du type lecteur d'écran, sans pouvoir à ce moment m'appuyer sur une vision même partielle de mon écran.

Passer ainsi d'une expérience visuelle à une expérience auditive du Web est, disons... instructif

C'est pourquoi je voudrais tenter, sans autre prétention que de faire état d'une expérience très personnelle, de décrire simplement les nouveaux besoins que je rencontre actuellement. Pour commencer, voici le premier problème que j'ai rencontré : me faire une idée de la topographie d'une page, et pouvoir l'utiliser dans le reste du site.

Lire la suite de Perception de la structure d'une page Web par un handicapé visuel, tentative d'explication
(12 commentaires et trackbacks)