Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: first up #2749. just something I created just now. It's for the editors' meeting.
… then #2744 from spectranaut_
spectranaut_: just an experiment I did. This idea comes up once in a while. But I'm not sure if it's worth it.
… maybe other AAMs could benefit but not sure.
<np-at> I'd be potentially interested; not sure how much time I'll have though
jamesn: next #2742 from James Craig. A document on heuristics.
… this is about known heuristics.
… I think we can merge this and continue there.
… feel free to add.
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: anything we should discuss?
spectranaut_: I'd like review on my PRs
… PR 2744
… would love for scotto to take a look
<spectranaut_> web-platform-tests/
spectranaut_: correction: PR 57696 in WPT
jamesn: anyone specific?
spectranaut_: anyone who might write AAM tests
… this is getting close to merge. The RFC is almost done.
cyns: I'll take a look
jcraig: note that the invitations need accepting (and are easy to miss)
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: any idea?
pkra: issue 2748 on dev tools. From the editors' call.
jamesn: yes, but needs the right people.
… maybe a F2F is better.
… e.g. TPAC Dublin
jcraig: it's a small group.
dgrogan: ours is all open source.
jcraig: I think that's true for most browsers.
… review time is easier, too.
jamesn: maybe some of these are feasible to prototype.
dgrogan: a lot of this stuff seems doable. And reviewing is definitely easier.
jamesn: great to hear. Esp. the new IDL things would be important to get visible.
authoring errors, name-from-author, and exposure
spectranaut_: let's keep that issue open, add F2F and continue to to gather ideas.
pkra: this issue wasn't triaged. That's why I added agenda.
… I think at least we need to update aria claiming that form require a name. But I think there might be a discrepancy with implementations.
jamesn: I agree that core-aam is confusing
spectranaut_: agreed.
scott: could we simplify it. Just have one mapping table and identify that if it has a name, expose it as a landmark.
spectranaut_: what does it mean to be a form but not a landmark?
scott: there is an XML property in some of the mappings where you can explicitly call something out as a landmark.
… that's roughly the intent.
spectranaut_: right. but for AX API it's unclear.
spectranaut_: I can take that on. Is that enough?
pkra: right, the second part of my top card is a bit wider. Essentially if roles with only name-from-author and no name gets exposed.
scott: we tried to make this change a few years back to expose forms without them needing to be landmarks. Maybe we didn't do enough in finishing the work.
… maybe we should consider reverting, going back to all forms being landmark.
jamesn: I suppose browsers and AT might always have a choice. I don't understand why people have forms without name
… not that they don't exist.
scott: I'd go as far as saying there's no reason to use the role directly.
aria-busy="true" with descendant invalid ARIA structure
jamesn: inside aria-busy, what are the rules for invalid aria markup?
giacomo-petri: in ACT rules, we allowed everything inside aria-busy
… that seemed to make sense to us but re-reading the spec, it seems uncler.
… e.g. listbox.
… having the text "loading" inside
… in theory, AT should ignore what's inside.
… but we see developers using the content in, say, a listbox.
noah: I don't think aria-busy is meant for a loading status, right? You'd still be expected to provide an accessible loader information.
… is it excluded though? If it is, then invalid markup seems fine.
scott: I was discussing this with vispero. JAWS treats it like aria-hidden, which makes it pointless. Others don't.
… this ACT rule feels like a loophole for good and bad actors.
… in manual audits we found lots of aria-busy avoiding invalid markup to show up in automated tests
jamesn: if they don't use busy, aria-hidden seems to do the job?
noah: but it will throw other errors. I understand Scott's point.
jamesn: right. But if you can tab to it, then it may or may not be in the tree
<Zakim> jcraig, you wanted to mention it's intended to suppress required child validation errors during loading states, too. in practice, it varies. Should be testable in WPT soon, so we shouldn't change it until then... NNF™
<jamesn> Act jcraig
jcraig: it is also intended to prevent required child errors.
… in practice, it varies whether it's conveyed to the user.
… there were a number of things in ARIA 1.0 that didn't work out or proved not ideal.
… I don't think we should change much unless we can test them. But we have some changes coming that help with that.
giacomo-petri: by removing the required accessibility children, we alleviate some problems. We already allow no children.
… with aria-busy we have other use cases. E.g. on body.
… in our platform, we treat aria-busy as "everything inside needs manual check". E.g. in body this is obviously important.
<jcraig> https://
giacomo-petri: with the current ACT rule, we cannot expect any check.
<jcraig> If changes to a rendered widget would create a state where the widget is modifying Allowed Accessibility Child Roles during script execution, authors MAY set aria-busy to true on the widget during the update process. For example, if a rendered tree grid required a set of simultaneous updates to multiple discontiguous branches, an alternative to replacing the complete tree element with a single update would be to mark the tree busy while each
<jcraig> of the branches are modified.
jcraig: in the quote from the spec before the tables seems to handle some of this.
jamesn: we'd need to look into the blame to check.
jcraig: I think that was the context of that change.
jamesn: we may find that it might be less useful nowadays.
… but as Scott pointed out this does get misused to suppress errors. Though I think developers may always find some way to do that.
noah: we could also allow for an explicit naming when using aria-busy. That might help to identify misuse.
jamesn: I'm not sure how useful testing is while there's an aria-busy state.
<Zakim> jamesn, you wanted to say there are no required children any more right?
jamesn: if anyone wants to try a PR, feel free.
… perhaps the last paragraph can be improved.
giacomo-petri: I can try but I would make it permissive, right?
jamesn: right. And perhaps aria-busy is a problem if it persists.