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 w3c/dpub-aam#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 w3c/html-aam#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 <#1643 (comment)>, 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 <#1643 (comment)>, 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.

[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.

[cookiecrook]

FYI this is on the ARIA agenda for TPAC. Currently scheduled for Friday morning, but I've asked @jnurthen to change it to Thursday to accommodate @avneeshsingh if he can attend remotely. @avneeshsingh Do you prefer morning or late afternoon Pacific time?

[avneeshsingh]

Thanks @cookiecrook
I will be participating in TPAC remotely. I am at +5:30 UTC. So, morning time on Friday will work well for me.
8 AM in Vancouver will be 20:30 in India
9 AM in Vancouver will be 21:30 in India.
Both of these time slots will work.

[cookiecrook]

Had a good pre-meeting with @clapierre and Gregorio today and came to a good agreement I think. I have notes that I will try to summarize tomorrow before the Friday morning meeting.

[cookiecrook]

Trying to reconcile feedback with @clapierre and Gregorio from Wednesday with the prioritization notes from @avneeshsingh above. There are some conflicts in received information, so none of this is set in stone.

Here are my rough thoughts to discuss in the group call Friday morning.

Note, I may edit this more before that call.

Consider as new Core Roles in ARIA main spec (in any case, map the doc-prefixed roles to AAM with new role/subrole and role description)

• doc-chapter
• doc-pullquote
• doc-subtitle: Is this sufficiently different from heading? [Update: @scottaohara says yes, would help with https://github.com/hgroup element mapping update html-aam#398 ]
• doc-footnote

link roles:

compromise: add role/subrole for these but keep role description "link" like the superclass role (prevents breaking user muscle memory)

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

Keep in DPUB, but need AAM role/subrole and role description:

• doc-pagebreak: needed to reference print or other finite source page numbers. AT may want to announce in some contexts.
• doc-notice
• doc-toc
• doc-tip

Keep in DPUB: add subrole but keep the role description of the superclass (e.g. "group")

Still question what utility this has to AT users... Make sure this doesn't end up as effectively EPUB API. (See also note below re: "group roles that keep superclass role description")

• doc-part
• doc-endnotes
• doc-abstract

Others Avneesh listed above were not important to re-map in DPUB AAM (leave exposed as identical to the superclass role)... In hindsight I may have received conflicting info, so these may be undecided.

• doc-acknowledgments
• doc-afterword
• doc-appendix
• doc-bibliography
• doc-colophon
• doc-conclusion
• doc-cover
• doc-credit
• doc-credits
• doc-epigraph
• doc-epilogue
• doc-errata
• doc-foreword
• doc-glossary
• doc-index
• doc-introduction
• doc-preface
• doc-prologue

Questions (instances of conflicting info between Wednesday's discussion and the prioritization notes above, so I don't know where these will land)

(Charles mentioned Wednesday he wanted to keep these; but Avneesh's WG prioritization list above indicates low importance)

• doc-dedication
• doc-example

Charles mentioned okay to skip, but above Avneesh ranked these higher.

• doc-pagelist

Re: group roles that keep superclass role description

Consider: add subrole but keep role description matching that of the superclass role (e.g. "group")? Or maybe add something additional distinguishing information some non-intrusive, non-verbose way that is only available on demand. Still not sure how to do this, but thinking similar to Mac:AXListItem which is available for orientation but not spoken unless requested, or maybe something new like the "structured role description" @pkra mentioned above.

[scottaohara]

re: aria-subtitle - arguably yes, it should be considered different than heading, and would help with w3c/html-aam#398

[cookiecrook]

Avneesh mentioned publishers want pagelist role or subrole... role description is still in open discussion.

[pkra]

Random side note regarding the group of roles that are derived from link.

The problem they try to solve seems related to the recent aria-link-target discussion (i.e., #1785) because those link roles, ultimately, try to inform users of the type of target they lead to (e.g., bibliographic reference, glossary/index, foot/endnote).

I realize the aria-link-target discussion moved into a different direction but perhaps there is something to explore here.

[cookiecrook]

TPAC minutes: https://www.w3.org/2022/09/16-aria-minutes.html#t01

[cookiecrook]

Some of the points in the minutes are hard to follow, but the takeaway Mac API proposal from TPAC was:

1. Expose the raw role attribute string similar to how browsers expose DOM id and classname strings.
2. Pass the additional user string through some API property that would only ever be spoken at the end… so user could skip the added verbosity without time or interaction cost. (e.g. user here’s “link, [label], bibliography reference” not the front-loaded verbosity “bibliography reference link, [label]“)

I'm floating this change proposal internally at Apple.

[cookiecrook]

Aforementioned "some API property" will likely use AXCustomContent, but waiting on specifics.

[cookiecrook]

WebKit tracker: https://webkit.org/b/248411

[cookiecrook]

w3c/dpub-aam#15 is ready for review