Details element Summary content always rendered as plain text

[SteveALee]

/cc @patrickhlauke, @stevefaulkner and @daniel-montalvo

Summary

The HTML5 spec states the Summary element can contain content such as <a> and <h*> however Jaws does not expose this correctly, dropping the semantics.

It appears that Jaws maps the details marker to a button and the summary to play text content. The second slot content IS correctly rendered.

I cannot tell if behaviour is standard or a unilateral decision as something has to be done for AT users? This html-element-role-mappingseems closest to a spec

Expected result

Button{?} and HTML content

Actual result

Button and plain text content

Example

This uses <a> in the summary but same <hn> also fail to render correctly

<details>
  <summary>
      <a href="#top1">Top level 1</a>
  </summary>
  <ul>
    <li><a href="#child11">Child 1.1</a></li>
    <li><a href="#child12">Child 1.2</a></li>
  </ul>
</details>
<details>
  <summary>
      <a href="#top2">Top level 2</a>
  </summary>
  <ul>
    <li><a href="#child21">Child 2.1</a></li>
    <li><a href="#child22">Child 2.2</a></li>
  </ul>
</details>

Additional Information

This is not academic. We want to add collapsible Table of contents to several new WAI website pages but have spent time trying to find something that works with Jaws.

For example this draft page uses details but we also have problem with <hn> elements rather than

Summary element in the spec - "Content model: Phrasing content, optionally intermixed with heading content."

JAWS version and build number

Latest?

Operating System and version

Browser and version:

[stevefaulkner]

@SteveALee

It appears that Jaws maps the details marker to a button and the summary to play text content.

its not JAWS that does this its the browser that maps summary to button and button has child presentational children.
refer to the mapping for summary in the html acc api spec

[JAWS-test]

Duplicate of: #105

[JAWS-test]

Related: w3c/html-aam#345, w3c/html-aria#355, whatwg/html#2272, nvaccess/nvda#12008, w3c/aria#1174

[SteveALee]

Duplicate of: #105

Not quite duplicate as content can be more than heading elements.

[JAWS-test]

@stevefaulkner

its not JAWS that does this its the browser that maps summary to button and button has child presentational children.

This is not true. Both Firefox and Chrome do not map summary to button, but to a separate role (which does not currently exist in ARIA). Within summary, all other roles (such as links) are correctly passed to the Accessibility API and would thus be correctly available for reading by JAWS. NVDA also does this correctly (e.g. lists the links in the link list). However, JAWS does not do this. In this respect, JAWS follows the mapping specifications exactly, but ignores the information passed by the API.

In #105 it was accepted as JAWS bug.

[stevefaulkner]

This is not true. Both Firefox and Chrome do not map summary to button, but to a separate role (which does not currently exist in ARIA).

This unfortunately is a misunderstanding on your part. while Firefox has an internal role of summary and chrome has an internal role of disclosureTriangle they are both currently exposed as push button in the platform accessibility APIs, as per what is specified in the HTML Acc API spec.

[JAWS-test]

@stevefaulkner

Thanks for the hint. I was not aware until now that the developer tools of the browsers do not show the role that is actually submitted to the API, but use their own role identifiers that have no meaning. However, what remains true about my statement is the following:

• both browsers ignore Children presentational on these buttons and correctly pass all descendant elements to the API.
• other screen readers (like NVDA) use this API information to output the role of the links

[JAWS-test]

@SteveALee

I consider links in the summary element to be an anti pattern that should not be used under any circumstances, regardless of incorrect output by screen readers.

The usability of the element is zero. It is not recognizable that the icon and the link have different functions. The fact that an interactive element contains another interactive element is absolutely unusual and thus makes it difficult to use for all people.

In addition, the click area of the icon is too small and thus violates WCAG SC 2.5.5 and 2.5.8.

I strongly recommend the W3C to choose a different implementation, e.g. place the link inside the details element

[SteveALee]

@JAWS-test thanks for your thoughts We have thougt long and hard about the less familiar interaction pattern and are exploring alternatives. More on that below.

But this bug is about JAWS apparently throwing away HTML semantics for Summary, of which links is only one aspect. The problem may well turn out to be in other parts of the stack, eg browsers or platform accessibility APIs. We should aim to identify the cause and fix it. Everyone wins when the specs are fully implemented everywhere, even when they allow patterns we seriously don't like. I personally abhor throwing away the link underline affordance as CSS provides for and that is sadly common in the name "good design". One of the strengths of the web is it's extreme UI flexibility based on a few flexible semantic and interaction primitives. People are free to use that as they like. Even at the users expense. Something we in the accessibility world are rightly very sensitive about! Anyway enough philosophy about TBL's great gift :)

As for your point of having two interactions modes in one "widget", this may be unusual but there are other examples in the wilds. eg Buttons with a pull down menu on. There are also cases where two interactions are closely bound by being close (visually and in the DOM) even if not bound into a "widget". Yes the case of link in summary there are negatives, and another is the cognitive impact of less familiar patterns. There are also positive - eg a collapsible Table of Contents which is more manageable and so more cognitively accessible. IMHO engineering is all about balancing the trade-offs like this. Oh and following the specifications. And user testing to check our assumptions:)

Some mitigations in this case are:

• The link element (by default) has a clear affordance, both visually and a11y API
• The interactive marker is fully customisable in CSS
  • agree the default browser versions are very poor - just like focus rectangles where until recently
• There are other ways to customise the the content eg :before that clarify the visual interaction modes

These all allow designers to improve the interactions, or not, as they choose.

In fact we have explored other presentations, eg using the WAI website themes expand / collapse As an aside, I notice @yatil provided an example with a Heading in the summary, something that is also broken in JAWS and so falls under this bug and called out #105.

Here is an example page exploring this.

We haven't decided on the final approach yet. It obviously needs to be accessible but the bug in JAWS leads us to have to make a difficult decision...

[JAWS-test]

@SteveALee

I fully agree with you that the JAWS bug needs to be fixed, regardless of my usability concerns.

However, the question is whether it is a JAWS bug. Because according to the ARIA specification, a button cannot contain interactive elements - and all content is output as plain text (i.e. heading markup is also ignored). Browsers ignore the specification here, JAWS adheres to the specification. There will be no solution until the HTML or ARIA specification is changed. More info: #591 (comment)

[SteveALee]

OK, so to my mind that raises the question: is the mapping to a button with "nested" content correct and specified somewhere in one of the several related specs? Would "peer" content be OK? But then there's no wrapper element.

It seems to me that the a11y API specs (and so ARIA) are semantically restricted compared to HTML. Hence the need to map. There's a quite a few moving parts and spec to get aligned here I guess.

I defer to others on this but am happy to help where I can in order to unblock this.

[JAWS-test]

@SteveALee

Perhaps a possible solution would be to clearly distinguish between HTML and ARIA buttons:

• ARIA buttons have children presentational and may only contain plain text.
• HTML buttons may have semantic content and in the case of summary even interactive elements. HTML buttons do not map to ARIA role=button, but as with summary already well implemented in HTML AAM, directly to the button roles of the accessibility APIs.

This already works well in Firefox, Chrome and Edge. In NVDA it works relatively well (not perfectly).
If agreed, this would indeed be a JAWS bug and only the HTML AAM would still have to change the mapping for button (like already done for summary)

[stevefaulkner]

Works as expected in Chrome 119 and JAWS 2024, the summary is anounced as a button when it is focused and activates the expansion/collapse of the details element. pressing tab key moves focus to link inside button and link can be activated without effecting expanded/collapsed state
test case