Accessibility Tools for content producers/checkers

[gregoriopellegrino]

For those involved in producing and controlling accessible EPUBs it would be very useful to have tools to highlight graphically:

• the semantic role of the HTML tags used in the ebook
• the alternative texts of the images
• the reading order

Something like this:

Some CSS/JS libraries that could be used as a starting point:

• https://khan.github.io/tota11y/
• http://whatsock.com/training/matrices/visual-aria.htm
• http://pauljadam.com/bookmarklets/index.html

Gregorio

[llemeurfr]

Hi Gregorio, our dev team is asking what we can do with this issue. IMO not much, as Readium Desktop is a toolkit for desktop reader development and Thorium is a particular desktop reader. So not something like ACE / SMART from DAISY. I'll therefore close the issue but please reopen it if you see a use case.

[llemeurfr]

Because Thorium is starting being used as a reference reader by publishers, this issue may have a use case.
We can discuss it further then.

[danielweck]

One obvious problem with "bookmarklets" (or any other technique to inject Javscript+HTML+CSS into publication documents) is that the tools' user interface interferes with Thorium's rendering / layout engine (pagination, selection / highlighting, calculation of reading location based on markup present on the page, etc.). In many ways, MathJax introduces similar issues with its popup menu, and we know that the user experience is currently degraded due to focus steal / jumpy scroll, as Thorium and MathJax compete for control of the document presentation.

All that said, it would be very interesting to explore design options. For example Thorium could open a separate view to execute such custom presentations of loaded documents, without affecting reading location, pagination, etc.

PS: injection of arbitrary Javascript is of course a bad idea due to security issues, but let's also keep in mind that LCP-protected content could easily be compromised with some of these third-party tools.

[llemeurfr]

Thorium could open a separate view to execute such custom presentations of loaded documents, without affecting reading location, pagination, etc.

This is the only way I can imagine a solution, yes. An alternate presentation, with no pagination, a script injecting / modifying content in the DOM (developed by us) and a specific "Readium a11y CSS".

The first step is then: would such a solution be acceptable? and in fact why would it be better to develop that inside Thorium, rather than as a separate tool (support of LCP protection?) ?

[danielweck]

I would like to hear more about the use case too.
What are the merits of a solution integrated in Thorium, vs. a tool outside of the reading system.
I imagine there is the convenient advantage of being able to check (a11y or other quality metrics) directly a loaded publication, but if we disable pagination and other reading system injected features then the checked document is not really representative of the final rendered output ... so this would kind of defy the point. Plus, the validation result / check report would typically trigger a feedback loop, causing document edits, publication re-packaging, re-ingestion in Thorium's bookshelf, etc.
In that case, it would seem much easier to execute all the checks in a standard web browser, outside of the reading system's constraints.

[gregoriopellegrino]

I'll try to give some answers, from my perspective.

why would it be better to develop that inside Thorium, rather than as a separate tool (support of LCP protection?) ?

Thorium is open-source. Thorium has already developed all the EPUB library management, interface, TOC management, pagelist, landmarks, search function, etc... And all of this is under continuous maintenance.
I think it's simpler to add the functionality dedicated to accessibility validation to the Thorium reading system (which is already developed), rather than creating a new reading system from scratch, dedicated only to accessibility checking.

[danielweck]

bug triage: moving to discussion.