17:01:01 <RRSAgent> RRSAgent has joined #aria
17:01:05 <RRSAgent> logging to https://www.w3.org/2026/03/19-aria-irc
17:01:05 <Zakim> RRSAgent, make logs Public
17:01:06 <Zakim> Meeting: ARIA WG
17:01:06 <pkra> present+
17:01:11 <jamesn> Agendabot, find agenda
17:01:11 <agendabot> jamesn, OK. This may take a minute...
17:01:11 <agendabot> agenda: https://www.w3.org/events/meetings/690d057f-db6d-4169-b13f-68d7f1336b59/20260319T130000/
17:01:11 <agendabot> clear agenda
17:01:11 <agendabot> agenda+ -> New Issue Triage https://tinyurl.com/yhksws4u
17:01:12 <agendabot> agenda+ -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-03-12+repo:w3c/aria&type=Issues
17:01:15 <agendabot> agenda+ -> WPT Open PRs https://bit.ly/wpt_a11y
17:01:17 <agendabot> agenda+ -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates
17:01:20 <agendabot> agenda+ -> check mappings and a11y of HTMLButtonElement's declarative scroll commands https://github.com/w3c/html-aam/issues/600
17:01:23 <agendabot> agenda+ -> Change tooltip to name prohibited https://github.com/w3c/aria/pull/2670
17:01:26 <agendabot> agenda+ -> Expectations for aria-hidden and focused elements https://github.com/w3c/aria/pull/2181
17:01:39 <giacomo-petri> giacomo-petri has joined #aria
17:01:58 <spectranaut_> spectranaut_ has joined #aria
17:02:22 <spectranaut_> agenda?
17:03:20 <pkra> scribe+
17:03:23 <pkra> zakim, next item
17:03:23 <Zakim> agendum 1 -- -> New Issue Triage https://tinyurl.com/yhksws4u -- taken up [from agendabot]
17:03:23 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:03:37 <giacomo-petri> present+
17:03:40 <Jacques> Jacques has joined #aria
17:03:53 <cyns> cyns has joined #aria
17:04:16 <Siri> Siri has joined #aria
17:04:17 <scott> scott has joined #aria
17:04:23 <scott> present+
17:04:31 <Siri> present+
17:04:48 <spectranaut_> https://github.com/w3c/svg-aam/issues/47
17:05:22 <pkra> spectranaut_: a couple of svg-aam issues.
17:05:25 <jcraig> jcraig has joined #aria
17:05:28 <pkra> jamesn: just clearing up the spec, right?
17:05:34 <jcraig> agenda?
17:06:03 <pkra> spectranaut_: the link one sounds like something we want to talk about
17:06:25 <pkra> cyns: we're looking into UA behavior
17:06:39 <pkra> ... html is very permissive.
17:06:52 <Daniel> present+
17:06:54 <Daniel> q+
17:07:15 <pkra> jcraig: webkit will expose links with click handler as clickable but not necessarily as link.
17:07:33 <pkra> jamesn: note the heuristics for chrome on click handlers, too.
17:08:03 <Daniel> q-
17:08:05 <pkra> spectranaut_: next up #2750 logical properties.
17:08:12 <pkra> ... scott responded.
17:09:08 <pkra> pkra: this was a question in a personal conversation. I didn't have an answer. Scott pointed to focusgroup similarity.
17:09:28 <pkra> spectranaut_: others we have discussed already.
17:09:40 <Matt_King> Matt_King has joined #aria
17:09:42 <pkra> ... Daniels' is editorial
17:09:58 <pkra> ... I left a comment for Rahim's issue.
17:10:10 <pkra> zakim, next item
17:10:10 <Zakim> agendum 2 -- -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-03-12+repo:w3c/aria&type=Issues -- taken up [from agendabot]
17:10:10 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:10:18 <Jacques> I can help clarify wrt focusgorup similarity, but we can leave this to when we discuss this in the agenda.
17:10:27 <pkra> spectranaut_: first up the PR cyns mentioned.
17:10:59 <pkra> zakim, next item
17:10:59 <Zakim> agendum 2 was just opened, pkra
17:11:04 <pkra> zakim, close this item
17:11:04 <Zakim> agendum 2 closed
17:11:05 <Zakim> I see 5 items remaining on the agenda; the next one is
17:11:05 <Zakim> 3. -> WPT Open PRs https://bit.ly/wpt_a11y [from agendabot]
17:11:06 <pkra> zakim, next item
17:11:06 <Zakim> agendum 3 -- -> WPT Open PRs https://bit.ly/wpt_a11y -- taken up [from agendabot]
17:11:06 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:11:35 <pkra> spectranaut_:  no new ones
17:11:37 <pkra> zakim, close this item
17:11:37 <Zakim> agendum 3 closed
17:11:38 <Zakim> I see 4 items remaining on the agenda; the next one is
17:11:38 <Zakim> 4. -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates [from agendabot]
17:11:38 <pkra> zakim, next item
17:11:39 <Zakim> agendum 4 -- -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates -- taken up [from agendabot]
17:11:39 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:11:46 <pkra> spectranaut_: any plans?
17:12:22 <pkra> janewman: did we want to do one focusgroup?
17:12:53 <pkra> ... I don't have anything pressing but getting more eyes always helps.
17:13:11 <pkra> spectranaut_: is there a specific aspect we should focus on?
17:13:30 <pkra> janenewman: I just recall the last discussion calling for a deep dive.
17:14:58 <pkra> jcraig: deep dive idea: valerie's work on accacia and rahim's work on accessibility properties. could we use a deep dive for that?
17:15:32 <pkra> spectranaut_: sounds good.
17:15:46 <jongund> jongund has joined #aria
17:15:50 <pkra> ... once things land.
17:15:53 <pkra> jcraig: yes
17:16:48 <pkra> cyns: setting aside some test writing time would also be a good idea.
17:16:59 <pkra> zakim, next item
17:16:59 <Zakim> agendum 5 -- -> check mappings and a11y of HTMLButtonElement's declarative scroll commands https://github.com/w3c/html-aam/issues/600 -- taken up [from agendabot]
17:17:15 <pkra> spectranaut_: we briefly discussed this a few meetings ago.
17:17:27 <pkra> ... we ended with questions.
17:17:41 <pkra> ... in particular, what's announced when these buttons are clicked.
17:17:50 <pkra> ... how is scrolling announced.
17:17:55 <pkra> ... there's been an update.
17:18:23 <pkra> daniil: to recap, we want to add scroll events for html buttons.
17:18:36 <pkra> ... the question is how the changes in the scroller are announced.
17:18:38 <jcraig> Explainer update here: https://github.com/danielsakhapov/declarative-scroll-commands-for-html-explainer/blob/master/README.md
17:18:48 <pkra> ... first proposal is that it shouldn't be connected to the buttons at all but separate.
17:19:14 <pkra> ... proposal: snap change  event. Contains snap target.
17:19:24 <pkra> ... could be used as some way to understand which element is in view.
17:19:46 <jcraig> Deep link to scrollsnapchange: https://github.com/danielsakhapov/declarative-scroll-commands-for-html-explainer/blob/master/README.md#currently-possible-solution-scrollsnapchange
17:19:47 <pkra> ... problem: it only works with snappable containers, with limited implementations.
17:20:06 <pkra> ... 2nd proposal: declarative live regions.
17:20:33 <pkra> ... live region would have idref to scroller.
17:21:11 <jcraig> deep link to Daniil's new aria-live-source proposal https://github.com/danielsakhapov/declarative-scroll-commands-for-html-explainer/blob/master/README.md#proposed-extension-declarative-live-regions-aria-live-source
17:21:18 <pkra> ... the bowser could detect which element is in view, we can extract which element is active, take its label and without changing the DOM the browser sends the even to the OS that something has changed, e.g., with label.
17:21:49 <pkra> ... this would allow us to avoid requiring changes to AT
17:22:13 <pkra> ... problem is that you cannot really change much.
17:22:21 <pkra> ... but it's simple to subscribe.
17:23:18 <pkra> ... if this lacks flexibility, then a new event might be an option. Firing on any kind of scroller. Browser gives you the elements in view. You can then format it as you want and update the aria-live content.
17:23:25 <spectranaut_> agenda?
17:23:26 <jcraig> q+ to ask why the aria-live wouldn't already work?
17:23:29 <spectranaut_> q?
17:23:33 <scott> q+
17:23:39 <spectranaut_> q+ matt
17:24:03 <pkra> jcraig: thanks for the explainer updates.
17:24:52 <pkra> ... regarding aria-live-source. What's currently possible with aria-live, in particular atomic, and the events you described, I think you can already do this.
17:25:59 <pkra> ... if it requires JS, then it should work already.
17:26:34 <jongund> jongund has joined #aria
17:26:49 <pkra> daniil: the goal is to have no JS needed. The idea is that aria-live is subscribed to the scroller. Then the aria-live is populated automatically by the label of the element in view.
17:26:55 <pkra> jcraig: do you update the label?
17:27:13 <pkra> daniil: no, the label comes from the element in view.
17:27:40 <pkra> jcraig: thanks for clarifying.
17:27:50 <spectranaut_> ack jcraig
17:27:50 <Zakim> jcraig, you wanted to ask why the aria-live wouldn't already work?
17:27:54 <spectranaut_> ack scott
17:28:15 <pkra> scott: option 2 seems a bit more elegant, especially with aria-notify.
17:28:37 <pkra> ... for option 1, the markup seems a bit confusing to me.
17:28:43 <filippo-zorzi> filippo-zorzi has joined #aria
17:29:06 <pkra> ... I can imagine aria-live-source acting a bit like labelledby. It's different in that you're not putting anything into it.
17:29:19 <pkra> ... of course we want the accname for whatever is shown.
17:29:35 <filippo-zorzi> present+
17:29:44 <pkra> ... that could be done by role=status or alert right now if labelledby would point to the ID which changes
17:29:55 <pkra> ... not saying that's how it worked. just conceptually similar.
17:30:12 <pkra> ... I wonder why wouldn't we just use aria-notify since that's sort-of the future of aria-live / live regions.
17:30:24 <pkra> ... and since we don't want to add new features that aren't testable.
17:30:34 <pkra> ... anyway, I'm more in favor of option 2.
17:30:34 <spectranaut_> ack scott
17:30:39 <jcraig> q+
17:31:17 <pkra> matt: on option 2. you said you have flexibility here.
17:31:50 <pkra> ... is option 2 also not requiring JS to get this kind of flexibility?
17:32:15 <pkra> ... or is it the AT that's more flexible in presenting or filtering.
17:32:31 <pkra> daniil: I mean just the author.
17:32:45 <pkra> ... in the first option with aria-live-source, it's the browser that sources things.
17:32:58 <pkra> ... in option 2, it's the author.
17:33:36 <pkra> matt: so option 2 needs JS to format?
17:33:54 <pkra> jcraig: yes.
17:34:08 <pkra> matt: ok, then it doesn't achieve the objectives of option 1 but gives the flexibility.
17:34:17 <spectranaut_> After the third bullet in this section is the 2nd example https://github.com/danielsakhapov/declarative-scroll-commands-for-html-explainer/blob/master/README.md#extra-thoughtspossible-extensions
17:34:52 <spectranaut_> q?
17:34:54 <spectranaut_> ack masonf
17:34:58 <spectranaut_> ack matt
17:35:01 <spectranaut_> ack jcraig
17:35:28 <pkra> jcraig: if it's really as simple as "DOM announcement of an aria-label", could it not be done from the scroll snap change?
17:35:40 <pkra> ... or is there a downside?
17:36:06 <pkra> matt: how would AT handle that?
17:36:24 <Francis_Storr> Francis_Storr has joined #aria
17:36:30 <pkra> ... announcement with properties like aria-notify to enable AT to properly filter or control presentation?
17:37:25 <pkra> jcraig: maybe not even aria-notify. Just on scroll snapped event, we could say that the expected behavior is triggering a live region event with the computed label.
17:37:35 <pkra> ... it's then separate from really both live and notify.
17:37:52 <spectranaut_> q+
17:37:58 <pkra> ... it just gets routed to the platforms. maybe using live-like treatment under the hood.
17:38:08 <pkra> daniil: I thought it should be opt-in.
17:38:28 <pkra> jcraig: does it need to be opt in? Can we think of reasons it's too chatty or users don't want it?
17:38:38 <pkra> matt: feels like at least authors should opt in.
17:38:53 <pkra> ... when they do want a specific behavior.
17:39:12 <pkra> ... often what's snapped into view is a container that contains a lot of stuff, may not be named meaningfully.
17:39:19 <pkra> ... e.g. subset of a collection
17:39:31 <pkra> ... like a few thumbnails at once
17:39:50 <pkra> ... might need author control.
17:40:07 <pkra> jcraig: if they label the items, they could have granular control.
17:40:42 <pkra> ... there might be times where it's chatty but users would be able to cancel e.g. speech updates.
17:40:51 <pkra> ... but you're sitting on a button that you're activating.
17:41:03 <pkra> ... and by default you get an update.
17:41:17 <scott> q+
17:41:27 <pkra> matt: right. I think there might be a situation where authors want more control than the name of a container.
17:41:44 <pkra> ... generating containers and naming them might be a bigger ask.
17:41:57 <pkra> spectranaut_: recap, jcraig is suggesting making option 1 but as a default.
17:42:26 <pkra> jcraig: for option 2, you could use prevent default .
17:42:29 <spectranaut_> ack scott
17:42:34 <spectranaut_> ack spectranaut_
17:43:00 <jcraig> q+
17:43:04 <pkra> scott: I'm more in favor of jcraig's revision of option 1. Not asking authors to create an aria-live element somewhere.
17:44:11 <pkra> ... from a quick test, if I understand the feature correctly, then putting aria-labelledby on a visually hidden  status element, pointing to it, hiding/showing  that. It's announcing the correct thing. So it seems we could already do option 1 easily.
17:44:17 <spectranaut_> ack jcraig
17:44:48 <pkra> jcraig: just to clarify. this will obviously depend on how my suggestion is written up.
17:44:50 <Matt_King> q+
17:45:17 <pkra> ... I think the request to make this opt-out could be possible.
17:45:56 <pkra> ... and yes, notifications are not testable. But this seems more like a new behavior not a new feature as such.
17:45:57 <spectranaut_> ack Matt_King
17:46:17 <pkra> matt: I like this direction, in particular if there is an opt-out.
17:46:26 <pkra> ... and if the events help identify the source.
17:46:51 <pkra> ... e.g. when we talk to AT vendors, they tend to need a way to identify where the events come from.
17:47:14 <pkra> spectranaut_:  any other questions right now?
17:47:59 <pkra> daniil: having this on by default seems risky. This proposal is independent of the buttons themselves. If we're discussing this, we should be able to apply this to any scroller.
17:48:08 <pkra> ... or should it depend on the button specifically?
17:48:24 <pkra> jcraig: you're saying the announcement would happen in many other scenarios?
17:48:50 <scott> q+
17:48:58 <pkra> daniil: yes. And also not just on snappable. These buttons can be used outside snapping. E.g. scroll to TOS.
17:49:32 <pkra> jcraig: I think it should not apply to any scroller. Snapping has a more specific intent.
17:49:50 <pkra> daniil: but then scroll-snap-end event is sufficient?
17:50:09 <Matt_King> q+
17:50:18 <pkra> jcraig: then the question might be if authors can prevent the announcement.
17:50:33 <pkra> daniil: it just gives you the even, it doesn't update anything, just gives you the information
17:50:42 <pkra> jcraig: I have to spend more time on the opt-out considerations.
17:51:04 <pkra> ... I might be misunderstanding this.
17:51:35 <pkra> daniil: how would you envision the opt-out?
17:52:12 <pkra> jcraig: usually when you change focus, things get trampled over.
17:52:22 <spectranaut_> ack scott
17:53:07 <spectranaut_> zakim, close queue
17:53:07 <Zakim> ok, spectranaut_, the speaker queue is closed
17:53:28 <pkra> scott: clarifying question: this may be unwanted, e.g., when multiple items are in the available viewport. Say in a TOC. If you scroll, the other elements might not be out of view. Figuring out which accname to announce.
17:54:46 <pkra> ... in the carousel example, it's often assumed that if you only show a particular panel at a time, the off-screen content should be hidden.
17:55:09 <pkra> ... but from other work on carousel, that content is not necessarily hidden, so it might still contribute.
17:55:32 <pkra> ... I still feel like aria-notify is still the better path to follow.
17:56:20 <jcraig> I'm coming back around to option 2
17:56:22 <pkra> matt: re "all scrollers". It matter a lot what's triggering a scroller. In the case of the button, it's useful because it's outside the controller.
17:56:30 <jcraig> the new js event
17:57:06 <pkra> ... if the focus is inside, but say a keyboard event scrolls a feed you're inside, then announcements would be very confusing.
17:57:21 <pkra> ... it matters a lot.
17:57:55 <pkra> jcraig: thanks. I'm coming around back to your point of view.
17:58:29 <spectranaut_> agenda?
17:58:29 <pkra> daniil: thanks. if scott could add a comment. And perhaps we could split out the buttons.
17:58:48 <Francis_Storr> present+
17:58:54 <pkra> zakim, close this item
17:58:54 <Zakim> I see a speaker queue remaining and respectfully decline to close this agendum, pkra
17:58:59 <pkra> zakim, next item
17:58:59 <Zakim> I see a speaker queue remaining and respectfully decline to close this agendum, pkra
17:59:09 <pkra> q?
17:59:12 <pkra> ack Matt_King
17:59:14 <pkra> zakim, next item
17:59:14 <Zakim> agendum 6 -- -> Change tooltip to name prohibited https://github.com/w3c/aria/pull/2670 -- taken up [from agendabot]
17:59:28 <pkra> spectranaut_: scott could you take a look at my comment?
17:59:34 <pkra> zakim, end meeting
17:59:34 <Zakim> As of this point the attendees have been pkra, giacomo-petri, scott, Siri, Daniel, filippo-zorzi, Francis_Storr
17:59:36 <Zakim> RRSAgent, please draft minutes v2
17:59:37 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/19-aria-minutes.html Zakim
17:59:44 <Zakim> I am happy to have been of service, pkra; please remember to excuse RRSAgent.  Goodbye
17:59:45 <Zakim> Zakim has left #aria
18:20:56 <jongund> jongund has joined #aria
18:38:14 <scott> the values for aria-autocomplete are inline, list, both, none
18:44:38 <jongund> jongund has joined #aria
20:06:20 <jongund> jongund has joined #aria
20:39:02 <jongund> jongund has joined #aria
22:10:01 <jongund> jongund has joined #aria
22:40:11 <jongund> jongund has joined #aria
23:31:18 <jongund> jongund has joined #aria