Accessibilité

Epub3, un format pour l'avenir

Posté dans, , , , ,

De septembre 2014 à mars 2015, j'ai fait un stage à la fondation Accès pour tous à Zürich. Pendant ce stage, j'ai développé une application permettant de créer des cours et des tests interactifs accessibles dans le format epub3. Cette application a été également le sujet de mon projet de master, nommé Accessible course material with epub3, pour lequel j'ai récemment obtenu la note de 6 (équivalent à 20 en France).
Ce travail me permet de conclure en apothéose mes études à l'EPFL; je suis maintenant officiellement ingénieur informaticien EPF !

Le format epub3 est intéressant car il a été conçu dès le départ pour être accessible, il est standardisé et ouvert, et il intègre les ternières technologies web (HTML5, CSS3 et JavaScript), auxquels ont été ajoutés divers autres sous-standards pour répondre aux besoins spécifiques des livres numériques que n'ont pas les sites web, par exemple la navigation entre les documents, la pagination et la consultation hors ligne.
Il a tous les atouts pour devenir un format de choix pour diffuser un large éventail de documents accessibles, que ce soit des cours, des tests interactifs, des livres plus ou moins riches et complexes intégrant de l'interactivité et du multimédia, ou même pourquoi pas des documents administratifs grâce aux possibilités de signature numérique potentiellement offertes. IL est bien supérieur à word ou PDF pour ce faire, tant dans le domaine de l'accessibilité que de celui d'une probable maintenance.
Le plus grand obstacle à sa diffusion réside très probablement dans la'ttachement populaire à des technologies archaïques telles que PDF, et au semblant manque de volonté dont les étideurs font encore preuve malgré que la version 3 de ce format ait été développé il y a quelques années déjà.

Lorsqu'on achète en livre électronique aujourd'hui, dans le meilleur des cas il est encore à la version 2 du format epub, quand on a de la chance et que ce n'est pas encore du PDF ou des fichiers aux formats propriétaires volontairement conçus pour être non-interopérables. Corrollaire, les logiciels de lecture compatibles avec la version 3 et qui de plus est accessibles sont encore très rares, et c'est par conséquent le serpent qui se mord la queue: pas de logiciel de lecture, pas de support des étideurs, et pas de support des éditeurs, pas de logiciels de lecture. Il faut admettre qu'il va encore probablement falloir faire avec ce satané PDF pendant de nombreuses années.

En outre, l'achat de livres en ligne est souvent un problème pour une personne non-voyante, car on a constamment le risque de se retrouver avec un objet dûement acheté mais partiellement ou totalement inexploitable, et il n'y a aucun moyen sûr de savoir avant d'acheter l'ouvrage à quel point il sera ou non accessible. De plus les moyens pour se faire rembourser une fois le constat malheureux établi va de « tu peux te brosser » à possible mais plutôt compliqué.
JE vous avais déjà parlé aussi d'autres possibles problèmes de l'achat en ligne, ou du moins celui proposé par certains éditeurs. Avec le recul, l'application en question s'est avérée, sans aucune surprise, particulièrement décevante, et ce n'est pas près de changer vu leur mentalité.

JE suis d'avis que PDF devrait disparaître sans délai, au moins pour les raisons suivantes :

Pour en revenir à l'application que j'ai développée, il s'agit d'un éditeur de documents epub3 sous forme d'une application web open source. L'objectif était de permettre à quiconque de produire des documents accessibles dans ce format sans trop de difficultés, au départ des cours et des test interactifs, prévue pour des profs.

A l'issue des 6 mois de stage, on est encore à des années lumières d'une exploitation à grande échelle et même d'un minuscule déploiement réaliste, mais si vous êtes curieux, vous pouvez aller voir sur GitHub: répertoire GitHub du projet.
Mon stage est terminé depuis mars mais le projet ne l'est pas pour autant; pour le moment, il est en stand-by, en espérant qu'il pourra repartir ultérieurement.

Caractères unicode, icônes textuelles et accessibilité

Posté dans, , ,

Aujourd'hui, de plus en plus de sites utilisent des caractères unicode pour afficher des caractères spéciaux (des flèches par exemple) ou de petites icônes sous forme de caractères (ce qu'on appelle des icônes textuelles; les icônes pour partager un contenu sur des réseaux sociaux ou pour lancer la lecture d'un clip multimédia intégré par exemple), qui n'étaient autrefois qu'affichables en tant qu'images.

Afficher des caractères unicode à la place d'images a plusieurs avantages dont ceux-ci :

Malheureusement, tout cela ne va pas sans inconvénients :

Vous l'aurez compris, c'est surtout ce dernier point qui fâche.

Lire la suite →

Le point sur les players audio/vidéo HTML5 et l'accessibilité

Posté dans, , , , ,

J'ai bien envie de remettre en ligne mes bonnes vieilles compositions musicales datant de l'ancien site, ou du moins, les plus réussies. C'est alors que m'est revenue tout naturellement la question des lecteurs directement intégrés sur les pages web, et leur accessibilité, au demeurant relativement décevante en règle générale.

Lire la suite →

Contenus exclusifs et contenus exclus aux lecteurs d'écran

Posté dans, , , ,

Pour que l'accessibilité fonctionne bien, il est en général souhaitable que le contenu des pages web soit le plus possible « rendu » de la même manière visuellement qu'avec un lecteur d'écran.
Il est malgré tout parfois utile que certains contenus soient exclusifs aux lecteurs d'écran mais effectivement non affichés, tandis que, au contraire, certains éléments bien affichés ne soient pas rendus lorsqu'on consulte la page avec un lecteur d'écran.

Ce mini-tutoriel va vous expliquer dans quels cas ça peut effectivement être utile, dans quels cas ça ne l'est pas, et comment faire concrètement.

Lire la suite →

ARIA role=application, ou la totale incompréhension

Posté dans, , , , ,

Il semblerait qu'une des tandance actuelles soit d'appeler « application web » à peu près n'importe quel site web 2.0 utilisant javascript et AJAX. « Application web », ça sonne forcément plus cool que « page web » ou « site web interactif » ou autres appellations similaires.

Parralèlement à cela, et c'est fondamentalement une très bonne chose, les attributs ARIA améliorant l'accessibilité de telles pages dynamiques sont de plus en plus utilisés. La plupart ne sont normalement pas trop difficiles à comprendre et à implémenter de manière raisonnablement correcte (je devrais peut-être écrire un article d'introduction sur le sujet), mais il en existe malgré tout certains qui paraissent néanmoins échapper à la compréhension générale et collective. Je dis ça parce que, en-dehors de mes développements personnels, je n'ai à ce jour rencontré encore aucun site les utilisant réellement comme il faut.

Le rôle ARIA application fait partie de ces derniers. C'est sur celui-là que j'aimerais m'attarder aujourd'hui, car il est tellement mal compris et mal implémenté qu'il pose des problèmes sur la quasi-totalité des sites web qui croient bien faire et qui l'utilisent malheureusement le plus souvent totalement incorrectement sans raison véritablement valable, hormis que ça paraît peut-être plus cool pour le commun des mortels que son site web soit considéré comme une application plutôt que comme un site.

En fait, personne ne paraît vraiment comprendre ce que ce rôle implique vraiment, de même que quand il devrait, et quand il ne devrait pas être utilisé.

Lire la suite →

← Articles plus anciensRSS 2.0 RSS 1.0