Zoom sur le RGAA et ce qu'il y a autour
Par Armony Altinier et Jean-Pierre Villain
RGAA 3.0 : besoin de vous !
Chronologie
- 31 octobre 2013 : publication d'un appel d'offres
- 10 décembre 2013 : clôture de l'appel d'offres
- 24 avril 2014 : première réunion du groupement au SGMAP
D'un travail associatif à un marché porté par un groupement
- Mode de fonctionnement différent ;
- Peu de communication ;
- Frustration légitime des acteurs ayant porté AccessiWeb et se trouvant écartés du processus.
Objectif de notre présentation : partager
L'accessibilité ne progressera pas sans vous. Notre travail n'est qu'un point de départ.
- Les coulisses du RGAA 3.0
- Zoom sur le label en mode FailCon
Nouveautés de RGAA 3.0
et écarts avec AccessiWeb HTML5/ARIA
Vous connaissez AccessiWeb HTML5/ARIA, vous connaissez RGAA 3.0
AccessiWeb HTML5/ARIA
Décembre 2013
Version initiale
Transposition AW 2.2
RGAA 3.0
Juin 2014
Consultation Groupe de travail DISIC
Validation de AW HTML5/ARIA
RGAA 3.0
Juillet 2014
Appel à commentaires GTA
Validation + relecture
RGAA 3.0
Septembre 2014
Appel à commentaires
327 modifications
-
L'essentiel des modifications consiste en des améliorations d'intitulés, de tests, de définitions de glossaire (75% des modifications de l'appel à commentaire public) et une mise à jour importante du mappage des techniques WCAG (environ 80 technique ajoutées).
-
Les experts EAE AW HTML5/ARIA sont immédiatement opérationnels sur RGAA 3.0
Exemples d'amélioration
Avant
Critère 1.8 [AA] Chaque image texte, en l'absence d'un mécanisme de remplacement, doit si possible être remplacée par du texte stylé. Cette règle est-elle respectée (hors cas particuliers) ?
Après
Critère 1.8 [AA] Chaque image texte porteuse d'information, en l'absence d'un mécanisme de remplacement, doit si possible être remplacée par du texte stylé. Cette règle est-elle respectée (hors cas particuliers) ?
Exemples d'amélioration
Avant
Critère 4.21 [A] La consultation de chaque média non temporel est-elle contrôlable par le clavier et la souris ?
- Test 4.21.1 : Pour chaque média non temporel, chaque fonctionnalité est-elle accessible par le clavier et la souris ?
- Test 4.21.2 : Pour chaque média non temporel, chaque fonctionnalité est-elle activable par le clavier et la souris ?
Après
Critère 4.21 [A] La consultation de chaque média non temporel est-elle contrôlable par le clavier et la souris ?
- Test 4.21.1 : Pour chaque média non temporel, chaque fonctionnalité vérifie-t-elle une de ces conditions :
- La fonctionnalité est accessible par le clavier et la souris
- Une fonctionnalité accessible par le clavier et la souris permettant de réaliser la même action est présente dans la page
- Test 4.21.2 : Pour chaque média non temporel, chaque fonctionnalité vérifie-t-elle une de ces conditions :
- La fonctionnalité est accessible par le clavier et la souris
- Une fonctionnalité accessible par le clavier et la souris permettant de réaliser la même action est présente dans la page
Exemples d'amélioration
Test 7.1.3 :Chaque script qui génère, met à jour ou contrôle un composant d'interface qui comporte des rôles des états ou des propriétés correspondant à un motif de conception défini par l'API ARIA vérifie-t-il une de ces conditions ?
- Le composant d'interface est conforme au motif de conception défini par l'API ARIA
- Un composant d'interface présent sur la page, permettant d'accéder aux mêmes fonctionnalités, est conforme au motif de conception défini par l'API ARIA
- Le composant d'interface adapte un motif de conception défini par l'API ARIA.
- Une alternative accessible permet d'accéder aux mêmes fonctionnalités.
Adapter un motif de conception ARIA
L'API ARIA définit des motifs de conception, par exemple pour un système d'onglet ou une fenêtre modale, destinés à assurer un comportement homogène de référence des composants d'interface. Le respect de ces motifs de conception est exigé par le référentiel RGAA.
Néanmoins il est possible d'adapter ces motifs de conception en remplaçant une propriété mal supportée par une propriété équivalente ou en enrichissant le composant de propriétés améliorant l'expérience utilisateur ou sécurisant son comportement.
Il appartient à l'auditeur de vérifier que ces adaptations sont cohérentes avec le motif de conception, ne modifient pas le comportement, en termes d'expérience utilisateur, du composant et que le composant adapté est correctement restitué par les technologies d'assistance.
Si ces exigences sont respectées, le composant peut-être déclaré "conforme" au motif de conception.
Changements importants
Images en propriété de fond CSS + texte caché
- Non-Conforme avec AW HTML5/ARIA
- Conforme avec RGAA 3
Obligation de rendre les liens d'accès rapide visibles à la prise de focus au moins
- AW HTML5/ARIA tolérait que ces liens demeurent correctement masqués
- RGAA 3, exige que ces liens apparaissent à la prise de focus au moins
Suppression du test sur les surcharges de rôles ARIA
- AW HTML5/ARIA que les surcharges de rôle soient respectées, par exemple
<article role="article">
- RGAA 3, supprime cette exigence (indiquée en avertissement dans le glossaire)
Prise en charge des images maps coté serveur
- AW HTML5/ARIA avait supprimé la prise en charge des images maps coté serveur.
- RGAA 3, les réintroduits via un test du critère 1.3
Changements importants : mise à jour du mappage des techniques WCAG
Contexte
Le cadre légal créé des contraintes nouvelles quant au support de WCAG par RGAA 3.0. Même si la prise en charge de WCAG par RGAA 3.0 est établi au niveau des critères de succès, trois questions, remontées au DISIC, concernait :
- Le fait de savoir si une technique, non présente dans les références des critères, était supportée ou pas
- Le besoin de détailler le fait qu'un contenu conforme WCAG pouvait être non-conforme RGAA 3.0 comme indiqué dans le document d'accompagnement.
- Le fait de pouvoir vérifier qu'aucune exigence de RGAA 3.0 ferait appel à des exigences absentes de WCAG.
Mise à jour du mappage des techniques WCAG
Nous avons procédé à une mise à jour complète du mappage des techniques WCAG pour les technique G (Générales), H (HTML), C (CSS), SMIL (SMILE) et ARIA (WAI-ARIA).
Résultats de l'opération de mappage
273 techniques ont été vérifiées, 66 ont été ajoutées.
Ecarts WCAG vers RGAA 3
Les écarts entre WCAG et RGAA 3 concernent :
G142 (zoom graphique), G167 (utilisation d'un bouton adjacent pour labelliser un champ de formulaire), G178 (utilisation de bouton d'agrandissement des tailles de caractères)H53 (alternative dans une balise object)C7 (utilisation de texte caché pour rendre un lien explicite).
Dans chacun de ces cas, un contenu WCAG est suceptible de ne pas être conforme RGAA 3.0.
Ecarts RGAA 3 vers WCAG
Il n'a été trouvé aucune exigence présente dans RGAA 3.0 qui ne pourrait pas être liée à une technique WCAG au moins.
Coulisses de fabrication du RGAA 3.0 :
méthodologies et travaux en cours
Une ouverture progressive
- Constitution d'un noyau dur, formé et issu de l'administration : échanges directs et via un forum ;
- Consultation du GTA sur un forum éphémère ;
- Appel à commentaires publics.
Des outils divers au service du recueil des commentaires
Redmine pour le noyau dur
Forum pour le GTA
Drupal et le module Webform pour l'appel à commentaires
Côté pilotage
Un dépôt privé sur Github
- Toutes les modifications du référentiel AccessiWeb HTML5-ARIA tracées depuis le début...
- À chaque commentaire son issue (voire plusieurs) sur Github
Synthèses et arbitrages par la DISIC en l'absence de consensus
- Synthèses à l'issue des consultations restreintes ;
- Tableur de suivi des commentaires.
Résultats
- 170 commentaires
- 245 issues créées, dont 227 closes
Et après ?
Des ressources
- Des référentiels supports : tester les composants, tester le mobile, tester la bureautique
- Une base de composants accessibles parmi les bibliothèques les plus utilisées
- Des tutoriels pour corriger l'accessibilité de composants Javascript
- Des modèles de documents : déclaration de conformité, page d'aide, grilles de test, cahier des charges...
- Profilage des critères selon les tâches dans un projet web
Le développement de la formation
- Cadrage stratégique et constitution d'un groupe de travail : infuser une culture de l'accessibilité auprès des professionnels
- Programme de formation selon les types de métier et supports génériques
- Formation de formateurs
Objectif : diffuser l'appropriation du RGAA 3.0 et développer une culture de l'accessibilité numérique.
Test de la procédure de labellisation RGAA 3.0
Objectif: réaliser un audit pilote pour la labellisation RGAA 3.0
Points importants testés
Le cahier des charges de la procédure de labellisation
Les documents de travail fourni à l'inspecteur et au candidat.
Les différentes phases testées:
- La réunion d'initialisation
- La visite initiale
- La réunion de restitution de la visite initiale
- La gestion des contestations du demandeur par l'inspecteur
Le site choisi pour l'audit pilote
Conseil Général du Pas de Calais.
Ce qui se fait de mieux
- 10 ans de travail : conforme RGAA 2.2, labellisé AccessiWeb
- Accompagné par Temesis
- Respondable accessibilité : Bertrand Binois
Phase 1 et 2 : réunion d'initialisation et visite initiale
Mise en place et réunion d'initialisation
- Procédure claire et compréhensible
- Mise en place de l'échantillonnage OK
- Sentiment du demandeur : OK
- Sentiment de l'inspecteur : OK
Visite initiale
- Quelques petits soucis d'ajustements (tests AAA), interprétation des critères
- Mission : remplie, timing tenu
- Sentiment de l'inspecteur : R.A.S, la routine
La restitution...
Houston ?... nous avons un problème...
Attention : certaines images peuvent choquer.
Phase 3 : réunion de restitution
Point de vue du demandeur
- Grille de relevé totalement inadaptée
- Des NC jamais relevées ou contradictoires et impossibles à prendre en charge dans les délais
- Sentiment du demandeur : je ne vois pas comment poursuivre.
Point de vue de l'inspecteur
- Manque d'indications claires des objectifs
- Manque d'outils pour encadrer les contestations
- Sentiment de l'inspecteur : je me suis senti totalement démuni
Phase 3 : réunion de restitution
Point de vue de l'observateur
Le jour d'après...
- Débriefing et analyse des problèmes
- Mise en place de solutions immédiates nécessaire à la reprise du processus
L'art de l'audit
Trois paramètres :
- Impact utilisateur
- Accès technique à l'information
- Caractère raisonnable de l'aménagement préconisé
Résolution de conflits : 2 cas
- Quand l'impact utilisateur n'est pas contesté
- Quand l'impact utiliateur est contesté
Question sous-jacente : dans quels cas peut-on déroger ?
Appréciation humaine ne signifie pas arbitraire. Besoin d'encadrer le processus de décision dans les cas d'évaluation de la pertinence.
Un audit se doit d'être objectif et indépendant. Les critères techniques indiscutables ne peuvent pas être dérogés.
Déroger signifie sortir le contenu de la règle prévue : le contenu n'est plus applicable selon la procédure d'audit normale. Le contenu devient non applicable (mais le critère reste éventuellement applicable à d'autres contenus !).
Dans tous les cas, droit à la compensation !
Obligation d'aménagement raisonnable
Article 2 de la Convention des Nations Unies relatives aux droits des personnes handicapées :
On entend par « aménagement raisonnable » les modifications et ajustements nécessaires et appropriés n’imposant pas de charge disproportionnée ou indue apportés, en fonction des besoins dans une situation donnée, pour assurer aux personnes handicapées la jouissance ou l’exercice, sur la base de l’égalité avec les autres, de tous les droits de l’homme et de toutes les libertés fondamentales.
Refus d'aménagement raisonnable = discrimination.
Cas n°1 : quand inspecteur et demandeur s'entendent sur l'impact utilisateur
Au départ, une non conformté (NC) qui fait débat pendant la réunion de restitution.
L'impact utilisateur est démontré et non contesté
| Cas n° |
La NC entraîne un impact négatif sur l'utilisateur ? |
La correction de cette NC est-elle raisonnable ? |
Quel est le statut de cette NC après traitement ? |
Dérogation ? |
| 1.1 |
Oui |
Oui |
NC |
Non |
| 1.2 |
Oui |
Non |
NA |
Oui |
Exemple : une hiérarchie de titre prêtant à confusion
Dans la recherche, le nombre de résultats est un titre 2, puis il y a la possiblité d'exlure des termes de cette recherche. Le titre "Exclure de la recherche" est également un titre 2 et n'apparaît que lorsque nécessaire. Puis en-dessous, il y a la liste des résultats, chacun commençant par un titre 3.
Difficulté : les audits successifs demandent de changer ce niveau de titre. Que faire ?
Cas n°2 : quand l'impact utilisateur ne fait pas consensus, retour à l'accès technique à l'information
Ici, la non conformté (NC) entraîne un débat houleux dont il est difficile de sortir.
L'impact utilisateur est contesté
| Cas n° |
Est-il possible d'accéder à l'information ? |
La correction de cette NC est-elle raisonnable ? |
Quel est le statut de cette NC après traitement ? |
Dérogation ? |
| 2.1 |
Oui |
Oui |
NC |
Non |
| 2.2 |
Oui |
Non |
NA |
Oui |
| 2.3 |
Non |
Oui |
NC |
Non |
| 2.4 |
Non |
Non |
NA |
Oui |
Exemple : une image dans un lien composite pouvant parfois être porteuse d'information
Chaque actu contient un lien avec une image et le titre de l'actu, le tout étant cliquable.
Il arrive que l'image contienne un texte qui n'est pas intégralement repris dans le titre, mais est repris dans le texte de l'article une fois qu'on clique dessus.
Ici : l'image contient la date de l'événement, information qui n'est pas reprise dans le titre : comment traitez-vous cette non conformité manifeste ?
Quel auditeur êtes-vous ?
Comment pratiquez-vous l'audit ? Quel rôle souhaitez-vous jouer ?
Objectif du label à terme : exister en dehors du cadre du marché et être délivré par tout organisme d'inspection accrédité.
S'inspirer de l'existant : l'IFACI
L'IFACI encadre la pratique de l'audit interne pour éviter les dérives, en s'appuyant sur des normes internationales.
Vers une charte de l'auditeur et un code de déontologie des professionnels de l'accessibilité numérique ?
Merci de votre attention
Des questions ?
