Add support for DPUB ARIA roles

[nvdaes]

Is your feature request related to a problem? Please describe.

Digital Publishing WAI-ARIA Module 1.0 is currently a W3C recommendation, and DPUB ARIA roles aren't supported by NVDA.

Describe the solution you'd like

DPUB ARIA roles should be supported to facilitate navigation as done with other landmarks, and present semantic information with speech, braille or other appropiate means used in NVDA.

Describe alternatives you've considered

Add support for DPUB roles according to specs, perhaps modifying the aria.py module. A new checkbox could be added to the Formatting document settings if it's considered that this kind of roles can convey too much info in conjunction with other landmarks. 🤔

Additional context

We are discussing this in the Reading Systems evaluation list managed by @daisy. According to @georgekerscher:

If NVDA and JAWS and VoiceOver and TalkBack would support the announcing of these semantics, this would be great.

Also, @avneeshsingh pointed out the following:

I will also assign highest priority to supporting DPUB aria roles. It is in W3C aria 1.1 specifications which screen readers should support. It is a concern that NVDA is not supporting it yet. http://www.w3.org/TR/2017/REC-dpub-aria-1.0-20171214/

[LeonarddeR]

I think this is a very valid request. Cc @dkager

[nvdaes]

Thanks. DAISY people may wish to comment more on this now or in future oportunnities, since testers like me are evaluating NVDA with different ePUB reading systems at epubtest.org.

[dkager]

Yes, while I'm not yet completely familiar with these roles I agree this is a valid, useful addition.

[GeorgeKerscher]

Developer Collaboration Request for DPUB-ARIA

Last updated: September 1, 2021

Background

The Transition to Accessible EPUB 3 DAISY working group in conjunction with Benetech, LIA, and other leaders in the field of document access are seeking collaboration from targeted companies to help in the implementation of the DPUB-ARIA roles. The DPUB-ARIA roles version 1.0 is a W3C recommendation, and we want to encourage its widespread adoption across all browsers and EPUB reading systems and Apps. Find the specification at: https://www.w3.org/TR/dpub-aria-1.0/

What we have Done

• Developed a suggested, semantic, spoken representation for screen reader and other AT vendors.
• Tested the browsers to determine if they are exposing the DPUB-ARIA roles.
• Tested the browsers and AT combinations to determine what they are speaking now.
• Tested important reading systems with AT to determine what is being presented.
• Created a report with all the information.

Our Ask

• We are asking browser developers to review our results in the hopes of improving what is presented by AT. Where there is missing information necessary for AT to present the semantic information, we are asking the browser developers to fix the issues.

• We are asking EPUB Reading System developers to review the results and correct any areas where the reading system is not delivering the DPUB-ARIA semantic information and making it available to AT.

• We are asking AT developers to review the suggested output we have developed. We understand this is not a requirement and is only a suggestion. We have only made this information available in English.

Where to get the information

GitHub Repo at:

https://github.com/daisy/transitiontoepub.git

Test results for Browser and Reading Systems as Excel:

https://github.com/daisy/transitiontoepub/blob/main/dpub-aria-testing/test-results/DPUB-ARIA-test-results.xlsx

Test Results for Browsers and Reading Systems as a CSV file:

https://github.com/daisy/transitiontoepub/blob/main/dpub-aria-testing/test-results/DPUB-ARIA-test-results.csv

Suggested spoken output for Assistive Technology Vendors at:

https://github.com/daisy/transitiontoepub/blob/main/dpub-aria-testing/Suggested-AT-output/DPUB-ARIA-suggested-output.xlsx

[seanbudd]

Adding this issue to the 2022.1 milestone so we can track this request.

[editadapt]

I'am very interested by the result of this feature request, as it been implemented or discussed in another place?

[nvdaes]

@seanbudd @michaelDCurran , any change to triage this so this canbe investigated to get implemented? I'd like to help on this request if possible.

[michaelDCurran]

In principle, NV Access is in favor of supporting this standard where possible. However, There are many new roles, and it would be good to get a clear idea on how they should be presented to the user and how they may aide with navigation.

In regards to reporting roles automatically: Looking at several of the roles, such as doc-abstract or doc-appendix: The examples in the standard either include an aria label including the role's name E.g. <div role="doc-abstract" aria-label="abstract"> which means NVDA is not going to want to announce the role by default, otherwise we will constantly get speech like "abstract abstract". However, each of the roles would have to be considered on its own.

In regards to supporting them as landmarks / NvDA quick navigation / Elements list: The standard may already suggest which ones are landmarks. And we may need to choose which ones require their own new quicknav keys etc.

It would be also important to understand which Browsers / toolkits actually expose these roles via IAccessible2 and UI Automation currently.

In short, for anything to be implemented here, I would like to see clear example content, expected speech / braille, and expected navigation.

[nvdaes]

Thanks Mick. @GeorgeKerscher , can you reply to this thread please? Thanks.

[avneeshsingh]

Thanks @michaelDCurran, these are good questions. We did analysis on this and will come back to you with details. @gregoriopellegrino, can you please provide the link to Web platform tests which shows that DPUB ARIA roles are supported in the browsers.

[gregoriopellegrino]

Here you have the results of implementations of DPUB ARIA roles on different browsers: https://wpt.fyi/results/dpub-aam/role/roles.html

[Adriani90]

@gregoriopellegrino which of these roles are also visible for sighted people? I thing it makes sense to implement support only for the roles that a sighted person would also use to navigate a book.

So in my opinion following roles are obviously used also by sighted people due to their visual identity:

• role: doc-abstract
• role: doc-appendix
• role: doc-chapter
• role: doc-endnotes
• role: doc-footnote
• role: doc-glossary
• role: doc-notice
• role: doc-pagelist
• role: doc-pagefooter
• role: doc-pageheader
• role: doc-pagebreak
• role: doc-toc
• role: doc-tip
• role: doc-pullquote

Things like index, dedication, conclusion, introduction, preface, foreword, afterword, aknowledgements, bibliographie, prologue etc. are also indicated by headings, this is also how a sighted person would look for it. Correct? So a propper heading atribute should be sufficient to reach these zones nearly as fast as a sighted person without the need for an extra role.

Following roles should not be supported because this is already supported in browse mode:

• role: doc-cover
• role: doc-credits These two roles are always at the beginning and at the end of the book. So we can easily navigate to the beginning and the end with ctrl+home or ctrl+end so there is no issue in reaching these zones very fast with the current browse mode implementation.

Following roles should not be supported because they are not describing usual navigation paterns:

• role: doc-colophon
• role: doc-epigraph
• role: doc-epilogue
• role: doc-errata
• role: doc-backlink
• role: doc-part
• role: doc-qna
• role: doc-subtitle Do sighted people really navigate a book by these roles visually?

Following roles should not be supported because a quick navigation to them is not really logical. They should instead be numbers which are linked to the foodnotes or end notes or what they refer to and should be read as proper "link". We don't need an extra role for this becasue it introduces noise while reading:

• role: doc-noteref
• role: doc-glossref
• role: doc-biblioref

[nvdaes]

Acccording to the table with implementation results for browsers, I understand that, for example, doc-abstract is available on Microsoft Edge Canary for Windows. I've installed Edge Canary on Windows 1, and created an HTML document with role="doc-abstract". Then I've pressed NVDA+f1 to explore the paragraph properties, with and without UI Automation. But I don't see any property that helps me to work on this. I've read the Notes Adding support for aria attributes to browsers. In case I don't know how to create a PR for this, I'll review the implementation and contribute testing if needed. Or I may try to work if I get some initial guidance, though there are still unansered questions, specifically what roles should be considered landmarks.

[Adriani90]

In addition to my comment above, from the 14 roles I proposed to be supported, I can exclude some more of them as follows:

• role: doc-abstract • role: doc-appendix • role: doc-glossary These 3 roles are also indicated by headings, so if they have a proper html heading role then we can already find them without an additional role.

• role: doc-pagelist This role has mostly already another html role such as list, combo box, tree view or what ever. This could also be indicated via a html landmark role. So there is no additional role needed.

• role: doc-pagefooter • role: doc-pageheader Not sure if wee need these two roles if we can navigate to the page break. Supporting the role doc: page break would bring us already near the page footer of current page or the page header of next page. Or am I wrong?

• role: doc-toc This role is actually not needed because the toc is either indicated by a heading or it is a table itself. So having either a heading role or a html table role would already help and we don't need an additional role. Usually we press ctrl+home to navigate to the beginning of the book and then press h a couple of times to navigate to the toc heading. A sighted person would also scroll up and down until the propper heading is found.

[Adriani90]

So in summary, in my view only following roles should be supported separately because they are not always indicated by other roles.

• role: doc-chapter • role: doc-endnotes • role: doc-footnote • role: doc-notice • role: doc-pagebreak • role: doc-tip • role: doc-pullquote

[nvdaes]

I can exclude some more of them as follows:

... These 3 roles are also indicated by headings, so if they have a proper html heading role then we can already find them without an additional role.

I think that the mentioned roles should be supported in NVDA.

1. Headings are used to start sections, but maybe useful to know the purpose of each section, and knowing when we are moving out of them.
2. Regardless of what is indicated visually, screen reader users may want to know this information when a specific section is reached, since a sighted people can read more globally and we do it in a more linear way, so anticipating what things are maybe useful.
3. Not all roles maybe used to improve quick navigation, but this doesn't mean that the semantic information provided is not useful. Anyway, I think that Daisy people should provide more feedback to this thread to start implementing this.

[Adriani90]

1. Headings are used to start sections, but maybe useful to know the purpose of each section, and knowing when we are moving out of them.

Actually this will introduce the risk of misusage if the book author updates the heading but not the label of the role. So I think it is quite risky to define roles with the same label as the headings because then authors have to update things in multiple places and we end up with either lot of double speaking or lot of places where the label of the role does not match the actual heading.

2. Regardless of what is indicated visually, screen reader users may want to know this information when a specific section is reached, since a sighted people can read more globally and we do it in a more linear way, so anticipating what things are maybe useful.

Well quick navigation is not really linear anymore, it is actually very global and allows for skim reading. Roles such as headings are already giving the users a clue of what section will follow.

3. Not all roles maybe used to improve quick navigation, but this doesn't mean that the semantic information provided is not useful.

Could you please elaborate more on this? If we take such roles like • role: doc-abstract • role: doc-appendix • role: doc-glossary Which benefit would you have in these roles being reported in addition to the heading that already contains the same information?

In contrast, I see indeed a big improvement when NVDA reports entering and leaving foot notes, endnotes, notices, etc., or when reaching a tip, a new page or a new chapter is announced. So that's why I proposed only those 7 roles to be supported first. Then we can discuss on further roles if needed but to be honnest, I hope there will not be a lot of extra verbosity introduced to ePub books.

[nvdaes]

Actually this will introduce the risk of misusage if the book author updates the heading but not the label of the role. So I think it is quite risky to define roles with the same label as the headings because then authors have to update things in multiple places and we end up with either lot of double speaking or lot of places where the label of the role does not match the actual heading.

This should be configurable, and the risk is not specific to this kind of roles.

Well quick navigation is not really linear anymore, it is actually very global and allows for skim reading. Roles such as headings are already giving the users a clue of what section will follow.

I'm talking about reading, for example continuous reading, not just quick navigation.

Which benefit would you have in these roles being reported in addition to the heading that already contains the same information?

Headings may not contain the same information, and these roles can be assigned to paragraphs conteined in a section started by a heading. For example:

   <h2 id="hd">Deoxyribonucleic Acid Self-Replication</h2>
   <p role="doc-abstract">The cause of self-replicating DNA…</p>
   …
</section>

http://kb.daisy.org/publishing/docs/html/dpub-aria/doc-abstract.html#ex-002

[Adriani90]

This should be configurable, and the risk is not specific to this kind of roles.

I tend to agree, but many of these roles exist in parallel to other roles designed for the same purpose of semantic structure (i.e. groupings, lists, landmarks, regions etc.). So even if this is configurable, it will introduce more complexity and in many cases also confusion when all roles are supported.

Headings may not contain the same information, and these roles can be assigned to paragraphs conteined in a section started by a heading.

Looking at your code above, how would a sighted person know this is an abstract? I think it is not a good idea to introduce totally new roles only for visually impaired people. If this abstract section above has a clear visual identity, then I agree we should have a role for it. Otherwise we start to develop a new patern and we run into confusions when working together with sighted people.

[nvdaes]

many of these roles exist in parallel to other roles designed for the same purpose of semantic structure.

Can you provide precise examples of this regarding our discussion, i.e., dpub roles? From DAISY knowledge base:

The roles are not intended as a mechanism for workflow semantics so do not provide the same breadth of coverage as, for example, the EPUB Structural Semantics vocabulary.

http://kb.daisy.org/publishing/docs/html/dpub-aria/

So seems that roles should be added by authors in a way that doesn't produce confusions.

Knowing specific situations where supporting these roles can imply repeated info maybe crutial to decide what to implement and how to do it, for example, a mechanism maybe introduced to avoid double speaking in particular cases

Looking at your code above, how would a sighted person know this is an abstract?

CSS maybe used to associate a particular visual presentation with roles.

[ramoncorominas]

These 3 roles are also indicated by headings, so if they have a proper html heading role then we can already find them without an additional role.

Like any other landmark roles, I think they are usually assigned to container elements, so they will be useful when navigating "backwards", I mean, if I am in another section and move with up arrow the role will be announced when entering that section. The heading at the beginning will not help in that case. The same goes when navigating outside of the section, if the role is not there the end of the section will not be announced.

Actually this will introduce the risk of misusage if the book author updates the heading but not the label of the role. So I think it is quite risky to define roles with the same label as the headings because then authors have to update things in multiple places and we end up with either lot of double speaking or lot of places where the label of the role does not match the actual heading.

This is happening already with roles such as "main", "header", "footer" and so on, I don't think this is a reason to not support them.

[Adriani90]

Like any other landmark roles, I think they are usually assigned to container elements, so they will be useful when navigating "backwards", I mean, if I am in another section and move with up arrow the role will be announced when entering that section. The heading at the beginning will not help in that case. The same goes when navigating outside of the section, if the role is not there the end of the section will not be announced.

I see your point, but containers have visual identity. Regions are visually separated by separators, tables have certain visual structures, same for lists or headings. But roles such as abstract, glossary, credits, etc. do not have the same visual identity like a container. Let's take the example of an abstract section that spans over several pages or screens. So the heading is not visible at all when you enter the section from bottom with up arrow. Sighted people suffer from the same problem. They would also not really know the section unless they remember the structure of the book or the heading of that section or they scroll as far until the heading is visible. If CSS is applied to visually distinct the section from others, I think then it is really useful and understandable to have a role for it. But given the experience we already have with web design so far, not all web developers will adopt these additional new design paterns consistently.

As a compromise, what do you think about the request in #3554? Reporting of the nearest heading element above should actually give the user enough flexibility to find out in which section the cursor is, making at least several of the roles obsolete.

[gautierchomel]

I read with eyes and all those roles have visual identity. Not in all books, but when not, it's a lesser reading experience to me. I use them for navigation and for instant identification.

Duplication should not happen if the code is correctly made and the user can select verbosity.

[GeorgeKerscher]

The DAISY Transition to Accessible Publishing working group has created two resources to help in the implementation of DPUB ARIA roles in NVDA.

These files should provide what you need, and we are happy to answer any questions.

The first is an XHTML file found at [DPUB ARIA guidance and Testing] (https://github.com/daisy/transitiontoepub/blob/main/dpub-aria-testing/content/DPUB-ARIA-tests.xhtml)

The second is the same XHTML content in an EPUB 3. DPUB ARIA Guidance and Testing as EPUB

Best George