[Discussion] Accessibility: docs, gaps, guidelines

[JayPanoz]

Please allow me to open this issue so that we can have a shared space to discuss accessibility in the “Reading System” context, we’ll at least be able to move it to another repo at some point in time.

Thanks to the Marrakech Treaty and initiatives such as Daisy’s Inclusive Publishing, accessibility has become a hot topic and a strong priority for a lot of people. For instance, several publishers mentioned it as something important when we discussed “cloud readers” with them.

Problem is – at least to me – in a very naïve way: it’s kinda hard to navigate between User Agent Accessibility Guidelines (UAAG) and docs such as WAI-ARIA Authoring Practices, and others (including WCAG because adaptability through settings, etc.).

Consequently it can be tough to know whether what you’re doing is reasonable to do in the first place, if not doing something and letting the browser handle it is the best option you have, and so on and so forth.

A few practical examples…

Let’s take settings, should this be a menu/menubar? In which case you kinda “declare” you are supporting the corresponding keyboard navigation, cf. Authoring Practices or this article. I mean, I couldn’t even pick between menu and menubar in the first place, in the sense user settings are somewhat very reminiscent of an editor menubar.

Then let’s imagine you have an “about this book” display, exposing metadata for the publication. Surely this could be considered a footer with the role of contentinfo? Or am I missing something? And how do you even markup those contents so that they can make sense in the webpage context?

Should you have a heading in the app’s interface? If so, how? Shall the book title you maybe have on top of the iframe be used?

Should “space” navigation be reimplemented in pagination? So instead of scrolling the doc, you progress one page like some Reading Systems already do?

Should “escape” hide the global menu/toolbar?

Should you attempt to reuse some keyboard shortcuts for some features e.g. increasing font-size or zooming fixed-layout? My worry is that once you start doing shortcuts, maybe you can go too far – i.e. same principle as ARIA role in the sense people tend to overuse it once they start using it.

And finally there is some “tension” between the browser and the web app in UAAG. A quick example: settings profiles + export/import. Is the web app claiming responsibility of that given user settings in its UI? But then, what to make of browsers’ settings e.g. font-size, font-family, etc.? and OS settings e.g. dark UI → night mode?

Note that at least part of those may well apply to native too, although in a different form so I’d really like to work with others on all these points if possible, and maybe have a set of guidelines that can be a lot clearer to deal with – I mean, I got some doubts very quickly, in part because ARIA is powerful hence easy to misuse (cf. all the epubcheck issues about dpub roles recently), and having to navigate across multiple docs is making it some kind of labyrinth at first.

[waharnum]

Two thoughts on the general issues raised by @JayPanoz:

• Starting points amidst the forest of standards: WCAG should be starting point for thinking about web accessibility considerations (not as familiar with UAAG, but I recognize those may be consequential here as well, since the reader has some positioning as a "user agent") - WCAG being specifically written into some accessibility legislation is a part of this, so it makes WCAG important in a lot of relevant contexts, especially educational settings. The other standards are generally meant to assist in fulfilling and supporting the goals of WCAG.
• Using WAI-ARIA: the WAI-ARIA Authoring Practices that are linked are my go-to for how to use (and not use) ARIA. There's a lot of old, outdated or incorrect information about ARIA on the web - this is the starting point for modern work with ARIA. As the authoring practices say, no ARIA is better than bad ARIA. As a general guideline, I think it is best to use native form elements for controls wherever possible and make sure they are following WCAG guidelines (controls have associated label elements, etc), then use ARIA sparingly as necessary to indicate elements like tabbed interfaces, menus, etc that don't have a native form element equivalent.

And thoughts on some of the specific questions:

Then let’s imagine you have an “about this book” display, exposing metadata for the publication. Surely this could be considered a footer with the role of contentinfo? Or am I missing something? And how do you even markup those contents so that they can make sense in the webpage context?

I can see arguments for including metadata in a footer or aside element, depending on the placement in the document. Using section might also be appropriate to set it apart.

Should you have a heading in the app’s interface? If so, how? Shall the book title you maybe have on top of the iframe be used?

Assuming you mean the the interface outside the iframe, I might consider something like this:

<h1>Reader App</h1>
<h2>{current title displayed}</h2>

Should “space” navigation be reimplemented in pagination? So instead of scrolling the doc, you progress one page like some Reading Systems already do?

Some of the accessibility issues common with infinite scrolling may be relevant here. It is probably good to have paginated navigation as an option.

Should “escape” hide the global menu/toolbar?

I wouldn't implement this myself, as the escape key to hide/show menu elements like this is not IMO a standard behaviour.

Should you attempt to reuse some keyboard shortcuts for some features e.g. increasing font-size or zooming fixed-layout? My worry is that once you start doing shortcuts, maybe you can go too far – i.e. same principle as ARIA role in the sense people tend to overuse it once they start using it.

I wouldn't recommend reusing browser-based keyboard shortcuts to control preference elements of the app's interface because this can cause confusion. I'd make sure the app is fully keyboard accessible as a starting point.

And finally there is some “tension” between the browser and the web app in UAAG. A quick example: settings profiles + export/import. Is the web app claiming responsibility of that given user settings in its UI? But then, what to make of browsers’ settings e.g. font-size, font-family, etc.? and OS settings e.g. dark UI → night mode?

In general any browser / OS settings (or something like a personal stylesheet, not that many use those) should win out (both technically and philosophically) over an individual web app. I'd rely on the browser / OS for this behaviour, and focus the web app's settings on the web app only.

---

Finally, general testing advice:

• regularly test the app's usability with keyboard-only (can all features be accessed with the keyboard, is the keyboard focus always visible, is the tab order logical); this is a good regular development practice that will catch many issues.
• learning to do basic screen reader testing is also good, lots of articles out there like this one: https://medium.com/that-conference/the-why-and-how-of-screen-reader-testing-8a92add2a609
• if at all possible, test with experienced users of accessible technology

[llemeurfr]

We are currently working on the accessibility of the Thorium desktop app based on Readium Desktop (the two are still intermingled today, will be correctly split later). And I agree that having a collaborative set of rules would be good, for web and desktop apps (plus mobile apps if used "as" desktop apps, I'm thinking about Chromebooks + Android app).

A proposal: start by exposing the choices we are making in our respective apps in a doc on the Readium Architecture space, with a proper doc structure (menubar, local library/shelf, user settings, reading experience ...), then discuss specific points where we're unsure about the way to go.