Descendants of buttons with "Children Presentational: True"?

[JAWS-test]

I think it's ok that buttons should not contain elements with roles, but unfortunately the HTML specification for the elements <button> and <summary> allows this (even interactive elements like links may be included in <summary>). I'm afraid that the HTML specification will not be changed (see whatwg/html#2272 (comment)), so we should consider whether the content of buttons is not implicitly presentational, so that AT users can perceive the content correctly (see FreedomScientific/standards-support#105).

[aleventhal]

Neither Chrome nor Firefox enforce leafiness of buttons anymore. I kept getting bugs that content inside of buttons, like links, were accessible in Firefox and not Chrome. When I investigated, I found that Firefox had changed it.

While invalid, it happens. For example, I saw an appointment in a calendar, where there was more info, including some links, inside of it. Triggering the appointment expands it to show more of its inner contents. This probably isn't a button, but I don't think the authors knew what to use. What should it be?

[JAWS-test]

Unfortunately this creates a big mess:

• The specification says that button cannot have child elements with a role
• Firefox and Chrome ignore that
• JAWS with Firefox and Chrome adheres to the specification and ignores e.g. links inside buttons
• NVDA outputs links within buttons as "Link" and "Button", which is confusing...

[stes-acc]

I would like to throw in the soup the question if headings are allowed inside buttons.
HTML folks say no on request but gimme the the exact location in HTML 5.2 spec where this is explicitly declared as forbidden.

Currently nothing in the world stops you saying

<button><span role="heading" aria-level="3">Details</button>

On request: "Yeah yeah don't do that" but where is the rule set?

The entire nesting thing including ARIA for the markup cries for clarification. Really.

[scottaohara]

@stes-acc if you look at the button element in the HTML spec, it clearly states that only elements that are classified as phrasing content, barring interactive elements or elements with tabindex. (note: html 5.2 had similar wording, but lacked the bit about elements with tabindex).

but per your example, yes, the HTML validator is silent on that as it's not checking the role, but the span. This is what I was referring to during our last WG call (my example being <button><span role=link>trash code</span></button>).

HTML is clear on the allowed nesting of elements. ARIA is purposefully vague, as was discussed at the end of the call. I personally think there needs to be more clearly defined rules here, while still respecting the need to be more lenient than HTML.

Re: this thread, based on what Firefox and Chrome are now doing, I personally do not think the spec should change concerning the children of buttons being presentational. Rather seems a topic that could be covered in Handling Author Errors so that what Aaron outlined here is not unexpected, but rather better surfaced so all user agents can consistently implement a way to correct for nested interactive elements.

[stes-acc]

I was speaking of the HTML spec in the past not the other one :) .. current whatwg is much more verbose here, I agree.

[carmacleod]

The whatwg spec is now "the HTML spec". Links to W3C HTML specs are old, and are no longer being updated.
https://www.w3.org/blog/2019/05/w3c-and-whatwg-to-work-together-to-advance-the-open-web-platform/

[scottaohara]

Per all the above, an in lieu of #1440, i wonder if the following would be sufficient (comments welcome to help move the thinking around this along):

1. Authors would still be advised NOT to nest interactive elements (roles) unless they are specifically following the guidance of aria-actions - in reality, nesting interactive elements - even if exposed in chrome/firefox, can still be very problematic for people using screen readers to access. E.g., buttons or links within buttons - attempting to activate with the virtual cursor typically only activates one of the controls, even if someone has managed to navigate to the inner control. For this reason it probably makes sense for aria-actions to not be directly exposed to virtual cursors - which then semi-treats these as presentational as well?
2. User Agents treat all non-focusable/non-interactive elements as presentational - aside from the above mentioned quirks of nested interactives actually functioning as expected - putting structured content within an element that is spec'd to have child presentational content can create other unexpected behaviors that should still be avoided/corrected by user agents. I came across an instance of a table inside of a button the other day ("FOR LAYOUT PURPOSES") and by-golly -gee ... no. please no.
3. User Agents expose the semantics of focused nested interactives - to mitigate against author errors - i.e., per Firefox/Chromium ignoring the current spec now, and potential author errors with the aria-actions proposal.

[JAWS-test]

If browsers ignore the children presentational, it might make sense to abandon the concept completely or to apply it only where nesting is actually not allowed in HTML and is automatically corrected by the browsers, e.g. at

• select (all elements except option and optgroup)
• option
• table (all elements except caption, thead etc.)
• link with nested link

As it is at the moment, I don't think it will work, because browsers ignore the children presentational for HTML elements and ARIA roles, and then screen readers do what they want, so there are no consistent results at all

[aleventhal]

We should probably address this in the spec since Firefox, Chrome and Edge are ignoring it.

[MelSumner]

Why specifically are they ignoring it?

[aleventhal]

Why specifically are they ignoring it?

We get desperate bug reports from users when there is content that a user cannot access. It's not always an option for the user to ask the company to change their content. Here's an example where sites use it, and I'm not sure what ARIA markup would cover it (they could change their UI but choose not to): an item/entry/region that shows truncated information, and clicking it (or focusing it and pressing enter/space) expands it to show the information. For example, entries in a schedule where there isn't enough room to show everything. The entry can have paragraphs, lists, links etc. inside of it.

Whether we think the use case is legit or not is kind of irrelevant, because it comes up, and if the UA simply truncates the info, the user has not chance of accessing it. If they tab to a link inside the <div role=button aria-expanded=true>...</div> they will hear nothing even in forms mode, because there is not even an object to receive a focus event.

Others can debate whether the use case is legit but in general the browsers run into trouble with inaccessible content when we just remove interactive content from the tree. Therefore I think this should be an authoring requirement if anything.

[scottaohara]

even with exposing the roles, JAWS 2023 for example, still treats the child content as presentational.

NVDA does expose the content inside of the buttons, though a bit awkwardly at times (which is not a criticism on them - they're dealing with some junk markup here after all)

very different experiences between nvda/jaws - https://codepen.io/scottohara/pen/XJrVGxX

i'll try to work on this issue soon, since it was assigned to me 4 years ago... sigh... clarification in the spec would be good...

[aleventhal]

@scottaohara We can work with JAWS to address this.

Maybe we should just change User Agents SHOULD to MAY.

[scottaohara]

to be clear, i was pointing that out as an example of how the spec says one thing, browsers are doing another, and then AT is doing a mixture.

i'm of the opinion this is a good repair, but it still can lead to an awkward user experience, even with the repair. i think it's poor authoring and that is the important part - pointing that out. but it's a good idea for browsers / AT to be able to attempt to expose the content, in spite of the author's mess.

[scottaohara]

made this issue on apg to create a component per the use case discussed in the aria wg meeting today - w3c/aria-practices#3215

[scottaohara]

from the call today:

• remove children presentational from buttons
• identify that this is to mitigate against author error, but it is still an author must not / not recommended depending on the element
• @smhigley brought up the idea, again, of identifying a content model for ARIA roles to indicate what is valid or not
• suggestion to add UAs SHOULD indicate there are errors if nesting invalid elements/roles within buttons (html or aria)

[spectranaut]

Notes from today's meeting: https://www.w3.org/2025/01/16-aria-minutes.html#f8cf