Figure out what to do with the DPUB mappings overlap with the ARIA Core spec, in the context of implementation differences.

Implementations of the DPUB Roles module are fragmenting based on some (recent?) implementation changes. In my opinion, the non AX API mappings in the DPUB ARIA Mapping are leading implementations to expose way too much cruft to the user.

For example, some Windows or Android AT users may now hear redundant ("appendix, appendix") or questionable ("qna") role descriptions. Even worse, some of these may be harmful to the understanding of the user interface. Do users know that the verbose "bibliographic reference" is actually a clickable link? [Update: previous "toc" example was updated to "qna" because based on test results, I'm not certain "toc" was ever spoken to a user.]

Background

When the DPUB working group published its ARIA roles module, the DPUB and ARIA groups met years ago and, as I recall, agreed to the following:

1. Each DPUB role would map to a superclass ARIA role. Complete. (For example, doc-acknowledgments has a superclass role of landmark)
2. Implementations should map these as synonyms to the core ARIA role. Completed several years ago in Safari/WebKit, Firefox/Gecko, and Chromium/Blink, though Chromium and Gecko have either diverged since then or mapped them differently after the initial WebKit implementation; more on this below.

• Note: The stated goal at the time of mapping some of these DPUB roles was that EPUB could use them as both functional structural elements (for EPUB renderers to use), while retaining some fallback role that would be relevant for accessibility where appropriate. As an example, the biblioref would be exposed as a regular "link" to screen reader users (similar to how sighted readers perceived it) but the EPUB renderer could cross-reference this element somewhere else in the UI.

3. DPUB WG and ARIA WG were then going to discuss which DPUB roles should be brought back into the Core ARIA spec as non-prefixed roles that should be conveyed more specifically to users of assistive technology. For example everyone agreed that doc-chapter should result in a new chapter role for the ARIA spec. I don't think this last step ever happened. It may have been that the ARIA WG was focused on HTML Parity and de-scoped the DPUB convergence, or there may have been some other reason.

Since that time, Firefox and Chrome have updated to expose the DPUB role descriptions mostly in line with the suggested screen reader output from DPUB (Microsoft Excel download).] @avneeshsingh and @GeorgeKerscher recently reached out to ask if Safari/WebKit would match the Chrome and Firefox implementations. While it would be a relatively simple technical change to do so, I think implementing the whole list would result in some unfortunate user interface changes, including aforementioned masked links, redundancy, and verbosity.

There are good and bad examples. For example, some Windows or Android AT users will now hear "chapter" on chapter roles (good) but the questionable ("qna") role description on a "Questions and Answers" container with a doc-qna role. Even if this latter role description was expanded in the implementation to the DPUB recommended "Questions and Answers" role description, it would be verbose and redundant, because the first element in most "doc-qna" sections is probably going to be a heading labeled "Frequently Asked Questions" or something similar. A user might hear "Questions and Answers, Frequently Asked Questions, heading." Some now hear, "qna, Frequently Asked Questions, heading." [Update: previous "toc" example was updated to "qna" because based on the DPUB test results, Talkback on Android does speak the "qna" role description. Also based on DPUB results, I'm not sure "toc" was ever spoken to a user.]

More concerning are the link examples, where the role description potentially masks some interaction hint for the user. DPUB suggests the "doc-biblioref" role should expose a role description of "bibliography reference" so users may hear "bibliography reference, foo" instead of terse and predictable "link, foo." I doubt most users would immediately understand that "bibliography reference" means it's a clickable link, and even if they did, it increases the cognitive load for little or no user benefit. At default verbosity settings, there are eight syllables in "bibliographic reference" before a text-to-speech user would hear the contents of the link. I have the same concern for other link subclass roles such as doc-noteref and doc-glossaryref.

DPUB Role Descriptions that should be Conveyed to Users of Assistive Technology, IMO

I'd first propose the DPUB and ARIA stakeholders agree on a list of role descriptions (including the non-controversial chapter role) that should be conveyed to users of assistive technology. WebKit could expose these to the AX API to match the other implementations.

Optionally, the ARIA Working Group should whether consider that list (as a whole or individually) should be incorporated as core ARIA roles. DPUB's doc-chapter would then reference the new ARIA chapter role as its superclass, rather than the more general landmark role. This would result in implementation changes to all engines, and would allow authors to use role="chapter" rather than the more verbose and dpub-specific role="doc-chapter".

doc-backlink may allow some interesting behavioral features (so the role itself should definitely be considered as a core role), though I'd argue that UIA's localized "backlink" may not be the right string to send to the user as a role description.

DPUB Roles where the role description may NOT need to be conveyed to Users of Assistive Technology

I expect this may be a more controversial list, but I'll try to explain my thought process as a starting point. To be clear, I'm not suggesting that the roles not be exposed to the Accessibility APIs. They already are. Instead I'm suggesting that the AT end user (such as a screen reader user) doesn't need to hear about these differences. In the same vein, a sighted reader likely won't perceive any visual difference between these sections or types of elements.

Certain container role descriptions are redundant to convey to users.

I just picked up 5 or 6 print books off my desk and bookshelf. In all cases where these sections were available, the results were consistent.

• Appendices all started with a title that included the word "Appendix." For example, adding a role description here would have conveyed "Appendix III" as the redundant "Appendix III, appendix" or "appendix, Appendix III"
• Bibliographies all started with a heading that contained the word "Bibliography" or something equivalent like "References" or "Notes [sic]" (There is a minor semantic distinction between a DPUB "Notes" section and a "Bibliography" but in this print book, the publisher chose to combine them and title the section "Notes." I think it's a reasonable editorial decision on behalf of the publisher, and I don't believe it causes any reader ambiguity.)
• Acknowledgements were all titled Acknowledgements.
• In the one book that had "Parts", the Parts were titled "Part 1" etc.
• In the one book that had Author Notes, the title was "A Note About the Author" [Update: This example may be irrelevant. DPUB has a doc-endnotes role but not a doc-authornotes role.]
• In the one book that had a Colophon, the title was "Notes about the Facsimile Version." Not today, but in past experience I do recall seeing Colophons that were titled "Colophon" and more frequently I recall seeing untitled colophons (no heading)… Regardless, the context of the colophon is clear to sighted readers with or without a visible heading. I'd also argue that the context is clear to screen reader users without the invisible-but-audible role description.

Certain other non-container DPUB role descriptions are unnecessary to convey to users.

There was not an "abstract" section in any of the books I picked up, but I think it's similar to colophon, in that the context is clear, regardless of whether the publisher chooses to visibly include a title labeled "Abstract." If the publisher doesn't choose to burden a sighted users with an unnecessary title, why would we want to subject screen reader users to one in the form of a role description?

To reference an existing core role description, "list item" usually isn't spoken by AT because doing so would be annoying, so there is practically no difference whether the engines send longer localized strings for more specific list item subclasses to the API or not, since each would be a subclass of listitem. I don't have a strong preference, but we typically wouldn't make an academic code change that results in no functional or perceptual user benefit.

I don't recall ever seeing a "dedication" labeled with a title, but the context is always clear. Why would a screen reader user want to hear "dedication, For my daughter" or "For my daughter, dedication" when the content "For my daughter" is immediately clear on its own?

This is an incomplete list, but I'm hopeful it's shows why WebKit engineers did not choose to convey most of these role descriptions to end users. (Honestly, I'm surprised that Chromium and Gecko engineers didn't question these mappings at the time. There may be a great reason that I missed.) In any case, I think it's enough to start the discussion and I look forward to learning from you all.