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 https://github.com/whatwg/html/issues/2272#issuecomment-578654640), so we should consider whether the content of buttons is not implicitly presentational, so that AT users can perceive the content correctly (see https://github.com/FreedomScientific/VFO-standards-support/issues/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 https://github.com/w3c/aria/issues/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