Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
giacomo-petri: I went through the allowed a11y roles; suggestion #1 is more obsolete compared to the others. I tried using a11y children to clarify, for example, generic intervening (and role=none) are also allowed. Perhaps we can discuss in the next meeting
… right now, I'm keeping it as is but potentially, it could be a point of discussion
pkra: I think it should be split up into an editorial issue, and author MUST statements
giacomo-petri: This one is editorial; assuming children is the same as "accessibility children" which is a point of discussion
pkra: I've already taken a look; it's about the move towards using "accessibility children" which we (ARIA WG) haven't gone through the move of cleaning it up comprehensively in the spec
spectranaut_: Can look at this as editorial
HaTheo: I'm happy to take a look
<spectranaut_> w3c/
HaTheo: ARIA PR #2833 is editorial
spectranaut_: I'll take a look at merge it since it's core-aam
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
HaTheo: For WPT #60778, I looked at CDP and their API, and support in Chrome for getting a11y properties. I added the accessibility protocol part, and standard functions you call in a test to add those. Chrome is actually doing well, just a couple places I saw errors
… saw aria-actions is working in Edge
… please take a look at it, but if it's duplicative let me know
spectranaut_: I didn't know that Chrome DevTools Protocols (CDP) was available
HaTheo: Can add indication that it's experimental but it does seem to run tests pretty well
jcraig: For WPT #60533: we've got two positive reviews but Ben had a comment on something that wasn't responded to. Is that resolved/updated?
HaTheo: I haven't resolved that yet, happy to uncomment it. There's not support for any browser yet (toggle pattern)
spectranaut_: Let's leave the assert(), it's OK for the test to fail
HaTheo: I'll make an amendment to my last commit and add this back in
HaTheo: The Invoke pattern is an interesting one, I'll take a look at that one later
spectranaut_: Did you run these tests locally as well, Ben?
benbeaudry: No, but found a bunch of issues in Chromium (already filed a bug)
sarah: We should consider the possibility that the spec also has issues; e.g., for toggle, wrong semantics on menuitemradio
jcraig: WPT #60504 may be ready to merge
HaTheo: I've simplified this one, since we can add things in later
spectranaut_: I'll look and merge
jcraig: For WPT #59768, I'm still reviewing this one from Tyler. It's getting close
spectranaut_: Ping me when it's ready
jcraig: We have a 2nd reviewer, but I was going to merge it when it's ready
… we've got two approvals on yours WPT #60410
spectranaut_: I haven't merged this one yet because I wanted to open bugs on the browsers and then merge it. But no reason to necessarily do that
… thanks for pinging me, I think we can merge this
Daniel: I used to be a WPT repo admin, but not anymore
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jcraig: I may have a potential one regarding aria-actions and focus which has outstanding questions. We also have 3 implementations so seems like a good opportunity for a deep dive
spectranaut_: Did we discuss ARIA #2791 in a meeting, Matt?
Matt: There's a lot of history here that started with overscroll discussion. This is one of those issues where we need to get NVDA reps involved if we're going to come up with any agreement on what we're going to put in spec
spectranaut_: This is a matter of getting the right folks in the room. Has anyone started that email thread?
Matt: Is that something you or James N. would do?
… as long as we have a time horizon for this, we should have some kind of plan
jamesn: Sure (I can do this)
… I'll ping you (Matt) to formulate what we want to say/ask
aria-actions: handling focus when actions are synthetically triggered
spectranaut_: What are the next steps? James C. was suggesting a deep dive that Jamie Teh could attend
sarah: Just a deep dive, or perhaps a call?
jcraig: The best time would be 3 or 4PM PT (and preferably not on Friday, July 3 is a US holiday)
spectranaut_: Can someone respond and propose a time? I'm OOO next week
Matt: Can we come up with a couple proposed times and put them in the email thread to make sure they work for Jamie Teh. I'm available Mon/Tues next week, the next following week is more flexible
<Jacques> I'm on an engineering rotation 9-5, so the later in the day the better, but I can make things work if needed.
jcraig: Tyler Wilcock is OOO, but I'd like Dominic Mazzoni on there
sarah: Attendees will be James Craig, Dominic Mazzoni, Matt King, Jacques Newman, myself and Jamie Teh
Add explicit language and direction metadata to AriaNotificationOptions
Clay: I added this to the agenda, ran over in triage last week. Sarah had commented (thanks), and I as well pulling in previous context. Wanted to open it to the ARIA WG to understand the ask, to see if this is something we want/could support. Proposal is to add a lang attribute or action along with ariaNotify calls to designate a different language than the sending element
… don't see a use case for this, and why we want messages to have arbitrarily different language then sending element and why we would want this
jcraig: You can also modify the lang of the sending element
Clay: There are other options without additional customization
jcraig: Don't agree with the addition of adding a text direction (there's no ARIA text direction property somewhere else is there). From the discussion, it sounds like we're going to decline this request (don't need it, other ways to do it). Calling this as we consider future expansions, and avoiding ARIA (e.g., should just be TextDirection dir, or actually DOMString dir, and not include ARIA)
Daniel: We shouldn't close the issue yet; based on the group's consensus that it's not needed, I would expect the issue to include rationale as to why (e.g., Sarah has explained). We should comment on the alternative ways to do that
spectranaut_: I won't close, I will comment noting if it's enough that there's other ways to do this
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
Allow treeitems to omit groups by specifiying aria-level, aria-posinset, and aria-setsize
<jcraig> d/Don't agree with the addition of adding a text direction/For future reference, even if we were to add a text direction, we should not prefix ARIA here as proposed AriaTextDirection/
HaTheo: I wrote some tests and in this case, tested if the level was respected; it is, but it doesn't end up in a hierarchy. This will dictate if the other test will go from being a draft to another PR
… I don't know if the hierarchy is important; if it is, we probably need to file a test and bugs on browsers otherwise, this one is good to go
spectranaut_: Is it a flat tree? If you look at the children, they're not re-arranged
sarah: I was comparing the a11y API output vs. a thing done with children, and I think that was the same. In the platform a11y API, you don't get hierarchy
… can just ensure that setsize/posinset/level are mapped correctly
HaTheo: I can find other examples in WPTs; in my manual testing across Windows, Mac, Linux and different screen readers, and I had no issues in having level read out
sarah: I also have a flat tree example, but it's not much more complex than what you already have
<sarah> https://
HaTheo: If you can send me an example, I'm happy to use that
Matt: When I was looking at this PR, if there is a repair one thing I don't see here is what the author requirements are for setting posinset. I don't know what happens when somebody numbers their posinset for the entire tree, e.g., 100 items that aren't all at aria-level=1 but you do aria-posinset at different values. Does that override what browsers calculate?
… when you get to a treeitem in a subgroup, you're used to hearing item #1 in the subgroup. The spec may not say it's a mistake, can't find where in spec it tells authors how to make it work for users
sarah: That's not different from how it works now; even now, you can override how it works for posinset/setsize. If you're in a tree, you could have linear numbering and then jump to something like 150
… that's why you would define posinset/setsize, it's an intentional part of the feature. Authors can mess it up
Matt: The part that's confusing is if the author doesn't want to put in in groups and use posinset instead, they have to have some kind of understanding what the requirements are for posinset to work the way we (ARIA spec) intend
<Zakim> jcraig, you wanted to discuss the history of why this level/set exists outside the parent/child relationship
Matt: I can't find where it says in spec where browsers do and what's expected
jcraig: I was going to talk about the history of why this pattern was done. It's possible Matt was in the group
… at the time, there was no such thing as allowing re-rendering/re-ordering of child nodes (used to use the phrase "don't cross the streams" as people thought it would cause looping issues). We then figured out ways to avoid that problem, and now we can re-order items in the a11y tree separate from the DOM
… this a11y pattern was developed prior to this evolution. So, aria-level/aria-posinset was a way to convey to ATs that there were re-usable elements that were in a different order and nesting for patterns such as trees (but not expanded out to the entire DOM since it's a set). Even though these (elements) end up being sibling/children, ATs can convey them accurately
… the fact it's not listed is probably just an editorial oversight
sarah: The reason they wanted a flat tree at Microsoft is due to virtualization which is easier and more performant. It's more likely you'd be heavily managing setsize/posinset/level in a flat tree, rather than a nested/hierarchical one
… even in a nested one, need to know the same things so I'm all for adding more information on how to do that but don't think it should be a gate on this specific PR
Matt: I may need to re-read the whole treeitem thing. The structure may be explained in a non-normative way
… if you're not using groups, then it seems that it would have to be a normative requirement that you specify posinset/setsize. If it's normative, in that case, then doing that without a normative explanation of what those values should be (how to calculate them as an author) seems like it would be necessary
sarah: There was never anything in the spec that said you couldn't do this; and in fact, we do this relatively widely because it's a lot more performant for visualization. It's not forbidden by spec
… this PR adds clarity, and a browser MUST for calculating aria-level from the DOM (if nested) and also adds an author MAY noting that they can do this. But it doesn't change existing spec MUST/MAYs
… it's not changing any existing requirements
jcraig: As Sarah has mentioned, there are MUST/SHOULD requirements in spec that are tied to language that says "if all items are not present in the document structure..."; if you think you found some RFC MUST/MAY/SHOULD, I would encourage you to file a bug
Matt: Based on what Sarah said, we can make this a separate issue
HaTheo: Wasn't there an issue around standardizing posinset/setsize?
Matt: Yes, that's the deep dive; that one is for areas where it's not clear like menus. For trees, I don't think there's any questions since screen readers have always done the same thing
jcraig: Mac AppKit tree controls are effectively a type of single column collapsible table (essentially a single-column tree grid)
aria-actions: handling focus when actions are synthetically triggered
Impact of AI technologies on Accessible Rich Internet Applications Working Group's mission
spectranaut_: If anyone has any thoughts, you can put in this issue or we can talk about it now. Daniel?
Daniel: This is related to how it might affect the mission of the ARIA WG; the big question is how everyone is using AI. There's a danger of using ARIA to "please agents", and how LLM makers are portraying ARIA. A pro could be that agents are able to remediate UIs based on knowledge that can be scraped from specs and other resources like APG
Clay: Practical day to day for how we execute this work, we briefly discussed Zoom AI note-taking. I've been on calls where not everything is minuted, how can we more careful on things being stricken/not minuted
Jacques: +1, in the groups I'm in that use AI note-taking, not as useful as human transcription. For now, we should use the best tools (i.e., human notetaker)
jcraig: +1, my experience with auto transcription is that for general conversation is good but technical/domain-specific conversations, you need domain-specific training data (true for ARIA WG)
JohnJansen: Some WGs don't allow AI transcription due to government contracts. I've been experimenting with a tool that listens to active Zoom tab, and types into IRCCloud but doesn't submit so types for you but allows you to review before submitting (doesn't identify people as well)
… could be something that works for the ARIA WG
<Jacques> that sounds interesting to me, again, I'm for using the best tools available.
jcraig: That is how human professional transcribers work today; they use AI-based transcription and augment on the fly (human + machine based transcription)
Matt: Back to Daniel's issue and our mission, one possible solution to this issue is to determine that we don't need to make any modifications to the ARIA WG's mission, and what it might mean to come to the conclusion that AI doesn't change that mission
… we're being told to think of agents as "people-like"; but as a consequence of supporting people, we're also supporting agents perhaps but this may be a big logical leap
Daniel: I don't think we should be changing the mission; the agent aspect you (Matt) mentioned is something we should pay attention to. We want to serve the agents and please them but we may be perpetuating bad uses cases of ARIA
Matt: For example, we have an open PR in the Authoring Practices Guide (APG) to make an MCP (Model Contextual Provider/Protocol) which we summarily decided against