non-focusable widget roles nested within elements with children presentational

[giacomo-petri]

As demonstrated in web-platform-tests/wpt#50045, UA consistently expose non-focusable widget roles nested within elements with children presentational with their implicit role.

For example:

<button>
  Something
  <div role="button">Something</div>
</button>

According to the current specs, the conditional logic does not account for this exception. As written, the nested button should be ignored or treated as a generic element, which does not match existing UA behavior.

Since I'm currently working on Presentational Roles Conflict Resolution in #2237, I'd like to address this discrepancy in that PR. Before doing so, I want to confirm that this is indeed the desired direction.

[scottaohara]

As mentioned in the call from today, here are at least a few of the related issues about child presentational (by being directly mentioned or should be considered in the same conversation)

• Prohibit authors from causing conflict resolutions #1288
• reword one of examples for role presentation #1455
• Unclear what counts as interactive in Presentational Roles Conflict Resolution #1270
• Each ARIA role entry characteristics table should have a "can have focusable descendants" entry #1028
• Deprecate presentational children #2509
• Descendants of buttons with "Children Presentational: True"? #1174

there may be / likely are others. but i'll need to look more later.

[css-meeting-bot]

The ARIA Working Group just discussed non-focusable widget roles nested within elements with children presentational.

The full IRC log of that discussion

<Zakim> agendum 5 -- -> non-focusable widget roles nested within elements with children presentational https://github.com//issues/2699 -- taken up [from agendabot]
<Adam_Page> spectranaut_: yay, github-bot
<Adam_Page> ... from giacomo-petri
<Adam_Page> giacomo-petri: I want to update that is not just about widget roles, but everything in general within roles that allow presentational children
<Adam_Page> ... right now, UAs are all exposing nested elements to AT
<Adam_Page> ... even though the parent specifies presentational children
<Adam_Page> ... I understand why UAs are doing it, but it still conflicts with the spec
<Adam_Page> spectranaut_: hasn’t this conversation happened before? that we should cross-reference?
<Adam_Page> scott: looking through backlog, because I think you’re right
<Adam_Page> jcraig: I recall a convo with aaron
<Adam_Page> ... maybe some things to consider there are strong native semantics for focusability
<scott> here is one related issue: https://github.com//issues/2509
<Adam_Page> ... because right now UAs do respect native focusability
<Adam_Page> ... the ARIA spec may not account for that
<giacomo-petri> q+
<jamesn> q+
<scott> q+
<Adam_Page> q?
<Adam_Page> giacomo-petri: we have conflict resolution
<Adam_Page> jcraig: but it might overlap with a different section about strong native semantics
<Adam_Page> ... for example `required` attribute overriding `aria-required`
<Adam_Page> ... but it still may not account for this
<Adam_Page> jamesn: Chromes started this by exposing button children
<Adam_Page> ... related to summary/details
<spectranaut_> ack giacomo-petri
<spectranaut_> ack jamesn
<Adam_Page> ... because HTML allowed <summary> to be stuffed
<spectranaut_> ack scott
<jcraig> q+
<Adam_Page> scott: there was some discussion we had in WG meetings about “do all roles really need to be exposed?”
<Adam_Page> ... for example a <main> inside a <button>
<spectranaut_> ack jcraig
<Adam_Page> jcraig: I remember some of this discussion being related to `aria-hidden` semantics, and its similarity to `presentation` behavior
<Adam_Page> ... things that `aria-hidden` from the a11y tree, until it must be exposed by virtue of something taking focus
<scott> https://github.com//issues/1174
<Adam_Page> scott: I just threw another even older issue in ☝🏻
<Adam_Page> ... I’ll throw these into giacomo-petri’s issue and any others I find, to consolidate
<Adam_Page> ... thank you for raising this again, giacomo-petri
<jcraig> Github: https://github.com//issues/1174
<jcraig> GitHub: https://github.com//issues/2699
<Adam_Page> spectranaut_: seems like we should resolve this
<Adam_Page> ... maybe we can, in the next 30 min
<Adam_Page> ... do we want to figure out what cases we need to remove children: presentational from? to align with current UA behavior?
<Adam_Page> scott: while browsers “don’t” respect it, I know that JAWS does
<jcraig> q+ to mention the "browsers don't support it" may be more nuances... e.g. most input elements?
<Adam_Page> ... and have had multiple conversations with them where they expressed concerns
<jcraig> s/nuances/nuanced/
<spectranaut_> ack jcraig
<Zakim> jcraig, you wanted to mention the "browsers don't support it" may be more nuances... e.g. most input elements?
<Adam_Page> ... jcraig, can you recall if someone were to put a heading inside a button, can VO navigate into it?
<Adam_Page> ... definitely not on iOS
<Adam_Page> jcraig: certainly not a native button
<Adam_Page> ... but maybe a <div role="button">
<jcraig> ack me
<Adam_Page> ... browser support will be varied
<Adam_Page> scott: we should still interrogate these cases carefully
<Adam_Page> spectranaut_: should we try to think of a list of cases?
<Adam_Page> ... maybe figure out what kind of investigation to do with SRs? Reach out to them?
<Adam_Page> jamesn: Mel was going to look into this
<Adam_Page> ... I don’t want to tackle this just for `button`; we should look at all the elements that do have presentational children
<Adam_Page> ... and figure out which ones we might want to allow nested interactives, and which ones we certainly don’t
<Adam_Page> spectranaut_: do validators validate this?
<Adam_Page> jamesn: yes
<Adam_Page> ... in some cases
<Adam_Page> scott: yes, some cases, but they don’t catch everything
<Adam_Page> ... we started to try to make this normative in ARIA-in-HTML but didn’t finish
<Adam_Page> ... axe put some checks in and then pulled them out because of uncertainty
<giacomo-petri> q+
<Adam_Page> ... just also found #1455, which might be related
<Adam_Page> ... about `role="image"`
<spectranaut_> ack giacomo-petri
<Adam_Page> giacomo-petri: to jamesn’s point, think about a heading inside of a button
<Adam_Page> jamesn: if it’s something non-interactive, then you can just flatten it
<jcraig> Scott's referenced issue above: https://github.com//issues/1455
<Adam_Page> ... you’ll remove semantics, but you won’t necessarily 100% break something
<Adam_Page> spectranaut_: the main problem we’re trying to solve is that people want to nest interactives
<Adam_Page> jamesn: yes, sometimes, but often someone’s created something like a card, for example, where they enclose all the card content in a single `<button>`
<Adam_Page> ... and maybe we want to consider accommodating that
<Adam_Page> scott: parsing will prevent native interactives from being nested
<Adam_Page> ... but that can still be defeated with Javascript
<Adam_Page> ... while <button>s are not allowed inside <button>s, for example, HTML does still allow for interactives within <summary> which functionally acts like a button
<Adam_Page> spectranaut_: no clear path forward for this
<Adam_Page> ... would be good if someone could champion this
<Adam_Page> scott: giacomo-petri, would you like to team up on this?
<Adam_Page> jamesn: definitely worth doing, but needs a good plan behind it; testing, investigation, etc.
<Adam_Page> scott: I’ll take assignment, I’ve already begun to do the research
<Adam_Page> giacomo-petri: I will help
<Adam_Page> pkra: I will also help
<Adam_Page> s/I will also help/and my axe!/
<giacomo-petri> https://github.com//issues/2685
<Adam_Page> spectranaut_: any other topics, or should we start spring cleaning?
<Adam_Page> giacomo-petri: somewhat related ☝🏻
<Adam_Page> ... talks about presentational, allowed children, so could potentially be related
<Adam_Page> ... started creating a table with ideas/suggestions
<spectranaut_> shttps://github.com//issues/2685
<spectranaut_> s\https://github.com//issues/2685\Topic: https://github.com//issues/2685\