ARIA dans les livres numériques : est-ce utile, et dans quels cas ?

Toute personne qui s’intéresse à l’accessibilité des sites web finit tôt ou tard par rencontrer le mystérieux sigle ARIA. Pour certains, il semble être un élément obligatoire de tout projet ; pour d’autres, il serait réservé aux développeurs. Il n’est donc pas étonnant que le monde de l’édition se pose lui aussi cette question : puisqu’un livre numérique accessible repose sur le HTML, doit-il également utiliser ARIA ?

La réponse est : parfois oui, mais beaucoup moins souvent qu’on ne pourrait le penser.

Et c’est précisément ce qui rend le sujet intéressant.

Qu’est-ce qu’ARIA, au juste ?

ARIA (Accessible Rich Internet Applications) est un ensemble d’attributs qui aident les technologies d’assistance à mieux comprendre les éléments d’une page ou d’une application. Grâce à eux, un lecteur d’écran peut recevoir des informations supplémentaires sur la nature d’un élément, sa fonction ou son état.

Par exemple, un bouton qui ouvre un menu peut indiquer à l’utilisateur si celui-ci est déployé ou replié. Un formulaire peut signaler qu’un champ comporte une erreur. Une boîte de dialogue peut être identifiée comme telle, au lieu d’être traitée comme un simple fragment de texte.

Sur les sites web, cela a une grande importance.

Mais un livre numérique n’est pas un site web.

C’est pourquoi l’utilisation d’ARIA y occupe une place très différente.

D’abord le HTML, ensuite ARIA

Cette phrase mérite d’être retenue.

L’une des règles fondamentales de l’accessibilité est la suivante :

Si une fonction peut être correctement réalisée avec le HTML, il ne faut pas remplacer l’élément HTML par ARIA.

Pourquoi ?

Parce que le HTML a été conçu dès l’origine comme un langage permettant de décrire la structure et le sens du contenu.

Un titre balisé avec <h1> est un titre.

Une liste balisée avec <ul> est une liste.

Un tableau balisé avec <table> est un tableau.

Les lecteurs d’écran le comprennent très bien.

Ajouter des attributs ARIA à ces éléments n’améliore généralement rien et peut parfois introduire de la confusion.

Les spécialistes de l’accessibilité rappellent souvent cette règle :

« No ARIA is better than bad ARIA. »

On peut la traduire très simplement :

Mieux vaut ne pas utiliser ARIA que l’utiliser de manière incorrecte.

EPUB sait déjà ce qu’est un chapitre

C’est l’un des points qui surprennent le plus les personnes qui commencent à travailler avec EPUB 3.

On pourrait croire que, puisqu’ARIA existe, il faut l’utiliser pour tout décrire.

Pourtant, EPUB possède son propre mécanisme sémantique.

Il permet notamment d’identifier :

• un chapitre ;

• une note de bas de page ;

• une bibliographie ;

• un index ;

• une préface ;

• une postface ;

• une table des matières ;

• un glossaire.

Cela se fait à l’aide de l’attribut epub:type.

Par exemple, une note de bas de page peut être identifiée ainsi :

epub:type="footnote"

Le système de lecture reçoit alors une indication claire : l’utilisateur accède à une note de bas de page.

Aucun attribut ARIA n’est nécessaire pour cela.

Ce mécanisme a été conçu spécialement pour les publications numériques.

Quand ARIA est-elle vraiment utile ?

Il existe toutefois des situations dans lesquelles ARIA peut être très utile.

Elles concernent le plus souvent les publications plus élaborées.

Imaginons un manuel de biologie contenant un modèle interactif de cellule. Un clic sur les différents éléments fait apparaître des descriptions supplémentaires.

Ou un cours de langue dans lequel on peut développer les définitions des mots.

Ou encore une publication pédagogique contenant des quiz.

Ce n’est plus un simple livre.

C’est une petite application intégrée à un EPUB.

C’est dans ce contexte qu’ARIA peut devenir nécessaire.

Elle permet d’indiquer au lecteur d’écran qu’un élément est un bouton, un onglet, une section dépliable ou une boîte de dialogue.

Sans ces informations, l’utilisateur peut même ne pas savoir que cet élément est interactif.

Un exemple tiré de la pratique éditoriale

Imaginons un atlas de plantes conçu sous la forme d’un EPUB 3 moderne.

Lorsque l’on touche l’illustration d’une fleur, un panneau présentant l’espèce apparaît.

Une personne voyante remarque immédiatement qu’il s’est passé quelque chose.

Une personne qui utilise un lecteur d’écran peut ne recevoir aucune information.

L’application vient-elle d’ouvrir une nouvelle fenêtre ?

Un nouveau texte est-il apparu ?

Le focus s’est-il déplacé vers une nouvelle section ?

Si les créateurs utilisent les mécanismes ARIA appropriés, le lecteur d’écran informera l’utilisateur qu’une boîte de dialogue s’est ouverte ou qu’une section a été développée.

L’interaction devient ainsi compréhensible.

Et si l’on ajoutait ARIA partout ?

C’est l’une des erreurs les plus fréquentes.

Les personnes qui découvrent l’accessibilité concluent parfois que, puisqu’ARIA est utile, autant l’utiliser pour décrire tout le document.

Le résultat peut être contraire à l’effet recherché.

Le lecteur d’écran commence à recevoir des informations contradictoires.

Un titre est à la fois identifié comme un titre HTML et décrit d’une autre manière.

Une liste peut être annoncée deux fois.

Les éléments de navigation peuvent être annoncés de manière redondante.

L’utilisateur entend donc davantage de messages, mais comprend moins bien.

C’est un peu comme si, dans un livre imprimé, on ajoutait trois pages d’explications au début de chaque chapitre pour préciser qu’un chapitre commence.

Un livre numérique ordinaire a-t-il besoin d’ARIA ?

Dans la très grande majorité des cas, la réponse est :

Non.

Un roman, un reportage, un guide pratique ou un ouvrage de vulgarisation courant ne nécessite pas l’utilisation d’ARIA.

Les éléments suivants ont beaucoup plus d’importance :

• une structure de titres correcte ;

• un HTML sémantique ;

• des équivalents textuels ;

• des tableaux correctement structurés ;

• une navigation logique ;

• une table des matières correcte.

Ce sont ces éléments qui déterminent en grande partie la qualité de l’expérience de lecture.

Un HTML bien structuré fera beaucoup plus pour l’accessibilité que plusieurs dizaines d’attributs ARIA inutiles.

HTML et ARIA ne sont pas concurrents

Cette distinction est importante.

ARIA n’a pas été créée pour remplacer le HTML.

Son rôle est de compléter les informations lorsque le HTML ne suffit pas.

C’est un peu comme les notes dans un livre.

Si tout peut être expliqué dans le texte principal, une note n’est pas nécessaire.

En revanche, lorsqu’un point exige une explication supplémentaire, la note devient très utile.

Il en va de même pour ARIA.

Il faut d’abord exploiter les possibilités offertes par le HTML et le standard EPUB 3.

C’est seulement lorsque la publication contient des éléments véritablement interactifs ou des solutions inhabituelles qu’il convient d’envisager l’utilisation d’ARIA.

L’accessibilité ne se mesure pas au nombre de technologies utilisées

Pour terminer, dissipons un dernier mythe.

Plus j’explore le monde des livres numériques accessibles, plus je constate que les meilleures publications ne sont pas les plus compliquées.

Bien au contraire.

Les meilleurs livres numériques utilisent les standards conformément à leur fonction.

• Le HTML décrit la structure.

• EPUB décrit les éléments propres au livre.

• CSS définit l’apparence.

• ARIA n’intervient que lorsqu’il est réellement nécessaire.

C’est pourquoi l’accessibilité ne consiste pas à ajouter des couches technologiques, mais à utiliser de manière réfléchie les outils dont nous disposons déjà.

Un livre numérique bien préparé n’impressionne pas par le nombre de solutions mises en œuvre. Sa qualité tient au fait que le lecteur peut tout simplement se concentrer sur le livre, sans avoir à lutter avec la technologie.

Liens utiles:

https://ef-ef.pl/2025/05/22/atrybut-aria-w-e-bookach-dostepnosc/

https://www.gov.pl/web/dostepnosc-cyfrowa/aria-na-stronach-internetowych

https://dostepnik.substack.com/p/dostepnik-o-aria-i-zasadach

https://www.accessiblepublishing.ca/getting-started-with-aria-and-epub/

https://helpx.adobe.com/pl/indesign/using/aria-role-and-label-support.html

https://craftware.pl/klucz-do-web-accessibility/

https://www.accessiblepublishing.ca/getting-started-with-aria-and-epub/

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA

https://www.w3.org/WAI/standards-guidelines/aria/