Mesure de la conformité WCAG 2.0 via le référentiel AccessiWeb 2.2 avec HTML5/ARIA

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

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

3. Sommaire en 7 points Rappels • Préambule • Introduction • Les principes • Base de références • Exemples – Préambule – Thématique Images • 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 : • Mise en place d’une procédure adaptée dans le cadre de la labellisationPourquoi ? • 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) • 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 6 principes Destinés à assurer la transition entre AW 2.2 et HTML5/ARIA Base de référence AT/UA/OS Destinée à gérer la notion de « compatible avec l’accessibilité » Liste des adaptations connues Adaptation des critères AW 2.2 (critères, tests, conditions, cas particuliers, notes techniques) Base de connaissance Qualifier, autant que possible des widgets ARIA pour l’accessibilité

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

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

17. 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 1 <vidéo > / <audio> <svg> NonoCompatible NonoCompatible Compatible <object>Conforme AW 2.2 Présence d’une alternative texte 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. 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. 2 En HTML 5 summaryObsolète non-conforme Obsolète Non-Conforme Obsolète Conforme Equivalents HML5<figcaption><detais>Non-Compatibles summary ! Validation Validation Failure Warning L’absence de validité du code HTML5/ARIA résultante est prise en charge via une déclaration de conformité partielle.

19. 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é. 3 Landmark rôleAméliore l’accessibilité mais absence de support au clavier banner, main, navigation, search… + Skip links !

20. 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é.. 4 Widget ARIA, Evenement ou dispositif JavaScript AlternativeSystématique Non 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. 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 5 Questions Widgets ARIA Navigation séquentielle obligatoire ? Respecter les Design Pattern 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. 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. 6 Surcharger un rôle natif via un rôle ARIA équivalent Modifierle rôle natifd’un élément <button>rôle=‘’’heading ’’ <a href>rôle=‘’button ’’ HTMLL.S HTMLL.S HTML 5 Mappagerefusé Mappageautorisé HTML 5 <button> <h(x)>+ behavior RefuséFailure AutoriséRestrictions Autorisé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 NonCompatible Compatible avec les 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) <imgalt=‘toto’ aria-labelledby=‘idtxt’ /><p id=‘idtxt’>texte </p> Conforme ARIAPas supporté par les ATPas compatible(probablement jamais) <figure> <imgalt=‘’toto’’ /> <figcaption>texte</figcaption></figure> Conforme HTML5Support incompletPas compatible(2013, 2014…. ??) <figure role=‘group’> <imgalt=‘’toto’’ /> <figcaption>texte</figcaption></figure> Conforme HTML5/ARIAPatch ARIA provisoireCompatible(2013, 2014… ??)

26. Compatible avec l’accessibilité ? Navigateur + • Tester quoi ? • Sur qu’elle base ? • Comment tester ? Technologie d’assistance + Systèmed’exploitation + API(s) d’Accessibilité

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

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 (regression, 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 • Tableau de compatibilité de l’état de l’art Comment tester ? 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 adaptations « connues » issues de : • Spécifications • Etat de l’art • Résultat de tests • Suppression, ajout, modification d’un critère, d’un test, d’une condition… • Ajout de ‘’notes techniques’’ et/ou de cas particuliers permettant de préciser des aspects techniques particuliers

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ésCritè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 particulierCas 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ésCritè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 recomande cet usage.

37. Exemple d’adaptation : thématique 1 Images #4 Critères ajoutésCritè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 textuelleo    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 images SVG de décoration

38. Exemple d’adaptation : thématique 1 Images #5 Critères ajoutésCritè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 textuelleo    L’élément SVG contient une alternative sous la forme d’une image possédant un attribut ALTo    Un lien adjacent permet d’accéder à une alternative Prise en charge du cas d’une images SVG porteuse d’information, obligation d’une alternative.

39. Exemple d’adaptation : thématique 1 Images #6 Critères ajoutésCritè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 pertinenteo    L’élément SVG contient une alternative sous la forme d’une image possédant un attribut ALT dont le contenu est pertinento    L’alternative accessible via un lien adjacent est pertinente Prise en charge du cas d’une images SVG porteuse d’information, pertinence de l’alternative.

40. Exemple d’adaptation : thématique 1 Images #7 Notes techniquesNote 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 techniquesNote 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 providingusefultext 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 ?