17:00:01 RRSAgent has joined #aria 17:00:06 logging to https://www.w3.org/2026/03/26-aria-irc 17:00:06 RRSAgent, make logs Public 17:00:07 Meeting: ARIA WG 17:00:08 Agendabot, find agenda 17:00:08 jamesn, OK. This may take a minute... 17:00:37 Sorry, I did not find an agenda. 17:01:24 present+ 17:01:47 Jacques has joined #aria 17:02:04 agenda+ [New PR Triage](https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-03-19+repo:w3c/aria&type=Issues) 17:02:04 agenda+[WPT Open PRs](https://bit.ly/wpt_a11y) 17:02:04 agenda+ [Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates) 17:02:04 agenda+ [Are there use cases for logical properties in aria-orientation?](https://github.com/w3c/aria/issues/2750) 17:02:05 agenda+ [Expectations for aria-hidden and focused elements](https://github.com/w3c/aria/pull/2181) 17:02:34 present+ 17:02:37 scribe: Rahim 17:02:49 regrets+ Val 17:02:54 scott has joined #aria 17:03:14 dgrogan has joined #aria 17:04:04 present+ 17:04:15 giacomo-petri has joined #aria 17:04:17 zakim, next item 17:04:17 agendum 1 -- [New PR Triage](https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-03-19+repo:w3c/aria&type=Issues) -- taken up [from jamesn] 17:04:17 I can't comment on that because it doesn't look like a github issue to me. 17:04:27 present+ 17:04:35 pkra has joined #aria 17:05:22 jcraig has joined #aria 17:05:43 present+ 17:05:44 agenda? 17:05:53 jamesn: ARIA #2756 looks editorial. Part of the large aria.js PR #2501. Is it ready of review? 17:06:17 pkra: Asked Danielle if we can have a diff, put a manual diff at the bottom. Would be nice if we had an official diff 17:06:28 ...essentially it fixes some code that incorrectly generates the informative tables 17:06:39 jamesn: Daniel, can you create a real diff? 17:06:49 Daniel: I will try to write it 17:07:24 ...perhaps next week 17:07:34 jamesn: can you assign me as reviewer after the diff is done? Thanks 17:08:02 jamesn: Peter has already reviewed ARIA #2754; should we have other reviewers? 17:08:28 Matt_King has joined #aria 17:08:38 giacomo-petri: yes; not sure what we should use here (i.e., SHOULD language) 17:09:13 pkra: my criticism is not around MUST, it's the inability to test the MUST (automatically). How do we know what the author has done 17:09:22 ...seems more WCAG-related rather than ARIA 17:09:41 giacomo-petri: yes, but the intent of `aria-busy` is to make users aware when content is updating 17:10:07 pkra: perhaps the ARIA specification isn't the place to specify it's a MUST 17:10:31 Matt_King: seems like an ARIA problem when `aria-busy` is true 17:10:59 q+ 17:11:26 Matt_King: can add me as a reviewer. Should it be agenda+? 17:11:39 jamesn: I don't think so. Any other reviewer volunteers? 17:12:24 Rahim: should this be a heuristic? 17:13:17 jcraig: the only way I see it being a heuristic is if the relaxed rules were different than what's codified in spec. Sometimes that's because there's differences in ambiguity (or difficult to spec it due to inherent complexity) 17:13:36 Ack ra 17:13:45 zakim, next item 17:13:45 agendum 2 -- [WPT Open PRs](https://bit.ly/wpt_a11y) -- taken up [from jamesn] 17:13:45 I can't comment on that because it doesn't look like a github issue to me. 17:14:57 jcraig: since Scott on the call, will defer to him if there's more to do on WPT #52480, and Adam's comments. Is this ready for re-review, Scott? 17:15:13 scott: I think so 17:15:29 jamesn: why is there stuff here that hasn't been merged? 17:15:39 jcraig: a good think to put on the agenda for the next interop a11y meeting 17:15:43 zakim, next item 17:15:43 agendum 3 -- [Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates) -- taken up [from jamesn] 17:15:43 I can't comment on that because it doesn't look like a github issue to me. 17:16:42 jamesn: two items: gathering ideas for dev tools improvement (might be a good TPAC topic, could be done earlier); scoping focus group to scenarios defined by aria roles and overlap with `aria-actions` 17:17:11 ...a deep dive could help with focusgroup discussion outside of Sarah H.'s conflict 17:17:29 zakim, next item 17:17:29 agendum 4 -- [Are there use cases for logical properties in aria-orientation?](https://github.com/w3c/aria/issues/2750) -- taken up [from jamesn] 17:18:11 I can chat with Sarah about that as well, I'll be likely be working on actions at some point in the near future. 17:18:20 jamesn: we are unsure what this issue means (e.g., `inline`, `block` values) for `aria-orientation` 17:18:51 scott: using `inline` for left/right navigation, and `block` for vertical navigation. Just different terminology 17:20:02 q+ 17:20:12 Stefan has joined #aria 17:20:23 q_ 17:20:26 q+ 17:20:36 keithamus: if you set `writing-mode` to horizontal (CSS), inline becomes vertical axis and block becomes horizontal axis. Horizontal writing mode is default; japanese/chinese use vertical writing mode 17:20:38 present+ 17:20:39 Ack jc 17:22:07 q+ 17:22:11 jcraig: I'm confused about this distinction; horizontal refers to horizon line and `aria-orientation` is used for scrollbars/sliders. I'm familiar with different directionality of writing systems, but having trouble understanding how `inline` and `block` would make difference in the case of `aria-orientation` which is used for those types of controls 17:22:17 q+ 17:22:58 ...I would like to understand the context; is there a change we can review related to this? 17:23:37 scott: was only just noting that it wasn't an uncommon thing out of left field 17:24:44 q- 17:25:10 pkra: I was having a conversation with a developer who was dealing with ARIA and writing direction changes. They haven't run into any problems but since they had to deal with both, and they looked at `aria-orientation` and were in touch with the problem of writing directional changes, they wondered if it was something they need to think about. Was it possible to do via CSS? I brought it up to ask if other developers have run into this 17:25:10 consideration, and for other widgets such as scrollbars/sliders/tabs, and it's where directionality could coincide with orientation. If other devs have, I'd love to know how they handled it 17:25:27 Ack me 17:25:31 ack me 17:25:35 q+ 17:25:38 ...`focusgroup` is another good example of this (directionality) 17:26:21 jamesn: I'm having trouble imagining how someone would create a horizontal accordion if one had a vertical writing direction. Having a hard time visualizing the layout, although it's possible. It's probably not something most developers have thought about 17:26:33 This is the "old" version of the explainer btw 17:26:42 Not the one that is actively being developed. 17:26:51 ...when we look at the ARIA spec and think about what orientation applies to...do widget controls in the browser respect writing direction or is it just text blocks? 17:26:52 q+ to ask if there are any related renderings that change when the writing style switches to vertical... For example, do sliders change to vertical? 17:27:00 inline/block is roughly the same though. 17:27:22 ...should look at applying directionality on a selective basis perhaps 17:27:42 ``` 17:27:42 data:text/html, 17:27:42 ``` 17:27:44 https://open-ui.org/components/scoped-focusgroup.explainer/ 17:27:47 scott: look at latest `focusgroup` explainer 17:28:30 data:text/html, 17:28:41 jcraig: I had a similar question: does anyone know offhand if there's a UI control that automatically switches orientation based on writing direction? E.g., a slider that defaults to horizontal, if it were japanese for example. Maybe the AAM mapping should adjust 17:28:49 ack me 17:28:49 jcraig, you wanted to ask if there are any related renderings that change when the writing style switches to vertical... For example, do sliders change to vertical? 17:29:20 keithamus: see `input type="range"`example I posted in IRC 17:29:48 jcraig: maybe the mapping is tied into HTML/CSS AAM which changes the `aria-orientation` to vertical 17:30:12 Matt_King: are you suggesting that the browser does this automatically when the browser maps a11y attributes in the a11y tree? 17:30:23 q+ 17:30:34 jcraig: may be confusing to authors to change the meaning of these `aria-orientation` attribute values 17:30:50 q+ 17:31:10 Ack ja 17:31:11 jamesn: the control itself would have to (a custom scripted control) would have to know the writing mode 17:31:36 q+ to discuss the mappings in https://wicg.github.io/aom/explainer.html#user-action-events-from-assistive-technology 17:31:53 q+ 17:31:57 Jacques: if author noted `horizontal, how does this map to screen readers? Specifying `inline` or `block` allows browser to compute directionality 17:33:06 Ack keithamus 17:33:14 q+ 17:33:14 keithamus: the issue here is that the writing mode is controllable independently from HTML; the orientation is either horizontal or vertical, this can be controlled via CSS. I think it's reasonable to have these terms block/inline and the engine can resolve those to the computed style (allows developers to abstract away horizontal/vertical to one location where they set the writing mode, and have browser figure out what they mean via use of 17:33:14 logical properties) 17:34:33 jcraig: having trouble understanding why we need a separate aria value for that? If you're using ARIA in this scenario, you're trying to override what the browser has done automatically. Or you're rendering something custom, you're not relying on the browser (browser doesn't know what the orientation is so you must be explicit). If you're leveraging `input type=range` which happens to be vertical, do you need `aria-orientation`? 17:34:45 Ack jc 17:34:45 jcraig, you wanted to discuss the mappings in https://wicg.github.io/aom/explainer.html#user-action-events-from-assistive-technology 17:35:22 keithamus: problem is you're already authoring HTML which is the orientation of horizontal, if the `writing-mode`changes, the browser responds to that (although the visual orientation is now vertical) 17:36:24 Siri has joined #aria 17:37:10 ...developer use case is that, in CSS you can write stuff that is flexible to writing mode; the ARIA override does not allow the abstract notion of block vs. inline. The implementation should be such that, if you've specified implementation of block for examples, the value of `aria-orientation` changes (via mapping and browser calculation) 17:38:11 ...when I press one of my arrow keys in AT (at interaction time), dynamically figure out writing mode. Difficult to do this via HTML (reacting to changes in computed CSS styles) 17:38:41 agenda? 17:40:55 Ack Matt_King 17:41:05 jcraig: regarding increment/decrement AT events; AT needs to know what event to synthesize depending on writing mode (e.g., horizontal modes like French/English, RTL languages like Arabic). In VO on Mac, you can send arrow keys through or use interaction mode which synthesizes up/down keys for increment/decrement for example. Hope it's clear that user agent implementation range is what author has intended; concern is that there's a scenario 17:41:05 where engine has implementation and author is listening for keys and gets the wrong one 17:42:10 q+ 17:42:14 q- 17:42:44 Ack jc 17:42:45 Matt_King: my concern is, if we have these new values for `aria-orientation`, is that they would never be exposed to user via a11y tree. This isn't a situation where you're using ARIA to override to something that the user agent is going to do, it's more like the user agent should do it for the author (and pump out horizontal/vertical to the AT). This seems unprecedented as far as ARIA 17:42:48 q+ to discuss examples like a circular slider 17:42:56 Ack jc 17:42:56 jcraig, you wanted to discuss examples like a circular slider 17:44:23 jcraig: as a circular slider example, it could be left-to-right circular slider (or right-to-left). As far as assistive technology experience, users don't need to know, they are either incrementing or decrementing; since this is a custom control, is this a scenario where you need to explicitly state directionality 17:44:39 Matt_King: Right/Up and Left/Down do the same thing in this scenario 17:45:20 Matt_King: Highlights different in LTR vs RTL languages (right is increase/increment in LTR languages) 17:45:25 q+ 17:45:35 Ack Jacques 17:46:18 q+ 17:46:41 Jacques: if someone made a toolbar which is horizontal, but the CSS is a vertical mode and they used `aria-orientation` (or a vertical toolbar for example), what should the AT experience be 17:47:02 q- 17:47:03 jcraig: because you're using a toolbar as a managed widget, then the controller for that view should update `aria-orientation` property 17:47:14 Matt_King: big question is who is responsible for that; is that the author? 17:47:16 q+ 17:47:33 q+ 17:47:41 jcraig: maybe it doesn't matter if the author is doing the right thing, left/right (or up/down) moves focus and maybe it does the right thing and an AT user doesn't need to know 17:47:51 q- 17:48:01 Matt_King: in a toolbar, you often only want to use one set of arrow keys (due to drop-down, submenus or combobox implementations) 17:48:53 keithamus: I agree with Matt; main value of this is for web developers. Without implementing block/inline, it is incumbent on the author to ascribe action to arrow keys (without specifying writing mode). There's an additional step that they need to take to set orientation depending on writing mode 17:49:28 q+ to ask if there's IDL precedent for anything like this. 17:49:34 q+ 17:49:52 Zakim, close the queue 17:49:52 ok, jamesn, the speaker queue is closed 17:49:58 Ack keithamus 17:50:10 q+ 17:50:22 filippo-zorzi has joined #aria 17:50:51 Matt_King: is there a use case for aria-orientation where an author is relying on `focusgroup` which changes arrow keys based on CSS. Does it do that? 17:51:30 keithamus: for a custom widget, I may be responding to arrow keys but based on computed style; it's too difficult to set `aria-orientation` because there's no way of notifying the element that writing mode has changed 17:51:31 and at the point the arrow comes in, its too late to set the aria-orientation, they would have to be watching style 17:52:06 ..when the attribute is set, no way to know writing mode 17:52:48 Ack jcraig 17:52:48 jcraig, you wanted to ask if there's IDL precedent for anything like this. 17:53:04 agenda? 17:53:10 q- 17:54:11 jcraig: I'm coming around to this. Is there IDL precedent? May relate to some of the IDL challenges Rahim encountered. E.g., aria-orientation, can't have different IDL defaults based on role. The approach that may work is having a browser default (null) 17:54:41 Ack Jacques 17:54:44 ...in such cases, the default value could either come from the browser or author (e.g., custom slider) 17:55:38 Jacques: even without `focusgroup`, challenging to determine the orientation (and querying computing styles) 17:55:54 instead of taking up speaking time, i'll just say +1 to much of what keith just said. it seems like it'd be favorable to add these values for cases where orientation could be variable - and thus an author could just set one of these values as their default, and then not have to worry about updating the DOM / aria attribute, and instead rely on the 17:55:54 browser css/js to help do this 17:55:57 q+ 17:56:11 custom elements 17:56:23 ...the real-world example is a custom control that just works, and using the same widget with differing orientations on different pages. Might need a CSS script to control the different orientations 17:57:18 keithamus: not so much about changes during page interaction, it's about how an author is reasonably able to handle the timing. E.g., during the startup/instantiation of element, figure out the orientation then (but this is complicated). HTML, and perhaps unrelated JS that is unaware of mutations, can further complicate this 17:57:46 jamesn: we need some definitive use cases written down to progress this. Any volunteers to flesh this out? 17:58:49 Matt_King: I hope this discussion gets added to the issue 17:59:00 zakim, next item 17:59:00 agendum 5 -- [Expectations for aria-hidden and focused elements](https://github.com/w3c/aria/pull/2181) -- taken up [from jamesn] 18:00:59 scott: was waiting for people to make definitive decisions (on behavior after they made comments) 18:02:09 Daniel: my company is no longer participating in the W3C. This was a worthwhile experience, thank you to James Nurthen/Valerie, great work. Wanted to say goodbye, was an honor to be part of this group. 18:02:44 ...Mario as well is leaving. Greetings from him as well 18:03:35 bkardell has joined #aria 18:08:55 Adam_Page has joined #aria 18:34:53 Matt_King has joined #aria 23:47:26 RRSAgent has joined #aria 23:47:26 logging to https://www.w3.org/2026/03/26-aria-irc 23:47:34 rrsagent, make minutes 23:47:35 I have made the request to generate https://www.w3.org/2026/03/26-aria-minutes.html Rahim