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.

  1. Les coulisses du RGAA 3.0
  2. 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

  • 133 critères
  • 327 tests

RGAA 3.0

Juin 2014

Consultation Groupe de travail DISIC

Validation de AW HTML5/ARIA

  • 133 critères
  • 327 tests

RGAA 3.0

Juillet 2014

Appel à commentaires GTA

Validation + relecture

  • 133 critères
  • 331 tests

RGAA 3.0

Septembre 2014

Appel à commentaires

327 modifications

  • 133 critères
  • 349 tests
  • 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

  1. Constitution d'un noyau dur, formé et issu de l'administration : échanges directs et via un forum ;
  2. Consultation du GTA sur un forum éphémère ;
  3. Appel à commentaires publics.

Des outils divers au service du recueil des commentaires

Redmine pour le noyau dur

Wiki et forum

Forum pour le GTA

forum de discussion et sondage

Drupal et le module Webform pour l'appel à commentaires

gestion des commentaires reçu dans Drupal

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

Label e-accessible RGAA

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

  • Sans commentaire...

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 :

  1. Impact utilisateur
  2. Accès technique à l'information
  3. Caractère raisonnable de l'aménagement préconisé

Résolution de conflits : 2 cas

  1. Quand l'impact utilisateur n'est pas contesté
  2. 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 ?