Meeting minutes
<spectranaut_> scribe?
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: aria#2703
… exciting new PR from Daniel
… for improving netlify preview
Daniel: still working on it
… it won’t work in some cases
jamesn: we generally work in branches, not forks — so it not working on forks is no big deal
spectranaut_: but sometimes ARIA members do make changes from fork
… needs reviewers
pkra: I’ll review
spectranaut_: aria#2702
… editorial
jcraig: I’ll review
spectranaut_: I’ll also review
jamesn: me too
spectranaut_: approved
… can be merged now
New Issue Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: css-aam#16
… from pkra
… clarify CSS generated content alt text
pkra: just stumbled upon this morning
… and thought CSS-AAM might want to tackle
jcraig: I thought this was already covered in accname
… it doesn’t mention them
jcraig: I know we’ve got WPT tests for this
… I’ll look into it
spectranaut_: html-aam#595
… also from pkra
… update img alt accname to match aria-label
pkra: this came out of a convo with scott
… came up from validator updates
… they asked for input
… should be straightforward
Adam_Page: I’ll take it
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: open WPT PRs
… there are a couple
… wpt#56902
jcraig: I commented and will review
… and looking at Jacques’ second one now
cyns: I’ll review
jcraig: need to get you added to the repo
… please reach out to Simon at Mozilla
… zcorpan
… thanks for this second PR, Jacques — have some questions but still reviewing
… seems straightforward
Jacques: I’ll take a second pass
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: we don’t have anything in queue
… any topics?
jamesn: seems like we’re not having these often
… which is fine
… but please feel free to propose some
pkra: how about a backlog cleanup round?
… spring cleaning, so to speak
spectranaut_: yes!
jcraig: it’s a “shallow” dive 😉
… like the idea of repurposing that time
spectranaut_: how about next week?
… next week! let’s do it, no objections
non-focusable widget roles nested within elements with children presentational
spectranaut_: yay, github-bot
… from giacomo-petri
giacomo-petri: I want to update that is not just about widget roles, but everything in general within roles that allow presentational children
… right now, UAs are all exposing nested elements to AT
… even though the parent specifies presentational children
… I understand why UAs are doing it, but it still conflicts with the spec
spectranaut_: hasn’t this conversation happened before? that we should cross-reference?
scott: looking through backlog, because I think you’re right
jcraig: I recall a convo with aaron
… maybe some things to consider there are strong native semantics for focusability
<scott> here is one related issue: w3c/
jcraig: because right now UAs do respect native focusability
… the ARIA spec may not account for that
giacomo-petri: we have conflict resolution
jcraig: but it might overlap with a different section about strong native semantics
… for example `required` attribute overriding `aria-required`
… but it still may not account for this
jamesn: Chromes started this by exposing button children
… related to summary/details
… because HTML allowed <summary> to be stuffed
scott: there was some discussion we had in WG meetings about “do all roles really need to be exposed?”
… for example a <main> inside a <button>
jcraig: I remember some of this discussion being related to `aria-hidden` semantics, and its similarity to `presentation` behavior
… things that `aria-hidden` from the a11y tree, until it must be exposed by virtue of something taking focus
<scott> w3c/
scott: I just threw another even older issue in ☝🏻
… I’ll throw these into giacomo-petri’s issue and any others I find, to consolidate
… thank you for raising this again, giacomo-petri
<jcraig> Github: w3c/
<jcraig> GitHub: w3c/
spectranaut_: seems like we should resolve this
… maybe we can, in the next 30 min
… do we want to figure out what cases we need to remove children: presentational from? to align with current UA behavior?
scott: while browsers “don’t” respect it, I know that JAWS does
… and have had multiple conversations with them where they expressed concerns
<Zakim> jcraig, you wanted to mention the "browsers don't support it" may be more nuances... e.g. most input elements?
scott: jcraig, can you recall if someone were to put a heading inside a button, can VO navigate into it?
… definitely not on iOS
jcraig: certainly not a native button
… but maybe a <div role="button">
… browser support will be varied
scott: we should still interrogate these cases carefully
spectranaut_: should we try to think of a list of cases?
… maybe figure out what kind of investigation to do with SRs? Reach out to them?
jamesn: Mel was going to look into this
… I don’t want to tackle this just for `button`; we should look at all the elements that do have presentational children
… and figure out which ones we might want to allow nested interactives, and which ones we certainly don’t
spectranaut_: do validators validate this?
jamesn: yes
… in some cases
scott: yes, some cases, but they don’t catch everything
… we started to try to make this normative in ARIA-in-HTML but didn’t finish
… axe put some checks in and then pulled them out because of uncertainty
… just also found #1455, which might be related
… about `role="image"`
giacomo-petri: to jamesn’s point, think about a heading inside of a button
jamesn: if it’s something non-interactive, then you can just flatten it
<jcraig> Scott's referenced issue above: w3c/
jamesn: you’ll remove semantics, but you won’t necessarily 100% break something
spectranaut_: the main problem we’re trying to solve is that people want to nest interactives
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>`
… and maybe we want to consider accommodating that
scott: parsing will prevent native interactives from being nested
… but that can still be defeated with Javascript
… 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
spectranaut_: no clear path forward for this
… would be good if someone could champion this
scott: giacomo-petri, would you like to team up on this?
jamesn: definitely worth doing, but needs a good plan behind it; testing, investigation, etc.
scott: I’ll take assignment, I’ve already begun to do the research
giacomo-petri: I will help
pkra: and my axe!
<giacomo-petri> w3c/
spectranaut_: any other topics, or should we start spring cleaning?
giacomo-petri: somewhat related ☝🏻
… talks about presentational, allowed children, so could potentially be related
… started creating a table with ideas/suggestions
<spectranaut_> shttps://
<spectranaut_> s\https://
w3c/aria#2685
<spectranaut_> Github: w3c/
spectranaut_: can you explain the table, giacomo-petri?
giacomo-petri: the initial intent was to recognize the uselessness of having a radiogroup without radio buttons inside
… but if we think about all the other roles that require specific accessibility descendants
… for example an empty feed with no articles
<jcraig> seems like the issue should be renamed, since the scope is bigger than radio
giacomo-petri: could be okay if the articles are loaded asynchronously
… but if you define a table, you definitely need table headers from the get
… so in the table, I tried to distinguish
… and made suggestions for each
… for example, data table versus presentational table
… there are roles without direct HTML counterparts
… for example ARIA’s radiogroup role versus native fieldset
spectranaut_: I see, you wanted to introduce the idea of “required accessibility children”
jamesn: I’m not sure I understand the content scenario differences for empty/asynchronously loaded parents
giacomo-petri: if you declare a table, then you need — at a minimum — table headers. But you don’t necessarily need rows immediately, because those can be added later; the empty table structure is still valid
Adam_Page: q+
jcraig: I recall a few years ago required owned elements
… with aria-busy
… an empty list
jamesn: we removed “required own elements” entirely and it morphed into allowed children
pkra: I also fall on the “be more permissive” side of things
… reminds me of convos we’ve had about things in the spec being more WCAG concerns, but ARIA shouldn’t be the ones trying to enforce
<pkra> no disagreement there :D
spectranaut_: thanks for your thorough investigation, giacomo-petri
<spectranaut_> RESOLVE: We will not change the spec and allow for Required Accessibility Parent Roles to have no children.