Details / summary: Heading within Summary missing from Headings list

[juleskuehn]

Summary

<detail> / <summary> is a standard pattern for expand / collapse behaviour in HTML 5.1.

A single heading element is allowable as the content of a <summary> element in the HTML 5.1 specification for summary:

Content model:
Either: phrasing content.
Or: one element of heading content.

A summary with a heading should appear in the headings list. Yet, a heading contained within a summary element does not appear in the headings list in JAWS 2018, with either Firefox or Chrome.

Expected result

• A summary with a heading should appear in the headings list. ("Headings list")
• Summaries show in buttons list. ("Buttons list")
• Activating a collapsed summary with the keyboard should expand it, and activating an expanded summary with the keyboard should collapse it. ("Expandable / collapsible")
• The expanded / collapsed state should be voiced by the screen reader. ("State voiced")
• An expand / collapse action should be voiced by the screen reader. ("Expansion / collapse voiced")

Actual result

Browser	Headings list	Buttons list	Expandable / collapsible	State voiced	Expansion / collapse voiced
Expected	Yes	Yes	Yes	Yes	Yes
Chrome 68	No	Yes	Yes	Yes	Yes
Firefox 61	No	Yes	Yes	Yes	Yes

Full assessment of detail / summary tests

Example

Details / summary test case with heading inside summary

Additional Information

JAWS version and build number

JAWS 2018.1807.8 ILM

Operating System and version

Windows 10.0.16299

Browser and version:

Chrome 68, Firefox 61

[LJWatson]

@juleskuehn it may be because the <summary> element naps to the button role in the accessibility tree, and having a control for the disclosure widget that had a dual role of button and heading would be complicated.

[juleskuehn]

@LJWatson (Assuming you meant "Maps" not "Naps") Right, but the <summary> shouldn't have a dual role - it should have a button role, while the heading (inside the control) should have its own role? We aren't trying to do <summary role="heading">.
The only way I could get the desired functionality is to have the button nested inside the heading:
Test case: <summary><h4> converted to <div><h4><button>.

[LJWatson]

@juleskuehn

(Assuming you meant "Maps" not "Naps")>

Indeed :)

Right, but the

shouldn't have a dual role - it should have a button role, while the heading (inside the control) should have its own role?>

No, it shouldn't have a dual role. But by putting a heading inside a button, you effectively end up with a button/heading composite.

So this:

<summary><h2>this</h2></summary>

Is the same (in the accessibility layer) as:

<button><h2>this</h2></button>

In both cases, Jaws acknowledges only the parent element, and announces the control as a "button", not a "heading".

What would the advantage of recognising both the button and the heading be?

[juleskuehn]

Do we agree that valid HTML headings should appear in the headings list?

[scottaohara]

Adding some additional info to the mix...

Testing with Firefox nightly (63) and accessibility viewer, summary is revealed as a 'push button'. JAWS will neither list the heading in the headings dialog, nor allow quick key navigation to a heading within a summary.

Testing the following code:

<button>
  <h3>a test</h3>
</button>

JAWS ignores the heading within the button, just like it does with...

<details>
  <summary><h3>test</h3></summary>
</details>

Accessibility Viewer does reveal that the role of the h3 nested within the button and the summary is available.

It is an odd situation, because headings within buttons are invalid, and summary is announced as a button by JAWS, but it's not a button.

Both NVDA and VoiceOver expose the heading with the summary.

And for comparison's sake, TalkBack will also ignore a heading within a summary.

[lamador]

The heading is still not being read in the <summary> element using the latest version of JAWS 2020 (2020.2004.66), Chrome (81.0.4044.138, Official Build, 64-bit) and Firefox (76.0.1, 64-bit) in Windows 10.

The HTML Standard says you can nest a heading element in a summary, but the recommended accessibility API mapping for a summary in the HTML-AAM is a button role which makes the nested heading invalid.

@BenKeyFSI , per @scottaohara 's feedback, it'd be great if JAWS could do what NVDA does and create an exception for the summary element, since it's a "button" without all the limitations or allowances of a button element. e.g., also cannot accept the disabled attribute.

[BowtiesAreCool]

Encountered this issue today running JAWS 2020.2001.70 and a number of browsers (Edge Chromium 81.0.416.72, Chrome 81.0.4044.138, Firefox 76.0.1 - all 64-bit).

As reported above the element is recognised as a button but not as a heading. This differs from the behaviour in NVDA and Windows Narrator which treat it as both a heading and a button.

Relevant HTML:

<details>
    <summary>
        <h3 style="display: inline;">Heading here</h3>
    </summary>
    <p>Body content here</p>
</details>

As a (sighted) content author I agree with the expected results stated in this ticket.

[timbomckay]

Is there any progress on this?

[hexabinaer]

Watching 👀

[nchua-msd]

Any progress on this? We encountered this issue while using JAWS 2023.2303.144.
We were wanting to have the headings inside the summary so that the accordions/details are displayed on the heading structure and can be easily navigated with screen readers.

[stevefaulkner]

this issue is still present in JAWS 2023.2307.37
The reason it occurs is detailed here https://www.tpgi.com/respect-your-children/
The resolution relies upon the definitions of presentational children and the role of the <summary> element being clarified.
closing here until mapping is clarified.