1625880 - Support heading announcements inside summary elements.

Status: NEW

(Core :: Disability Access APIs, defect, P3)

Description

[Marco Zehe (:MarcoZ)]

STR:

1. Open this testcase.
2. Navigate to the summary element with VoiceOver.
   • Result: VoiceOver speaks the text and the fact that this is a collapsed summary, but does not speak that this is text marked up as a heading.
   • In Safari, the output is the same.
   • In Chromium, it is spoken as a collapsed disclosure triangle (like on a tree view item that is collapsed), but not that this is a summary.
3. Press Ctrl+Option+Shift+DownArrow to interact with the element.
   • In Chrome/Edge, Firefox and Safari, the text is now spoken.
4. Press Ctrl+Option+Shift+UpArrow to stop interacting, and navigate back to the beginning of the page.
5. Press Ctrl+Option+Cmd+H.
   • Result in all browsers: VoiceOver can navigate to the heading 2 inside the summary and speaks it as such.
6. Press CTRL+Option+Shift+UpArrow to stop interacting.
7. Press CTRL+Option+Shift+DownArrow to interact again.
   • Result in Firefox and Safari: VoiceOver speaks "Interact with the title of ...", and then you can navigate the text.
   • In Chrome/Edge, VoiceOver speaks "Interact with the title of ...", followed by Heading Level 2", followed by the text. So, after navigating to the heading, in Chromium, the knowledge was retained that this is a heading.
8. In Chrome/Edge, now press CTRL+Option+Shift+UpArrow again to stop interacting.
9. Press CTRL+Option+RightArrow, then CTRL+Option+LeftArrow to get off of, and back onto, the Summary element.
10. Interact by pressing CTRL+Option+Shift+DownArrow.

• Result: Now, Chrome/Edge is also back to what happens in step 3, that the text is viewed as only text, not a heading.

Aim for this bug: Keep the summary semantics intact, but also make us expose the heading inside in such a way that VoiceOver always recognizes it. That would put us above the Safari and Chrome experience, and on par with screen reader support on Windows, where the H2 is always spoken as well.

Comment 1

[Morgan Reschenberg [:morgan]]

(In reply to Marco Zehe (:MarcoZ) from comment #0)

STR:

1. Open this testcase.
2. Navigate to the summary element with VoiceOver.
   • Result: VoiceOver speaks the text and the fact that this is a collapsed summary, but does not speak that this is text marked up as a heading.
   • In Safari, the output is the same.
   • In Chromium, it is spoken as a collapsed disclosure triangle (like on a tree view item that is collapsed), but not that this is a summary.
3. Press Ctrl+Option+Shift+DownArrow to interact with the element.
   • In Firefox and Safari, the text is now spoken.
   • In Chromium, the text is spoken, but the fact that this is a heading 2 element is also spoken.
4. Press Ctrl+Option+Shift+UpArrow to stop interacting, and navigate back to the beginning of the page.
5. Press Ctrl+Option+Cmd+H.
   • Result in all browsers: VoiceOver can navigate to the heading 2 inside the summary and speaks it as such.

Aim for this bug: Keep the summary semantics intact, but also make us expose the heading inside in such a way that VoiceOver recognizes it. That would put us above the Safari experience, and on par with screen reader support on Windows, where the H2 is spoken.

Marco, I can't get Chrome to speak the heading level; in the example you're talking about the "All About Trains" text, right?
I get "All about trains, collapsed, disclosure triangle", and then when I try to interact with the element (without expanding) I just get the same title "All about trains". Was there a different STR?

Comment 2

[Marco Zehe (:MarcoZ)]

No, when I filed this bug, and interacted with the disclosure thing in Chrome, it spoke "All about trains Heading Level 2". That's why I filed it in the first place, because I wanted us to do it the same way as Chromium does.

Comment 3

[Morgan Reschenberg [:morgan]]

:eeejay Can you reproduce this? 🤕 I am having trouble.
Also, :marcoz I'm wondering if data:text/html,<button><h1>hello</h1></button> would be a similar issue? Like, should we expect heading information to be passed from there also?

Comment 4

[Marco Zehe (:MarcoZ)]

OK, turns out the steps are more involved than I originally assumed. I updated the STR and clarified what actually happens in Chrome/Edge.

(In reply to Morgan Reschenberg [:morgan] from comment #3)

Also, :marcoz I'm wondering if data:text/html,<button><h1>hello</h1></button> would be a similar issue? Like, should we expect heading information to be passed from there also?

Well, interesting question. According to the various specs, heading elements inside buttons aren't allowed, because only phrasing content, if it is not interactive, is allowed. However, we do expose headings as button children in the a11y tree, and NVDA and JAWS on Windows pick this up just fine. So yes, I'd say this is a use case similar to this one.

Comment 5

[Morgan Reschenberg [:morgan]]

Hmm okay I was able to reproduce with the new STR (thanks!) but sorta stuck as far as what to do here. I looked at events and there's nothing special going on when we do heading navigation (VO+cmd+h), nor are there any special roles/subroles or lists (AFAIK) maintained for headings. Just role == AXHeading, subrole == none.

My guess is that since summaries are role == AXButton, subrole == AXSummary, they don't propogate heading info because there's no room in attributes to indicate something is a heading. I guess we could do something like use the Summary's value attribute to indicate heading level iff there's a heading child? Or maybe we could change the role to heading but still support the press action? Hmm. Also not sure what something like this would entail, then:

<details>
  <summary>
   <a><h1>This is an important link</h1> check it out!</a>
  </summary>
  Here's more information
</details>

Like, what if you need to send heading info through nested objects to get to the summary element 🤕

:eeejay any better ideas?

Comment 6

[Morgan Reschenberg [:morgan]]

hmm okay yeah I think this is a button issue. if I switch the summary's main role to AXGroup, it reads the heading fine, but doesn't acknowledge the group as a summary even if I leave AXSummary as the subrole...

Comment 7

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1625880: Change summary role to allow heading information to propagate. r=eeejay.

Comment 8

[Eitan Isaacson [:eeejay]]

(In reply to Morgan Reschenberg [:morgan] from comment #6)

hmm okay yeah I think this is a button issue. if I switch the summary's main role to AXGroup, it reads the heading fine, but doesn't acknowledge the group as a summary even if I leave AXSummary as the subrole...

Yeah.. that is what I tried too. No luck. I think Chrome is benefiting from a happy accident since it doesn't really support AXDetails/AXSummary. It exposes them as groups and static text. It offers the "disclosure triangle" as the role description, but that's it.

Comment 9

[Morgan Reschenberg [:morgan]]

(In reply to Eitan Isaacson [:eeejay] from comment #8)

(In reply to Morgan Reschenberg [:morgan] from comment #6)

hmm okay yeah I think this is a button issue. if I switch the summary's main role to AXGroup, it reads the heading fine, but doesn't acknowledge the group as a summary even if I leave AXSummary as the subrole...

Yeah.. that is what I tried too. No luck. I think Chrome is benefiting from a happy accident since it doesn't really support AXDetails/AXSummary. It exposes them as groups and static text. It offers the "disclosure triangle" as the role description, but that's it.

Seems okay with AXSummary as a role though 👀
Also: Can you reproduce a difference between us and chrome? After Marco's heading-navigation above, I can't leave the summary element and have Chrome remember the heading; I get both FF + Chrome forget the heading and treat it as a title, though you can leave the heading (while still in the summary) and have it remembered in both browsers.

Comment 10

[Eitan Isaacson [:eeejay]]

(In reply to Morgan Reschenberg [:morgan] from comment #9)

(In reply to Eitan Isaacson [:eeejay] from comment #8)

(In reply to Morgan Reschenberg [:morgan] from comment #6)

hmm okay yeah I think this is a button issue. if I switch the summary's main role to AXGroup, it reads the heading fine, but doesn't acknowledge the group as a summary even if I leave AXSummary as the subrole...

Yeah.. that is what I tried too. No luck. I think Chrome is benefiting from a happy accident since it doesn't really support AXDetails/AXSummary. It exposes them as groups and static text. It offers the "disclosure triangle" as the role description, but that's it.

Seems okay with AXSummary as a role though 👀

How do you mean "ok"? What does that produce?

Comment 11

[Morgan Reschenberg [:morgan]]

(In reply to Eitan Isaacson [:eeejay] from comment #10)

(In reply to Morgan Reschenberg [:morgan] from comment #9)

(In reply to Eitan Isaacson [:eeejay] from comment #8)

(In reply to Morgan Reschenberg [:morgan] from comment #6)

hmm okay yeah I think this is a button issue. if I switch the summary's main role to AXGroup, it reads the heading fine, but doesn't acknowledge the group as a summary even if I leave AXSummary as the subrole...

Yeah.. that is what I tried too. No luck. I think Chrome is benefiting from a happy accident since it doesn't really support AXDetails/AXSummary. It exposes them as groups and static text. It offers the "disclosure triangle" as the role description, but that's it.

Seems okay with AXSummary as a role though 👀

How do you mean "ok"? What does that produce?

Behaves as expected (when you enter, exit the title of the summary it gives you heading information, even if you exit all the way out of the details object or if you've never VO+CMD+H'd before). Seems to preserve all the other relevant info too (unlike AXGroup)