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

[cookiecrook]

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.

[cookiecrook]

@aleventhal @joanmarie @mattgarrish @cyns @jnurthen @georgekerscher @avneeshsingh @jcsteh @TzviyaSiegman @asurkov Apologies if I've overlooked anyone who is or was a stakeholder in these.

[cookiecrook]

Noting that I made a several revisions to the issue description above. They were mostly editorial (typos etc), but I've added a few specific notes (labeled "Update:") anywhere the errata/correction was more substantive.

[jnurthen]

see https://github.com/w3c/dpub-aam/issues/11

[pkra]

To add from the perspective of content production, after having been an early adopter of DPUB ARIA. While the DPUB ARIA roles were easy enough to implement, I've found the benefits of these roles for users to be quite limited. Of course, that's always a chicken and egg problem with AT providing affordances for new roles but after 5 years it feels like a good time check.

From my recollection (and a quick test) both JAWS and NVDA mostly ignore the roles. When they don't, it's not clear if it's for the better. For example, NVDA adds elements with roles subclassing landmark to the landmark list; this makes sense but can get quite noisy. (The spec's suggestion to make footnotes aside elements doesn't help either but at least https://github.com/w3c/html-aam/pull/350 can help with that.)

I do think most of DPUB ARIA can be useful but maybe the information would work better as a sort of annotation of roles, a kind of "structured role description". Incidentally, I would find that particularly helpful for the link roles @cookiecrook criticized since this kind of link content can be very short and ambiguous (e.g., a footnote link or a bibliographic reference can just have 1 as text content, frequently in rapid succession inside a lengthy paragraph). I suspect a structured method for annotating these elements is better than, say, adding visually hidden hints (as we currently do).

To pick another example:

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?

This is perhaps far-fetched but at least from real life: there's a US-based mathematics journal I work with which regularly publishes articles in French. I can easily imagine a non-English user following a DOI to such a paper from, say, another paper's reference list. Like most DOIs, this brings them to a page that includes the title and abstract in French - yet the rest of that page would be in English. Since the French equivalent for abstract would be résumé, even the heading content might not be a great help. Providing some form of structural information could help users here.

Anyway, even after replacing English and French with less related languages, I admit this might not be the greatest example and I'm not arguing in favor of this particular role (or any DPUB role for that matter). I only mention it because I do think there's a lot of structural information in publishing workflows that users would benefit from if we found a way to make it available. In fact, there's far more than what's in DPUB ARIA (unsurprisingly, since DPUB ARIA mostly reproduces the older epub vocabulary).

Looking forward to the deep dive.

[mattgarrish]

I think this statement could use some clarification first:

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.

This wasn’t the motivation in bringing the roles into ARIA. That’s more of a history lesson in how EPUB’s type attribute failed for accessibility. The idea was that it would provide accessibility while publishers were using it for other means (pop-up footnotes), but it never materialized. The push for the past five or six years has been to unwind this perception – partly by properly creating roles for ARIA and partly by slowly retiring the type attribute and discouraging reading systems from developing off it (not that they did in any meaningful way). It’s really only for publishers’ internal workflow use these days. Also, now that EPUB is fully in W3C, the idea of building non-web functionality off a separate EPUB-only attribute is basically dead.

That said, I think there’s always room for discussion about how roles should be exposed/announced. I’ve also been getting asked about this since we started publishing the DPUB-ARIA 1.1 drafts, but the mappings are not my area of expertise (as you’ll probably recall, Rich did most of the work creating the mappings document for us). Publishing is a big and messy space, so while you can find common naming patterns, they rarely hold up everywhere. Having a consistent set of semantics to identify the parts of a publication has been central to accessible publishing going back before EPUB to DAISY talking books.

I expect you’ll find more openness on the publishing side to discussing the aspects of your proposal like what should be announced for roles rather than not having them announced at all or using their superclass roles to identify them. I can’t speak to why the difference exists, but I think I can safely say from discussion with folks on the publishing side that announcing the superclasses is viewed as the less helpful option, which is why they’re pushing to have the publishing names announced.

My understanding from going through the 1.0 process is that the mappings are intended only to expose the roles, though. How they’re announced, and whether they’re announced, is for API and AT devs to determine, with users being able to customize their playback as well. You mentioned listitem, for example, but I can’t find anything in the core AAM mappings that says not to announce it.

More to the point, I’m trying to understand if this is an issue that involves changes to DPUB-AAM, or if this is a question that is more general to the user experience. I opened the linked pull request in DPUB-AAM not expecting it will change the AX mappings, but because I was told the description fields are not necessary to specify anymore and are removed in ARIA 1.2. Is that correct in your view, @cookiecrook?

I expect where we’re going to find the most agreement is in adding roles to ARIA core. I know we discussed having chapter, at least, in the core when we did the 1.0 release, but it was decided not to rush adoption. If the suggestion at the time that the doc-* roles would simply become aliases in the future if roles were integrated remains true, then I expect you’ll get support from publishing to push for adoption.

But this message is getting very long, so I'll cut myself off here. I expect @GeorgeKerscher, @avneeshsingh, @clapierre, @gregoriopellegrino and others will have more to say.

[clapierre]

Totally agree with what @mattgarrish wrote above.

In terms of implementation our Global Certified Accessible (GCA) program which certifies publishers EPUBs as being accessible requires the use of DPUB ARIA roles be added to all relevant sections within the book. We have over a dozen publishers who have passed certification including some of the larger US publisher and the list is growing with an another dozen or more in the works to get fully certified. Not to mention our certification program is expanding where eBound Canada is using our program to certify Canadian publishers to also adopt the DPUB ARIA roles. For a list of publishers who have passed certification and are adding these roles to every EPUB coming off their production pipelines you can find that on our "Certified Publishers" webpage.

Publishers are already including these roles in their EPUBs which are being published now, so that part of the chicken & egg problem is solved, the content is there now, so all we need is AT to expose this information in a user friendly and customizable way.

As far as incorporating some of the DPUB aria roles into core, it depends on how it is implemented as I would not want to see those doc-* roles be dropped and instead be alias's to the core roles. I would not want to inform the publishers they have to say change their process for role="doc-chapter" to just role="chapter" but keep role="doc-acknowledgments" if that doesn't make it into core. So if there are aliases as Matt suggested then the author can use either this would fine.

[cookiecrook]

@clapierre wrote:

I would not want to inform the publishers they have to say change their process for role="doc-chapter" to just role="chapter" but keep role="doc-acknowledgments" if that doesn't make it into core.

For compatibility reasons, I would not expect role="doc-chapter" to ever be removed from implementations. Assuming the chapter role was brought into the core spec, it would just become an option to use either chapter or doc-chapter interchangeably. So the publisher could continue using doc-chapter indefinitely, or update to chapter at their discretion. End-user result should be the same.

[cookiecrook]

@mattgarrish wrote:

I’m trying to understand if this is an issue that involves changes to DPUB-AAM, or if this is a question that is more general to the user experience. I opened the linked pull request in DPUB-AAM not expecting it will change the AX mappings, but because I was told the description fields are not necessary to specify anymore and are removed in ARIA 1.2. Is that correct in your view, @cookiecrook?

If I understand the question, I think whether there is a DPUB-AAM change depends on the outcome of the discussion. If we agree that there are a subset of DPUB roles that are unnecessary to explicitly convey to AT users via role description, then yes, I would expect DPUB-AAM to change to reflect that. But there would presumably be no DPUB-AAM change related to the ones that should should be brought into the Core ARIA spec, as with chapter.

[TzviyaSiegman]

Thanks for the question @cookiecrook. @mattgarrish provides great background.

I need a little time to think about this. Without giving this more than a few minutes thought, the most valuable roles to have spoken are chapter and subtitle. I would love to get feedback from people using AT.

[aleventhal]

All of the roles are important when you're authoring the content.

[mattgarrish]

I think whether there is a DPUB-AAM change depends on the outcome of the discussion.

Right, my question is somewhat tangential to this thread in that the AXRoleDescription fields were all removed from the ARIA 1.2 specification and replaced with a note that says:

User agent should return a user-presentable, localized string value for the AXRoleDescription.

I don't believe those fields dictate what is to be announced, but I understand that is the perception of some for why the publishing roles are announced differently.

I noticed the two new additions (doc-pageheader and doc-pagefooter) don't have an AXRoleDescription field, so I'm assuming it's safe to remove the others, but wanted to run it by you here since we're discussing this anyway. I'd like to merge that pull request but don't want to do something that will have to be undone by this issue.

[jnurthen]

Discussed in ARIA WG - propose a meeting for a 9am pacific deep-dive on a Thursday in the new year? Please let me know your availability. @aleventhal @joanmarie @mattgarrish @cyns @GeorgeKerscher @avneeshsingh @jcsteh @TzviyaSiegman @asurkov

[aleventhal]

Sounds good. I should be available, with the possible exception of the first week of January.

On Thu, Dec 2, 2021 at 1:26 PM James Nurthen @.***> wrote:

Discussed in ARIA WG - propose a meeting for a 9am pacific deep-dive on a Thursday in the new year? Please let me know your availability. @aleventhal https://github.com/aleventhal @joanmarie https://github.com/joanmarie @mattgarrish https://github.com/mattgarrish @cyns https://github.com/cyns @GeorgeKerscher https://github.com/GeorgeKerscher @avneeshsingh https://github.com/avneeshsingh @jcsteh https://github.com/jcsteh @TzviyaSiegman https://github.com/TzviyaSiegman @asurkov https://github.com/asurkov

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/aria/issues/1643#issuecomment-984885490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQAZXVDRWSF4B5XNIIG3LUO624RANCNFSM5H3X32WQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[jnurthen]

Proposed date - Jan 13, 2022 - 9AM pacific (1700 UTC)

[aleventhal]

That works for me.

On Thu, Dec 2, 2021 at 2:17 PM James Nurthen @.***> wrote:

Proposed date - Jan 13, 2022 - 9AM pacific (1700 UTC)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/aria/issues/1643#issuecomment-984926682, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKQAZSG76NXME4UBVTAIJTUO7A3ZANCNFSM5H3X32WQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[mattgarrish]

The proposed date works for the publishing folks I've talked to.

[jnurthen]

great - I'll create the invite

[jnurthen]

https://www.w3.org/events/meetings/f0174998-3f13-4942-904a-8a3881741cda

[jcsteh]

Proposed date - Jan 13, 2022 - 9AM pacific (1700 UTC)

That's 3AM for me, so I unfortunately won't be able to attend.

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).]

I'm probably missing something here, but as far as I can see, Firefox doesn't expose any role descriptions for DPub roles on any platform. It exposes the semantic info (e.g. xml-roles for IA2), but not localised role descriptions. Are we talking about something else here? What am I missing?

I see that the UIA mappings do recommend exposure of localised control types and localised landmark types. Firefox doesn't support UIA natively yet, so that isn't relevant to Firefox.

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.

My personal opinion is that localised role descriptions should never be exposed for standardised roles. That's what we've upheld for IA2. This way, the AT can make the decision based on the semantic role and potentially other context. In contrast, if a role description is exposed, an AT has to report it; it can't reliably make any other decisions. Unfortunately, the UIA mappings have been defined such that this probably isn't an option now.

[cookiecrook]

@jcsteh wrote:

I'm probably missing something here, but as far as I can see, Firefox doesn't expose any role descriptions for DPub roles on any platform. It exposes the semantic info (e.g. xml-roles for IA2), but not localised role descriptions. Are we talking about something else here? What am I missing?

I may have misinterpreted some data from @georgekerscher and @clapierre from their test results. There is a column called "inspector (Firefox on Windows)" that seems to indicate the "doc-*" roles are exposed, but in other columns, it does appear that the role descriptions are based on standard core ARIA parent roles.

[aleventhal]

I agree with Jamie that the ideal is for the semantic role only to be exposed, and the AT to handle it. On ATK/IA2, this is what Chrome does, via the xml-role object attribute as suggested by Jamie. On Android and Mac, Chrome exposes a role description, because of the concern that it can take a long time for updates to those ATs to get into the hands of users -- admittedly a non-ideal shortcut.

[cookiecrook]

On Android and Mac, Chrome exposes a role description, because of the concern that it can take a long time for updates to those ATs to get into the hands of users -- admittedly a non-ideal shortcut.

We're wandering into implementation differences here. Default role descriptions on Mac aren't typically provided by the AT because multiple Assistive Technologies use the same frameworks. If I understand Aaron, he's alluding to the fact that some core role descriptions are built into the system frameworks, including AppKit, but also WebKit. Native apps have always had the ability to override the framework-provided role descriptions or create custom ones.

So IMO, it's reasonable to standardize the web role descriptions for DPUB, but the Rec should be a non-binding MAY (or an informative Note) to allow for small variants in platform UI and localization consistency.

[aleventhal]

Looks like the role descriptions Chrome exposes on Mac for DPUB-ARIA roles are incorrect, it's just the role string itself. Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1277238

On Android, Chrome exposes the role description correctly.

[aleventhal]

Here are the roles I see as useful for Google Docs in the near term: doc-endnote, doc-endnotes, doc-footnote, doc-pagebreak, doc-pagefooter, doc-pageheader, doc-subtitle, doc-toc

[TzviyaSiegman]

I think doc-abstract, doc-endnote(s), doc-toc, and doc-subtitle are extremely valuable. I have not yet discussed with other members of Publishing.

[aleventhal]

I'd like to suggest that the doc-prefix is useful on the roles and should not be removed.

• It helps understand that they are conceptually related to documents. It makes all of ARIA to understand when we have a giant bag of roles. I think we should discuss the pros and cons of moving roles into the ARIA spec. To me, it makes ARIA more comprehensible to have some of our semantics grouped or organized, even in a separate document. But this is not a super strong opinion.
• For implementation simplicity, I'd prefer that we don't have new synonyms for roles. We do this for presentation/none, but I don't see a major benefit in doing this again.

[pkra]

I want to add something tangential I didn't get to on the call.

From my (admittedly limited) user testing, it appears problematic that a lot of the dpub roles are landmarks. On a regular webpage (e.g., a full text journal article displayed on publisher website) these landmarks can add a lot of noise to landmark navigation, making the "regular" page landmarks hard to access. [In a dedicated epub reading application, that's less of a problem if the app UI is outside the webview. Though, for completeness, I've also seen no strong benefits there. Landmark navigation appears to be less useful to users; I suspect because most dpub landmarks typically end up in separate HTML files.]

Similarly, I find both doc-noteref and doc-biblioref compelling (and could honestly use a few more like them) because the link content for such cross-references is often extremely short and might not even be understandable in context (e.g., a footnote marker is commonly just a superscripted digit or dagger and may appear very near a biblioref having the same digit as link content). But I agree with @jcraig that it's problematic if such links were to get a role that is both unfamiliar and long (though I don't think any AT does that right now). Nevertheless, I do see a benefit when the content is too short to make sense otherwise and wished AT could expose the "full" role sometimes (instead of authors providing screenreader-only text to disambiguate).

Long story short, I'd be very interested to hear what others have found through user testing (and feedback). If there are similar experiences, it could be helpful to add guidance for AT. If not, I'd be thrilled to not worry about this anymore.

[aleventhal]

Re: doc-noteref, I agree it's important and forgot to mention it. I think we need more guidance for doc-noteref. IMO it can be used with aria-details to point to the doc-endnote/doc-footnote. It doesn't necessarily need to act as a link. It might not be one. For example, in an editor like Google Docs.

[cookiecrook]

I expect this to be somewhat controversial; no one will agree with every suggestion here. I took an action to move this along, so here goes a first pass of the whole DPUB role list.

I made a more thorough case above (first post), against several of the redundancies... but mentioning a few here again for context, albeit briefly.

Map the following to new roles in ARIA Core, along with a unique role description.

These provide clear utility IMO. When/Whether the role description would be voiced is still up to the AT.

• doc-chapter
• doc-pullquote
• doc-subtitle
• doc-example
• doc-footnote

Leave the following listitem-based subclass roles mapped to listitem.

List item role descriptions typically aren't voiced anyway (to avoid redundancy), so mapping a role description for each unique type isn't useful anyway:

• doc-biblioentry
• doc-endnote

Leave the following link subclass roles as synonyms of link

SR Users have "muscle memory" associated with link representation. The proposed role descriptions (e.g. "biblography reference") are tediously verbose and arbitrary. Keep the terse "link" role description as is... Leave these roles as synonyms of the superclass "link" role.

• doc-biblioref
• doc-glossref
• doc-noteref

One possible exception link subclass role:

• doc-backlink: I think this should still use a standard "link" role description, but inlcuding a new role could allow AT-based 'back' functionality. I'm leaning against including though since overriding the history stack with an AT-specific 'back' solution would out AT uses and conflict with WPDP §2.9.

Irrelevant container role descriptions

Leave as a synonym of superclass ARIA core role. The reader determines any necessary context from included headings, for example, an Appendix usually includes the word Appendix in the title. Hearing and additional role ("Appendix 1, Appendix") descriptions is redundant and burdonsome for AT users.

• doc-qna
• doc-abstract
• doc-acknowledgments
• doc-afterword
• doc-appendix
• doc-bibliography
• doc-colophon
• doc-conclusion
• doc-glossary
• doc-dedication
• doc-endnotes
• doc-epigraph
• doc-epilogue
• doc-errata
• doc-foreword
• doc-introduction
• doc-part
• doc-preface
• doc-prologue

Unsure about the rest. Some thoughts follow each.

• doc-cover: is this useful enough to subclass image and make sure SR users know it's a different type of image? e.g. role description: "cover image"
• doc-credit: Is there some cross-ref value or index-ability benefit to referenced credits? Why not use <cite>?
• doc-credits: same as above, but this is the redundant container.
• doc-pagebreak: I'd expect page breaks are print artifacts, and there's no reason to annoy the reader by interrupting a sentence to speak a role description for page break, but there may be some value in a page break sound icon.
• doc-index: standardized index could provide some unique navigational utility.
• doc-notice: suggest review. This is a subclass of "note" but the prose indicates it's more important, like a warning.
• doc-pagelist: similar to index, but probably less utility, as most would use the built-in pagination features of the e-reader.
• doc-tip: I've usually seen these with an icon (lightbulb or similar) that could have "Tip" as the alt text, but acknowledge there may be some value to ignoring these during a read-all mode or hearing the content bracketed.
• doc-toc: Tables of Contents are obviously important in the e-reader context, but the feature is also built-in there. Is this so common outside the e-reader case that we need a "TOC" in the open Web?

[avneeshsingh]

We are working with publishing community to identify more important and frequently used DPUB ARIA roles. Hopefully we will be able to share our list sometime next week. It is good thing that line between publications and web content is becoming blur. As per the discussions up to now, I can say that roles for actionable items, for navigation and for important structural items are surfacing more in the list. But it would be good to wait for finalization of the list.

[aleventhal]

@cookiecrook thanks for this.

What web use cases are we handling? Here are some worth discussing:

• Screen reader navigation on the (this is the obvious one)
• Editing/publishing, where the author may want to know what format something is. Perhaps for these, it's good enough to use aria-roledescription.
• Braille embossing. We may not care about this use case, but worth discussing. From memory in the Braille pushing business, the following listed in @cookiecrook 's comment have specialized Braille formats: doc-bibliopgraphy, doc-glossary, doc-index, doc-toc, doc-endnotes). We should consider it.

Regarding doc-pagebreak, it's useful to know what the page break is so that it can be ignored in the AT output. The AT output should sew together the text before and after the page break (skipping over headers/footers as well). It's also potentially useful for "move by page" commands. @cookiecrook , I didn't see doc-pageheader and doc-pagefooter listed in your comment.

For roles mapped to link, we might consider using aria-details to point to the in-page referenced content instead. This allows the role to remain semantic when it is exposed to the AT. I don't know that it necessarily makes sense to expose these things as links ... I'm guessing that was the only way we had of referencing the other content at the time the mapping was introduced.

[avneeshsingh]

The Publishing CG has identified the more important DPUB ARIA roles according to the following criteria:

• Actionable roles
• Navigation roles
• Structural roles which are important for the print disabled readers, but it may not be easy for them to distinguish these from other text. often these semantic elements are identified in the text by their graphical characterizations (e.g., superscripted number for footnote reference, larger, bold/italic text for pullquote, etc.) and thus assistive technologies have no reliable way to identify the content in a way other than with the support of the defined roles.

Following is the list:

More important roles

Link identification roles.

The print disabled reader need to know the destination of the link before activating it. doc-backlink, doc-biblioref, doc-glossref and doc-noteref.

Navigation roles.

Navigation is very important for users of AT. doc-toc, doc-pagebreak and doc-pagelist (WCAG 2.2 has success criteria for pagelist and pagebreaks)

Notes.

Usually there is no explicit heading structure to identify them. Footnotes can also appear inline, which makes it difficult to understand the text. doc-endnotes and doc-footnote

structural components

doc-chapter, doc-part, doc-doc-abstract, qna, doc-pullquote and doc-subtitle

Content notifications

doc-tip and doc-notice

Most of the other DPUB ARIA roles can be usually identified by the print disabled readers from structural elements like headings with relevant names or from the content itself. The following list includes all such roles along with some roles which may be important for production and distribution, but not so important for end users.

Other roles

Structural components

doc-glossary, doc-introduction, doc-prologue, doc-appendix, doc-bibliography, doc-conclusion, doc-example, doc-cover, doc-dedication, doc-epilogue, doc-foreword, doc-preface, doc-afterword, doc-acknowledgments, doc-colophon, doc-credit, doc-credits, doc-epigraph, doc-errata

Navigation roles

doc-index. The index is the only navigation role which is not included in the list of more important roles. This is because index is usually on a separate XHTML file or set of XHTML files, it is usually well defined with a heading, and the search functionality of reading systems provides an alternate way to find the relevant content.

In order to achieve the important goal of aligning with web technologies and reducing the use of EPUB specific attributes, we have de-emphasized the use of EPUB-type in the favor of using DPUB ARIA roles. Therefore maintaining DPUB ARIA roles for publishing use case will be crucial for this alignment.

[jnurthen]

@cookiecrook can you please review the comments from @avneeshsingh

[cookiecrook]

@avneeshsingh Can you edit your comment above and try to make the formatting more clear with Markdown? For example, It's not clear how the bulleted list relates to the rest. Was "Actionable Roles" intended to list the roles associated with that section? You've got a Navigational Roles bullet near the top, as well as two other Navigational Roles sections (should those be headings?) with additional comments. What is the ask re: the "content notifications" section?

I understand some of the comments but not all. If you prefer, I can try to edit and reformat your comment as I think it may be intended. I'll address some of the comments that seem more clear, and come back to the rest once those edits are in. Thanks.

[cookiecrook]

Most of the other DPUB ARIA roles can be usually identified by the print disabled readers from structural elements like headings with relevant names or from the content itself. The following list includes all such roles along with some roles which may be important for production and distribution, but not so important for end users. Structural components: doc-glossary, doc-introduction, doc-prologue, doc-appendix, doc-bibliography, doc-conclusion, doc-example, doc-cover, doc-dedication, doc-epilogue, doc-foreword, doc-preface, doc-afterword, doc-acknowledgments, doc-colophon, doc-credit, doc-credits, doc-epigraph, doc-errata

I am interpreting this to mean that DPUG WG agrees with my point above that there is no need for a redundant localized "role description" to be exposed to AT through an Accessibility API.

However, I think the request here is that the role should still be programmatically distinguishable. For example, in the Apple AX API we may use an AXSubrole (~"AXDocumentBibliography"), but keep the AXRole ("AXGroup") and AXRoleDescription ("group") generic like the superclass role. Is that the intention? Seems reasonable to me.

[cookiecrook]

Navigation roles. Navigation is very important for users of AT. doc-toc, doc-pagebreak and doc-pagelist (WCAG 2.2 has success criteria for pagelist and pagebreaks)

I agree that navigation is important. All EPUB readers I'm aware of already expose ways to quickly get to the table of contents "doc-toc" if provided. I'm not sure how the doc-pagelist differs. Are you asking that these be subclasses of landmark so that they can enable landmark-style navigation? If not, what is the mapping request or functionality intention?

However, page breaks (doc-pagebreak) themselves don't seem meaningful navigational elements. Aren't these mapped as a subclass of the "separator" role similar to an <hr> element? Maybe the DPUB Working Group is asking for a way to enact general pagination in the Web, similar to the native pagination that is already available in EPUB readers? Again, I'm not really sure what the mapping request or functionality intention is from this comment.

[cookiecrook]

The print disabled reader need to know the destination of the link before activating it.

A non-print-disabled reader doesn't usually know the destination of a link before activating it. Do they? If not, what is different about the print-disabled reader use case that justifies exposing additional information through AT alone?

[avneeshsingh]

@cookiecrook I have added headings to my comments. the list provided by me was action item from our call held on Jan 13. The objective was to identify more important DPUB ARIA roles for providing examples in ARIA Authoring Practices. At this point of time the list is not identifying the roles which should have their own class and which should be mapped to a super class.

[pkra]

A non-print-disabled reader doesn't usually know the destination of a link before activating it. Do they?

They do. For example, footnote references will usually be superscript numbers or abstract symbols (frequently via CSS or font-features, or just plain unicode). Similarly, bibliographic references can have just [1] as content (with brackets often realized as generated content). These two in particular easily show up side-by-side (a footnote providing context for a citation), which can cause confusion for non-visual users.

Additionally, color is frequently used to distinguish different types of cross-references (not just those covered by the current set of roles).

(Somewhat off topic: in the context of epub, footnote references are particularly weird because many reading systems have devised pop-up effects which pull in the footnote content. This turns a simple link into a complex widget outside author control. To make it worse, some reading systems easily break footnote content because they render the pop-up outside the page context.)

[cookiecrook]

@avneeshsingh wrote:

At this point of time the list is not identifying the roles which should have their own class and which should be mapped to a super class.

Does this mean we should consider this issue non-actionable at this time, and await further action from DPUB WG? Even with the headings changes, I do not understand your post. For example, why are there multiple sections labeled "Navigational Roles" and multiple sections labeled "Structural Components" and what should we do with this information?

[cookiecrook]

A non-print-disabled reader doesn't usually know the destination of a link before activating it. Do they?

@pkra responded

They do. For example, footnote references will usually be superscript numbers or abstract symbols (frequently via CSS or font-features, or just plain unicode). Similarly, bibliographic references can have just [1] as content (with brackets often realized as generated content). These two in particular easily show up side-by-side (a footnote providing context for a citation), which can cause confusion for non-visual users.

Generated content such as brackets should already be accessible in modern browsers, so a screen reader speech or braille user already has access to that link title difference that conveys the contextual inference to a sighted user.

Additionally, color is frequently used to distinguish different types of cross-references (not just those covered by the current set of roles).

IMO, that would be a bug in the EPUB reader implementation.

(Somewhat off topic: in the context of epub, footnote references are particularly weird because many reading systems have devised pop-up effects which pull in the footnote content. This turns a simple link into a complex widget outside author control. To make it worse, some reading systems easily break footnote content because they render the pop-up outside the page context.)

If the EPUB reader implementation overrides the default link behaviors, it should also override the markup/accessibilty and convey those with aria-popup, Correct?

[cookiecrook]

For clarity, I think screen reader users on Mac with default settings for example would currently hear these as "link, [1 foo]"… The proposal for a new role description would change this to the significantly more verbose "bibliography reference, [1 foo]" which:

• buries the important link title behind an additional seven syllables of role description
• presumably should have some longer braille role characters tool, using more cells on already limited displays.
• obscures the fact that this element is a link, or at minimum, increases the cognitive load of understanding that it's a link (depending on context and intention, screen reader users may only listen to the first phoneme "l…" in "link" before moving on)

Those are some examples of negative screen reader user interface aspects I'm attempting to avoid.

[pkra]

Generated content such as brackets should already be accessible in modern browsers, so a screen reader speech or braille user already has access to that link title difference that conveys the contextual inference to a sighted user.

Sure. On the one hand, that's just one example of many. On the other, default AT settings will likely gobble up the brackets, making it cumbersome for non-visual users to get the benefits visual users have.

IMO, that would be a bug in the EPUB reader implementation.

I was not referring to EPUB reading systems -- authors do this because they know their content is confusing otherwise.

If the EPUB reader implementation overrides the default link behaviors, it should also override the markup/accessibilty and convey those with aria-popup, Correct?

Sorry for bringing up EPUB. In any case I'd rather not actively encourage EPUB reading systems to mess up author content; it's a bad enough environment as is.

[pkra]

For clarity, I think screen reader users on Mac with default settings for example would currently hear these as "link, [1 foo]"… The proposal for a new role description would change this to the significantly more verbose "bibliography reference, [1 foo]" which:

Just to repeat my much earlier comment: I agree that this would be a bad default. (And to complete: I also find the roles that are exposed as landmarks problematic.)

What I'm trying to point out that I find it equally problematic to just drop this information (as was suggested earlier). Instead, we should recommend that AT find way to use this information to the benefit of its users.

For example, JAWS (by default, I think) announces links within a document as "in page link" (or something similar). I'm going to guess that's not due to excessive negative user feedback.

An option along the same lines could be beneficial to users. I could even see AT wanting to decide dynamically if it wants to provide additional information (e.g., a doc-biblioref with "1" might be treated differently as one with "Nurthen, et al").

[pkra]

FWIW I also feel that the entirety of DPUB roles touches on broader topics that have come up on the calls in the last year or so (multiple roles, better descriptions for roles etc). I think this might be an opportunity to think a bit bigger than just the immediate problem of AX API mappings for DPUB roles.

[avneeshsingh]

@cookiecrook I have inserted couple of more headings. Is it better now? As I mentioned earlier, Publishing CG has identified more important roles for adding examples in ARIA authoring practices, it was the action item from Jan 13, 2022 call. If we want to figure out which roles should have super class and which not then it will be a separate discussion.

[avneeshsingh]

"A non-print-disabled reader doesn't usually know the destination of a link before activating it. Do they?"

@pkra has already explained it very well. I would like to add that a print disabled reader needs to maintain the focus more than a visual reader. It is comparatively easy for a visual reader to click on a link move to the destination and if he/she realize that they have clicked on a wrong link, they can easily return back to original location. But it is challenging for a person with tunnel vision and screen reader user to land on an unknown destination and then get back to exact location from where they started. This is why it is essential for a print disabled user to know where the reference is going.

[cookiecrook]

@avneeshsingh wrote:

@cookiecrook I have inserted couple of more headings. Is it better now?

I'm still not certain how to move forward with the comments. Maybe you could confirm or deny my specific questions above? Here's one.

@avneeshsingh wrote:

Most of the other DPUB ARIA roles can be usually identified by the print disabled readers from structural elements like headings with relevant names or from the content itself. The following list includes all such roles along with some roles which may be important for production and distribution, but not so important for end users. Structural components: doc-glossary, doc-introduction, doc-prologue, doc-appendix, doc-bibliography, doc-conclusion, doc-example, doc-cover, doc-dedication, doc-epilogue, doc-foreword, doc-preface, doc-afterword, doc-acknowledgments, doc-colophon, doc-credit, doc-credits, doc-epigraph, doc-errata

@cookiecrook replied:

I am interpreting this to mean that DPUG WG agrees with my point above that there is no need for a redundant localized "role description" to be exposed to AT through an Accessibility API.

However, I think the request here is that the role should still be programmatically distinguishable. For example, in the Apple AX API we may use an AXSubrole (~"AXDocumentBibliography"), but keep […] AXRoleDescription ("group") generic like the superclass role. Is that the intention? Seems reasonable to me.

This may be ideal because it'd allow e-readers, scripts, and AT the ability to offer additional user navigation (e.g. "Jump to Bibliography") to these structural elements, without penalizing the user with additional high verbosity: "Bibliography, bibliography group, heading level 2, Bibliography"

[cookiecrook]

Moving to 1.4 until getting relevant responses from DPUB.

[cookiecrook]

I'm going to move forward with a PR that exposes the programmatic platform roles (for example, as an AXSubrole on Mac) but without the verbose role descriptions on the disputed ones. This seems like it will allow the behavioral changes mentioned (and the braille embosser case @aleventhal mentioned) without adding extra verbosity. If people object on specific roles, I propose we raise those as individual issues.