Le 13 décembre dernier avait lieu le 17e séminaire technique AccessiWeb organisé par l’association BrailleNet à la Cité des Sciences et de l'Industrie de la Villette à Paris. Il s’agit d’un séminaire réservé aux membres du Groupe de Travail AccessiWeb (GTA), rassemblant pas moins de 461 Experts AccessiWeb en Évaluation. Étaient présents une cinquantaine d’Experts pour ce nouveau séminaire dont deux d'Alsacréations pour vous relater ce qui suit.
Dominique Burger (INSERM), le président de l’association BrailleNet, a démarré la journée par une conclusion (oui, on fait les choses à l'envers) plutôt détaillée du questionnaire qui avait été adressé aux membres du GTA en novembre 2012 afin de recueillir les avis et suggestions pour améliorer l’organisation du GTA. Beaucoup de propositions ont été retenues et devraient être développées au cours de l’année (wiki, forum...). Vous pouvez consulter la synthèse du questionnaire du GTA (fichier PPT).
On enchaîne avec Jean-Pierre Villain (Qelios) et Denis Boulay (BrailleNet, AccessiWeb) pour une présentation de l’évolution du référentiel AccessiWeb vers une version 2.2 avec HTML5 et ARIA.
Pourquoi un nouveau référentiel ?
Jean-Pierre Villain nous explique que le référentiel AccessiWeb actuel - version 2.2 - n’est pas adapté à une labelisation de sites web développés en HTML5/ARIA, notamment dû aux nombreux changements avec HTML5 (suppression de certains éléments valides en XHTML par exemple). Une mise à jour du référentiel est devenue indispensable.
La publication de ce nouveau référentiel est prévue pour le 1er semestre 2013. Celui-ci devrait conserver la même forme que le référentiel AccessiWeb 2.2, avec une base de connaissance en plus. Pour suivre l’avancement du projet, vous pouvez consulter le forum public Accessiweb HTML5/ARIA.
Concrètement, qu'y aura-t-il de nouveau ?
Cette évolution du référentiel liste un bon nombre de nouveautés, parfois étonnantes comme l'abandon total des alternatives à Javascript : obligatoires jusqu'au référentiel actuel, elles ne seront plus forcément nécessaires pour fournir une alternative aux éléments développés en JavaScript, jQuery etc. D'autant plus que si une fonctionnalité HTML5 est inaccessible, on peut recourir soit à une alternative en JavaScript, soit à un dispositif conforme au référentiel AccessiWeb 2.2.
Des éléments obsolètes, mais pas trop
Les nouvelles spécifications de HTML5 rendent certains éléments et attributs HTML obsolètes, mais tant qu'il n'y aura pas d'équivalent, le nouveau référentiel AccessiWeb recommande malgré tout d'utiliser ces éléments dépréciés. Cela concerne notamment les attributs summary et longdesc (en cours de discussion pour ce dernier).
Il en va de même pour les liens d'évitements qu'il est préférable de conserver tant que les landmarks roles (rôle des sections du document) ne sont pas lus par défaut par l'ensemble des lecteurs d’écrans (ce qui n'est pas encore le cas actuellement). Il est important de noter aussi que l'attribut role est encore nécessaire sur les éléments de section car leur rôle natif et implicite n'est pas encore totalement implémenté par les lecteurs d'écrans.
Des possibilités graphiques encore en attente
HTML5 offre de nouvelles possibilités graphiques avec SVG et Canvas, mais ces derniers posent des problématiques d'accessibilité, notamment pour Canvas qui n'est qu'une surface de pixels. La présence d’une alternative - textuelle ou image avec description texte - sera nécessaire pour SVG, tandis que Canvas ne devra en aucun cas être utilisé pour diffuser de l'information (on peut l'employer à titre décoratif pour l'instant).
Personnalisation des fonctions natives
Il est tout à fait possible de modifier la fonctionnalité native d'un élément mais le référentiel fixera tout de même quelques restrictions, qui seront publiées sous forme de liste.
Exemple d'une personnalisation autorisée :
<a href="#" role="button">Exemple d'une personnalisation non autorisée :
<button role="heading">Une navigation au clavier plus personnalisée ?
La navigation au clavier devra toujours se faire à l'aide de la touche "tabulation" tout comme il sera possible d'utiliser d'autres touches pour certains modules, en prenant bien soin de prévenir au préalable l'utilisateur. Cette nouvelle forme de navigation peut être très utile pour des slideshows ou sélecteurs de date (alias datepicker) à l'aide des flèches de navigation par exemple.
Cette possibilité a tout de même des limites : si une page propose plus d'une dizaine de module avec chacun une navigation différente, on peut tomber très rapidement dans une usine à gaz et perdre notre internaute.
C'est pourquoi le critère est encore en cours de discussion. Il est surtout important de savoir comment implémenter et informer l'utilisateur.
Base de référence
Une base de référence sera mise à disposition pour effectuer les tests. Le principe général est que tout le monde teste sur une configuration identique.
| Lecteur d'écran | Navigateur web | Système d'exploitation |
|---|---|---|
| Jaws 13 en français | Mozilla Firefox 13 | Windows 7 |
| Jaws 13 en français | Internet Explorer 9 | Windows 7 |
| Nvda 2013-3 | Mozilla Firefox 16 | Windows 8 |
Il existera également une base de connaissance pour les widgets en JavaScript afin de mettre à disposition de tous des modules accessibles (slideshow, lightbox, slider...). Il faut savoir que pour tester l'accessibilité d'un module, il y a plus de 75 points à vérifier. Cette base de connaissance sera donc un gain de temps pour les développeurs qui n'auront pas à effectuer ces tests.
Et le RGAA ?
Le nouveau référentiel AccessiWeb HTML5/ARIA ne peut être relié à RGAA puisqu'il s'agit de deux choses totalement différentes. Le RGAA est figé depuis 2009 et n'a bénéficié d'aucune évolution depuis. Il serait néanmoins intéressant de converger les deux, ce qui est actuellement en cours de réflexion.
Actualités W3C / WAI
Sylvie Duchateau prend le relais et nous présente l'actualité du W3C. On apprend notamment que WCAG est devenu une norme ISO/CEI 40500 depuis le 15 octobre 2012.
Parmi les projets en cours, il y a notamment :
- la rédaction de WCAG Evaluation Methodology (EM),
- la traduction en français de "Comment rendre des présentations accessibles à tous",
- contacter des organisations à propos de l'inaccessibilité de leur site,
- la traduction en français de "Before & After Demonstration" (BAD).
Présentation de AcceDeWeb
Quelques membres de l'équipe d'Atalan (Sylvie Goldfain et Johan Ramon) sont venus nous présenter le projet AcceDe Web et ses notices d’accessibilité. L'équipe nous explique comment et pourquoi le projet est né : le but était surtout d'évangéliser les bonnes pratiques liées à l'accessibilité dans toutes les phases d'un projet - le graphisme, l'intégration HTML, le développement en JavaScript et la rédaction de contenu. Une traduction en anglais est prévue prochainement.
Notez qu'il est tout à fait possible d'utiliser, modifier et adapter le contenu de chacune de ces fiches pour vos projets, à condition de citer les auteurs. Un premier retour d'expérience nous a été donné par Catherine Berenblit et Guillaume Wurier (EDF) qui ont utilisé ces notices dans le cadre de la refonte de l'intranet. Les fiches, très appréciées par l’équipe, ont été modifiées et adaptées à leur projet.
Livre numérique et format ePub3
La journée se termine avec Romain Deltour (Consortium Daisy) sur une présentation générale du livre numérique et plus particulièrement du format ePub dans sa version 3.
Basé sur les bonnes pratiques du web, le format ePub3 est un format ouvert qui a été publié fin 2011. C'est un format qui a été conçu pour la distribution (édition, échange, archivage) mais aussi les livres, magazines, documents... Une méthodologie est en cours d'écriture.
Quelques chiffres : En Angleterre, 7% des livres numériques du marché sont accessibles et plus de 76% le sont pour les livres les plus populaires (statistiques basées sur environs 100 000 livres).
Vers HTML5 et au delà
ePub3 va au delà des fonctionnalités de HTML5 avec :
- une navigation avancée grâce à des structures expressives
- un ensemble de méta données très riches
- une internationalisation (Unicode, ordre de lecture...)
- une mise en page évolutive
- un contenu qui peut être interactif et enrichi (avec des vidéos, audio, animations, quiz, slideshow...)
On se retrouve face à un balisage XHTML5 où les attributs role ont beaucoup d'importance. Intégrés à l'aide de epub:type="", les systèmes de lecture ont plutôt intérêt à implémenter sa compréhension pour une meilleure compatibilité et utilisation des formats ePub3. Quelques exemples :
<aside epub:type="footnote">
<section epub:type="conclusion">
<dl epub:type="glossary">Vers les synthèses vocales et l'interactivité
On retrouve de plus en plus de synthèse vocale sur les produits actuels - que ce soient les tablettes ou les liseuses de livres électroniques - qu'on peut gérer et personnaliser très facilement grâce aux recommandations de EPUB3 Overview.
De l'annotation SSML au lexique de prononciation, on peut également personnaliser le type de voix et le rythme de lecture grâce à CSS3 Speech.
ePub3 Media Overlays permet aussi de gérer la lecture mixte (lecture texte et lecture audio) et l'interactivité de lecture en suivant l'interaction de l'utilisateur (commencer à lire la phrase sur laquelle l'utilisateur vient de cliquer par exemple).
Quelques recommandations pour un bon ePub
Pour un bon fichier ePub, voici quelques recommandations retenues lors de cette présentation :
-
L'attribut
aria-describedbyest conseillé -
Les éléments
captionetfigcaptionsont conseillés - Tout SVG doit être accompagné d'une description
-
L'attribut
altest obligatoire sur les images -
La description avancée est implémentée avec
epub:describedAt
Pour créer un fichier ePub, voici une liste non exhaustive de logiciels :
- Adobe inDesign (mais ce n'est pas le plus accessible),
- Éditeurs xml,
- Éditeurs spécialisés (Bluegriffon ePub),
- Daisy Pipeline 2 (conversion automatique au format ePub),
- ePub Check (permet de tester un fichier ePub).
Pour en savoir plus sur ce format ePub, nous vous conseillons ePub3 accessilibity guidelines ou les exemples de fichiers ePub par IDPF disponibles sur Google Code.
A consulter
Vous pouvez consulter le programme de la journée ainsi qu'un petit résumé sur le site d'AccessiWeb. Vous y retrouverez également l'ensemble des présentations. Rendez-vous au prochain séminaire !
Commentaires
Bonjour,
Merci pour ce compte-rendu très complet et, pour ce qui me concerne, très satisfaisant sur la partie HTML5/ARIA.
Une petite précision néanmoins : le problème des landmarks n'est pas tant qu'ils ne sont pas supportés (car en réalité ils sont supportés par les versions récentes de JAWS et NVDA) mais qu'au delà des utilisateurs non-voyants ils sont destinés à servir également de support pour les utilisateur de la navigation au clavier pour lesquels ils seraient une réponse efficace à la navigation rapide dans la structure de la page.
Comme d'habitude ces grands oubliés du web ne bénéficient pas encore de fonctionnalités développés par les navigateurs leur permettant d'utiliser les landmarks comme éléments de navigation.
C'est la raison pour laquelle l'adaptation du référentiel AccessiWeb à HTML5/ARIA prévoit de rendre les deux dispositifs obligatoires (landmark et liens d'accès rapide). En revanche, dés lors que ces dispositifs de navigation rapide seront disponibles pour tous les utilisateurs qui en ont besoin, les liens d'accès rapide pourront cesser d'être requis.
Autre précision utile : il n'est pas du tout évident (en fait c'est même plutôt l'inverse) que l'utilisation universelle de la touche de tabulation soit conservée car cela génère beaucoup de problèmes : surcharge systématique des composants produits par les bibliothèques JS implémentant ARIA, complexité des messages d'aides contextuels, redondance de ces mêmes messages avec ceux éventuellements utilisés par les AT etc. Tout porte à croire que faute de pouvoir imaginer des dispositifs d'aides suffisamment robustes le seul choix raisonnable soit de se conformer aux authoring practices ARIA. Cela impliquerais sur certains types de composants que l'accès par la tabulation ne soit pas actif (généralement au profit des touches de directions) et que ce problème d'utilisabilité soit laissé à l'appréciation de l'auteur.
Enfin, même si la compatibilité avec RGAA parait plus complexe cette adaptation (et à fortiori un futur référentiel HTML5/ARIA) ne remet pas en cause la compatibilité avec RGAA qui devra s'appuyer sur les critères de succès WCAG/RGAA (à défaut de pouvoir utiliser la liaison de critères HTML5/ARIA AW vers les tests RGAA actuels), accompagné si nécessaire de déclaration dérogatoires.
JPV
Merci Jean-Pierre pour toutes ces précisions ;]
Merci beaucoup pour ce gros compte rendu !
J'ai hâte de lire ce nouveau référentiel ;-)