Présentation de Denis Boulay (Braillenet) et Jean-Pierre Villain (Qelios) au séminaire GTA du 13/12/2012. Les technologies HTML5 et ARIA sont de plus en plus utilisées, et AccessiWeb est confronté à une demande croissante de labellisations pour des sites et applications basés sur ces technologies. Le référentiel AccessiWeb 2.2 n'est pas adapté, et doit être réinventé. Cette présentation fait le point sur les travaux en cours, menés par Accessiweb et Qelios. Elle décrit les challenges rencontrés, et donne un avant-goût du futur référentiel "AccessiWeb HTML/ARIA".

1. Mesure de la conformité WCAG 2.0
via le référentiel AccessiWeb 2.2
avec HTML5/ARIA
13 décembre 2012
17ème séminaire AccessiWeb

2. Intervenants
• Denis Boulay, Association BrailleNet,
denis.boulay@accessiweb.org
@accessiweb
• Jean-Pierre Villain, Qélios
jpvillain@yahoo.fr
@villainjp

3. Sommaire en 7 points
Rappels
1.Préambule
2.Introduction
3.Les principes
4.Base de références
5.Exemples – Préambule – Thématique Images
6.Le futur référentiel AccessiWeb HTML5 / ARIA

4. Introduction et rappels

5. Introduction et rappels
Rappel du contexte :
•Evolution des technologies
•Evolution des usages
•Nouvelles plateformes
•Utilisation grandissante du HTML 5 (présent dans les CMS)
Une des conséquences :
•Demandes de labellisations "HTML 5"
Dans les faits :
•Référentiel AccessiWeb actuel pas adapté pour de telles demandes

6. Introduction et rappels
Objectifs et besoins opérationnels :
•Besoin d’un nouveau référentiel
MAIS
•Difficile à mettre en œuvre dans un contexte d’implémentation progressive
par les AT/UA/OS
•Nécessité de mettre en place des procédures de tests supplémentaires

7. Introduction et rappels
Un plan en deux étapes :
1.Mise en place d’une procédure adaptée dans le cadre de la labellisation
Pourquoi ?
▫ Pour répondre à un besoin immédiat
▫ Pour tester - en situation – certains principes qui seront adoptés pour le
nouveau référentiel (voir par ailleurs)
1.Production progressive du nouveau référentiel (premier trimestre 2013)

8. Introduction et rappels
Comment fonctionne la méthode d’écriture des référentiels AW ?
•Rédaction du référentiel par un groupe restreint d’Experts
▫ Pilotage BrailleNet/Qélios dans le cas du référentiel AW version 2.0 à 2.2
▫ Appels à des Experts Référents pour avis précis (15 ER actifs)
▫ Validation finale et publication
•Les mises à jours fonctionnent sur ce modèle
▫ Recensement des retours issus de la liste GTA, des labellisations…
▫ Modifications apportées soumises aux ER
▫ Publication d’une nouvelle version + listes des changements

9. 1 Procédure adaptée pour la labellisation de site en HTML5
Préambule

10. Rappel HTML 5
Plus qu’une simple évolution, HTML 5 est une refondation du langage HTML
 Nouveaux éléments
• Formulaire, éléments sectionnants,
images…
 Nouveaux attributs
• Une centaine de nouveaux attributs
ou valeurs, par exemple 18
nouveaux attributs et 12 nouveaux
types uniquement pour l’élément
input.
 APIs :
• 2D/3D, Multimédia, Local Storage,
Edition, Drag an Drop…

11. Une procédure d’élaboration très compliquée entre le W3C et le WhatWG
Principaux problèmes
 La méthode
• Modulaire pour le W3C (plusieurs
modules de spécifications)
• Unitaire pour le WhatWG (Un
seul corps de spécifications
 Le versionnage
• Version (5.0, 5.1… Next) pour le
W3C
• Pas de version (Html Living
Standard) pour le WhatWG
 L’accessibilité
• Prise en charge d’ARIA, élément
<main>, rôle de title….

12. Pourquoi AW 2.2 n’est pas adapté pour HTML5/ARIA
Les différences de fond et les évolutions sont trop nombreuses pour porter AW 2.2
vers HTML 5
 HTML5 supprime ou modifie
des éléments
• Par exemple summary
pour les tableaux, longdesc
pour les images
• Outline pour le titrage…
 La notion d’alternative et de
compatibilité pour javascript
telle que définie par AW 2.2
n’est pas adaptée à HTML 5
 Prise en charge de l’API ARIA

13. 2 Procédure adaptée pour la labellisation de site en HTML5
Introduction

14. Cartographie de l’adaptation pour le labellisation HTML5/ARIA
Base de référence
6 principes AT/UA/OS
Destinés à assurer la transition entre Destinée à gérer la notion de
AW 2.2 et HTML5/ARIA « compatible avec l’accessibilité »
Liste des adaptations Base de connaissance
connues
Qualifier, autant que possible des
Adaptation des critères AW 2.2 widgets ARIA pour l’accessibilité
(critères, tests, conditions, cas
particuliers, notes techniques)

15. Procédure et état d’avancement à Novembre 2012
Approuvés
BrailleNet et le groupe
(sauf Navigation Clavier)
d’écriture proposent Principes
Base de En discussion
Le groupe d’Experts
référence
référents discutent et
approuvent
En préparation
Adaptations
Publication
Publications Objectif : Courant Janvier 2013

16. 3 Procédure adaptée pour la labellisation de site en HTML5
Les principes

17. 1 Recourir à des alternatives accessibles, si nécessaire
Si un élément HTML5/ARIA n’est pas compatible avec l’accessibilité, il faudra
implémenter un dispositif alternatif conforme AW 2.2
<vidéo > / <audio> <svg>
Compatible
Compatible
Non
Non
Compatible
<object> Présence d’une alternative texte
Conforme AW 2.2 ou <img>
Sauf exception répertoriée , les alternatives accessibles devront être disponibles sans
recourir à une manipulation de l’utilisateur comme la désactivation du support d’une
technologie, par exemple.

18. 2 Rétrocompatibilité
Maintenir une rétrocompatibilité stricte avec le référentiel AccessiWeb 2.2, sauf
exception répertoriée, pour le cas d’élément absents ou déclarés « obsolètes » par
HTML5 mais requis par AW 2.2.
summary En HTML 5
Obsolète non-conforme
Obsolète
Obsolète
Non-
Equivalents HML5
Conforme
Non-Compatibles
Conforme
<figcaption>
summary !
<detais>
Validation Validation
Warning Failure
L’absence de validité du code HTML5/ARIA résultante est prise en charge via une
déclaration de conformité partielle.

19. 3 Privilégier les éléments HTML5/ARIA si le support de l’accessibilité
est amélioré
Privilégier les éléments HTML5/ARIA équivalant ou non à des éléments définis dans
le référentiel AW 2.2, si le support de l’accessibilité est amélioré.
Landmark role
Améliore l’accessibilité mais
absence de support au clavier
banner, main,
navigation, search…
+ Skip links !

20. 4 Alternative à JavaScript
Sauf indication contraire lors de la procédure de labellisation, ne recourir aux
alternatives à JavaScript que lorsque le dispositif ou la fonctionnalité est
incompatible avec l’accessibilité..
Widget ARIA, Evènement ou
dispositif JavaScript
Non
Alternative
Systématique
Compatible
Compatible
Alternative compatible
L’alternative pourra constituer en la mise à disposition d’un contenu alternatif
conforme ou l’utilisation équivalente d’un élément défini par le référentiel AW 2.2.

21. 5 Navigation au clavier [en discussion]
Assurer la navigation au clavier sur et dans un composant complexe via la touche
tabulation, au moins, sauf si l’utilisateur est informé au préalable du fonctionnement
au clavier du composant complexe
Questions
Widgets ARIA
Navigation séquentielle obligatoire ?
Respecter les Design Patterns ARIA ?
Comment informer l’utilisateur ?
Les objections du groupe des Experts Référents ne permettent pas d’approuver ce
principe en l’état. Des consultations et de la recherche documentaire sont en cours.

22. 6 Robustesse
Respecter la sémantique HTML5 et ne pas modifier le rôle natif d’un élément via
ARIA sauf si cela permet d’améliorer la compatibilité avec l’accessibilité et ne
contrevient pas à l’un des principes de ce document.
<a href> <button> Modifier Surcharger un rôle
role= role= le rôle natif natif via un rôle ARIA
‘’button ’’ ‘’’heading ’’ d’un élément équivalent
HTML HTML HTML 5
Mappage Mappage L.S L.S
autorisé refusé
HTML 5
<button> <h(x)>
Autorisé Refusé Autorisé
+ behavior
Restrictions Failure Restrictions
La note « Using Aria in HTML » définit pour HTML5 les rôles utilisables pour
chaque élément HTML5 ainsi que le mappage requis si le support n’est pas assuré.

23. 4 Base de référence
Compatibilité avec l’accessibilité

24. Rappel : compatibilité avec l’accessibilité et problématiques liées
Dispositif, éléments, fonctionnalité, technologie
Non
Compatible avec les Compatible
technologies d’assistance et les
fonctionnalités d’accessibilité
des systèmes d’exploitation Alternative
Compatible
Le support d’HTML5/ARIA (2012, 2013, 2014… ??)
Variable, irrégulier et en cours d’implémentation
Compliqué à implémenter par les AT
Interprétations inconstantes pour les propriétés ARIA par exemple

25. Exemple : lier une légende à une image (Novembre 2012)
Conforme ARIA
<img alt=‘toto’ aria-labelledby=‘idtxt’ /> Pas supporté par les AT
Pas compatible
<p id=‘idtxt’>texte </p> (probablement jamais)
<figure> Conforme HTML5
<img alt=‘’toto’’ /> Support incomplet
<figcaption>texte</figcaption> Pas compatible
</figure> (2013, 2014…. ??)
<figure role=‘group’> Conforme HTML5/ARIA
<img alt=‘’toto’’ /> Patch ARIA provisoire
<figcaption>texte</figcaption> Compatible
</figure> (2013, 2014… ??)

26. Compatible avec l’accessibilité ?
Navigateur
+
Technologie 1. Tester quoi ?
d’assistance
+ 2. Sur quelle base ?
Système
d’exploitation
3. Comment tester ?
+
API(s)
d’Accessibilité

27. Approche proposée [en discussion] #1
Etablir une base de
Exemple de base de référence
référence représentative
- JAWS 13 Fr / FF 13 / WIN 7
AT
+ - JAWS 13 Fr / IE 9 / WIN 7
- NVDA 2012-3 / FF 16 / WIN 7
UA
+ - ZoomText Fr V1 / FF 16 / WIN 7
OS - ZoomText Fr V2 / IE 9 / WIN 7

28. Approche proposée [en discussion] #2
Déterminer les conditions et le seuil pour déclarer qu’un dispositif est compatible
avec l’accessibilité
Principe général
[1]. Tous les dispositifs HTML5/ARIA dans un même site sont fonctionnels pour
une même configuration.
Conditions et seuils
[2.a] Un dispositif HTML5/ARIA est considéré comme accessible s'il est
fonctionnel pour au moins une configuration pour chaque système d'exploitation
présent dans la base de référence.
[2.b] Un dispositif HTML5/ARIA est considéré comme accessible s'il est
fonctionnel pour x% des configurations présentes.
[2.c]. Un dispositif HTML5/ARIA est considéré comme accessible s'il est
fonctionnel pour une liste spécifique de configuration au moins.

29. Approche proposée [en discussion] #3
Etablir une méthode de gestion de la base de référence
Principe général
[1]. Pour les AT « payantes » la version de référence est l’avant-dernière version
Cas identifiés nécessitant une mise à jour
[1] Référencement d’une nouvelle configuration
[2] Versionnage d’une composante (AT, UA, OS) d’une configuration référencée
[3]. Déférencement d’une configuration (régression, abandon du support)
Cas des environnement maitrisés
[1]. La base de référence et ses mises à jour sont gérés directement par le
propriétaire du site (Conditions à définir)

30. Approche proposée [en discussion] #4
Etablir une méthodologie de test Etablir une base de connaissance
- Bibliothèque JS
Comment tester ?
- Tableau de
compatibilité de
l’état de l’art
Ces deux problématiques sont complexes et nécessitent des moyens

31. 5 Exemple d’adaptation du référentiel AW 2.2
Préambule

32. Exemple d’adaptation : préambule
Objectif Moyens
Fournir aux producteurs de
contenus toutes les Suppression, ajout, modification
adaptations « connues » d’un critère, d’un test, d’une
issues de : condition…
Spécifications Ajout de ‘’notes techniques’’ et/ou
de cas particuliers permettant de
Etat de l’art préciser des aspects techniques
particuliers
Résultat de tests

33. Exemple d’adaptation du référentiel AW 2.2
Thématique 1 : Images

34. Exemple d’adaptation : thématique 1 Images #1
Critères modifiés
Critère 1.2 [Bronze] Pour chaque image de décoration ayant une
alternative textuelle, cette alternative est-elle vide (Hors cas particulier) ?
- Test 1.2.1 : Pour chaque image de décoration (balise img) ayant un attribut alt, le
contenu de cet attribut est-il vide (alt="") (Hors cas particulier) ?
Ajout d’un cas particulier pour prendre en charge l’utilisation d’une légende
(figcaption) liée à une image de décoration.
Dans ce cas la notre technique de WAI « Techniques for providing useful text
alternatives” demande que l’alternative soit renseignée par un nom d’image au
moins.

35. Exemple d’adaptation : thématique 1 Images #2
Cas particulier
Cas particulier pour le critère 1.2 :
La note technique "Techniques for providing useful text alternatives" recommande,
lorsqu’un élément FIGCAPTION est utilisé pour créer un titre ou une légende à une
image, que l’alternative soit renseignée (attribut ALT) afin de créer une association
implicite entre l’image et son titre ou sa légende.
Cette implémentation est actuellement laissée au libre choix de l’auteur.
Dans ce cas, le critère 1.2 sur les images de décoration est Non-Applicable.
La pertinence de l’alternative sera évaluée conformément à la note technique
"Techniques for providing useful text alternatives" - section "The figure and figcaption
elements" - exemple C qui stipule que, dans ce cas, l’alternative doit permettre
d’identifier l’image (label), notamment par rapport à sa légende;

36. Exemple d’adaptation : thématique 1 Images #3
Critères ajoutés
Critère HTML5-1 [Bronze] Chaque image de décoration ne doit pas
posséder de titre, cette règle est-elle respectée ?
- Test HTML5-1.1 Chaque image de décoration (balise IMG) ne doit pas posséder
d’attribut TITLE, cette règle est-elle respectée ?
La notre technique de WAI « Techniques for providing useful text alternatives”
interdit l’utilisation de l’attribut title pour donner un nom (label) à une image de
décoration.
Cette disposition est une violation assumée de la spécification HTML 5 qui
recommande cet usage.

37. Exemple d’adaptation : thématique 1 Images #4
Critères ajoutés
Critère HTML5-3 [Bronze] Pour chaque image vectorielle de décoration
ayant une alternative, cette alternative est-elle vide ?
- Test HTML5-3.1 : Chaque image vectorielle (balise SVG) non porteuse
d’information vérifie-t-elle une de ces conditions ? :
o L’élément SVG ne contient pas d’alternative textuelle
o L’élément SVG contient une alternative sous la forme d’une image de décoration
(attribut ALT vide)
Prise en charge du cas d’une image SVG de décoration

38. Exemple d’adaptation : thématique 1 Images #5
Critères ajoutés
Critère HTML5-4 [Bronze] Chaque image vectorielle porteuse
d’information a-t-elle une alternative ?
- Test HTML5-4.1 : Chaque image vectorielle (balise SVG) porteuse d’information
vérifie-t-elle une de ces conditions ? :
o L’élément SVG contient une alternative textuelle
o L’élément SVG contient une alternative sous la forme d’une image possédant un
attribut ALT
o Un lien adjacent permet d’accéder à une alternative
Prise en charge du cas d’une image SVG porteuse d’information, obligation d’une
alternative.

39. Exemple d’adaptation : thématique 1 Images #6
Critères ajoutés
Critère HTML5-5 [Bronze] Pour chaque image vectorielle porteuse
d’information ayant une alternative, cette alternative est-elle pertinente ?
- Test HTML5-5.1 : Chaque image vectorielle (balise SVG) porteuse d’information
vérifie-t-elle une de ces conditions ? :
o L’élément SVG contient une alternative textuelle pertinente
o L’élément SVG contient une alternative sous la forme d’une image possédant un
attribut ALT dont le contenu est pertinent
o L’alternative accessible via un lien adjacent est pertinente
Prise en charge du cas d’une image SVG porteuse d’information, pertinence de
l’alternative.

40. Exemple d’adaptation : thématique 1 Images #7
Notes techniques
Note 1 : Pour créer une légende HTML5/ARIA propose l’utilisation d’un attribut
TITLE sur une image de décoration ou une image porteuse d’information. Dans l’un ou
l’autre des cas la restitution (alternative seule, alternative et titre ou titre seul) ne peut
être garantie avec suffisamment de robustesse. Comme le spécifie la note technique
"Techniques for providing useful text alternatives" cette utilisation n’est pas
appropriée (cf critère additionnels).
Note 2 : L’élément APPLET est déclaré obsolète non conforme en HTML 5,
néanmoins les tests 1.1.4, 1.2.3, 1.3.4, 1.4.3, 1.6.3, 1.7.4, 1.8.4, 1.9.4 restent applicables
si l’élément est implémenté (cf principe 2)
Note 3 : Dans le cas de l’utilisation d’un élément AREA sans attribut HREF, HTML 5
recommande que l’attribut ALT soit absent. Néanmoins les tests 1.1.2 et 1.2.2 restent
applicables (cf principe 2).

41. Exemple d’adaptation : thématique 1 Images #8
Notes techniques
Note 4 : Compte tenu du fait que le test AW2.2 [1.6.1] stipule qu’un texte adjacent
peut faire office de description détaillée (à la condition que la présence de la
description détaillée soit signalée dans l’alternative), l’association explicite créé via les
éléments FIGURE, FIGCAPTION et le rôle GROUP pourra être considérée comme une
alternative pour la description détaillée. Dans ce cas, le test 1.6.1 sera réputé valide et
le test 1.7.1 applicable.
Note 5 : Bien que le support pour l’accessibilité des images bitmap ou des formes 2D
implémentées via l’élément CANVAS ait beaucoup progressé, il est encore insuffisant.
En conséquence l’élément CANVAS ne peut pas être utilisé pour embarquer une
image porteuse d’information.

42. Exemple d’adaptation : thématique 1 Images #9
Eléments non traités [en cours]
Attribut longdesc pour créer une description détaillée :
Le statut de l’attribut longdesc, déclaré « obsolète non conforme » est encore
indéfini.
Utilisation du rôle « presentation » pour traiter les images de
décoration notamment :
Objection relevée par Aurélien dans la discussion en cours. (La note technique
«Techniques for providing useful text alternatives » ne fait pas mention de cette
technique)

43. 6 Le futur référentiel AW HTML5/ARIA

44. Merci de votre attention
Questions ?
Réactions ?
Suggestions ?
Précisions ?