ARIA in Ebooks – Does It Make Sense, And If So, When?
Written by
Monika Zarczuk-Engelsma
Posted on
Aug 24, 2026
Category
Accessibility
Anyone involved in web accessibility will sooner or later come across the mysterious acronym ARIA. To some, it sounds like an essential component of every project, while others view it as something reserved exclusively for software developers. It is hardly surprising, then, that the question arises in the publishing world as well: since an accessible e-book is based on HTML, should it also utilize ARIA?
The answer is: sometimes yes, but much less often than one might think.
And that is precisely what is most interesting.
What Exactly Is ARIA?
ARIA (Accessible Rich Internet Applications) is a set of attributes that help assistive technologies better understand the elements of a website or application. Thanks to them, a screen reader can receive additional information about what a given element is, what function it performs, or what state it is in.
For example, a menu-expanding button can inform the user whether it is currently expanded or collapsed. A form can indicate that a field contains an error. A dialog box can be recognized as a dialog box rather than just a piece of text.
This is of great importance on websites.
But an ebook is not a website.
And that is precisely why ARIA looks completely different here.
HTML First, ARIA Later
This sentence is worth remembering.
One of the fundamental principles of accessibility is:
If something can be done correctly using HTML, it should not be replaced with ARIA.
Why?
Because HTML was designed from the start as a language that describes the meaning of content.
A heading marked up as <h1> is a heading.
A list marked up as <ul> is a list.
A table marked up as <table> is a table.
Screen readers understand it perfectly.
Adding extra ARIA descriptions to such elements usually does not improve anything, and can sometimes even cause confusion.
Accessibility specialists often repeat the principle:
“No ARIA is better than bad ARIA.”
It can be translated very simply:
It is better not to use ARIA at all than to use it incorrectly.
EPUB Already Knows What a Chapter Is
This is one of the things that most surprises people starting to work with EPUB 3.
It seems that since ARIA exists, everything should be described using it.
Meanwhile, EPUB has its own semantic mechanism.
It is possible to tag, among other things:
a chapter,
a footnote,
bibliography,
index,
preface,
afterword,
table of contents,
glossary.
This is done using the epub:type attribute.
For example, a footnote can be tagged as:
epub:type="footnote"
The reader then receives a clear indication that the user is navigating to a footnote.
No ARIA is needed for this.
This solution was created specifically with digital publications in mind.
When does ARIA really help?
However, there are situations where it can prove very useful.
This most often applies to more advanced publications.
Imagine a biology textbook containing an interactive cell model. Clicking on individual elements reveals additional descriptions.
Or a language course where you can expand on word definitions.
Or an educational publication containing quizzes.
This is no longer an ordinary book.
It is a small application embedded within the EPUB.
And that is precisely when ARIA becomes necessary.
It allows you to inform the screen reader that an element is a button, a tab, an expandable section, or a dialog box.
Without this information, the user might not even know that a given element is interactive.
An Example from the Publishing World
Let us imagine a plant atlas prepared as a modern EPUB 3.
Tapping the flower illustration brings up a panel with a description of the species.
A sighted person will immediately notice that something has happened.
A person using a screen reader might not receive any information.
Has the application just opened a new window?
Has new text appeared?
Has the focus moved to the new section?
If the developers implement the appropriate ARIA mechanisms, the screen reader will inform the user that a dialog box has opened or a new section has expanded.
Thanks to this, the interaction becomes understandable.
Then Maybe Add ARIA Everywhere?
This is one of the most common mistakes.
People just starting out with accessibility sometimes conclude that, since ARIA is helpful, the best approach is to use it to describe the entire document.
The effect is sometimes the opposite of what was intended.
The reader begins to receive conflicting information.
A heading is both an HTML heading and something described in additional detail.
A list is presented twice.
Navigation elements are starting to duplicate.
As a result, the user hears more messages but understands less.
It’s a bit like adding three extra pages of instructions to every chapter of a paper book, explaining that the chapter is about to begin.
Does a Standard Ebook Need ARIA?
In the vast majority of cases, the answer is: no.
A typical novel, reportage book, self-help book, or popular science book does not require the use of ARIA.
Of far greater importance are:
proper heading structure,
semantic HTML,
alternative text,
well-structured tables,
logical navigation,
a proper table of contents.
It is precisely these elements that determine whether a book is comfortable to read.
Well-prepared HTML will do far more for accessibility than dozens of unnecessary ARIA attributes.
HTML and ARIA Do Not Compete with Each Other
This is an important distinction.
ARIA was not created to replace HTML.
Its purpose is to supplement information where HTML alone is insufficient.
It is a bit like footnotes in a book.
If everything can be explained in the main text, a footnote is not needed.
However, if something requiring additional explanation appears, a footnote becomes very helpful.
It’s similar in the case of ARIA.
First, it is worth leveraging the capabilities offered by HTML and the EPUB 3 standard.
It is only when a publication contains truly interactive elements or unconventional solutions that it is worth considering the use of ARIA.
Accessibility Is Not about the Number of Technologies Employed
Lastly, it is worth dispelling one more myth.
The deeper I delve into the world of available ebooks, the more often I see that the best publications are not necessarily the most complex ones.
Quite the opposite.
Najlepsze E-booki wykorzystują standardy zgodnie z ich przeznaczeniem.
The best ebooks use standards as intended.
HTML describes the structure,
ePUB describes book-specific elements,
CSS handles the visuals.
ARIA is used only when truly necessary.
That is precisely why accessibility is not about adding further layers of technology, but rather about making conscious use of the tools already at our disposal. A well-crafted e-book does not impress through the sheer number of features employed; it impresses because the reader can simply focus on the book itself, rather than struggling with the technology.
Bibliography:
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