00:21:45 RRSAgent has joined #aria 00:21:49 logging to https://www.w3.org/2025/11/11-aria-irc 00:22:15 RRSAgent, make minutes 00:22:17 I have made the request to generate https://www.w3.org/2025/11/11-aria-minutes.html ZoeBijl 00:22:34 Zakim, show the agenda 00:22:34 I see 7 items remaining on the agenda: 00:22:34 1. Update from Open UI, Part 2 [from ZoeBijl] 00:22:34 2. Menu Element [from ZoeBijl] 00:22:34 3. snap-to-activate [from ZoeBijl] 00:22:34 4. Process discussion with W3C [from ZoeBijl] 00:22:34 5. Update from Open UI, Part 3 [from ZoeBijl] 00:22:34 6. OpenUSD Accessibility API, element, and other accessible format types like SVG+ARIA [from ZoeBijl] 00:22:35 7. Purpose and priorities of the ARIA WG, including review of new web features? [from ZoeBijl] 00:24:12 ari has joined #aria 00:24:28 jamesn has joined #aria 00:27:28 rrsagent, set logs public 00:44:40 elguerrero5 has joined #aria 00:44:44 elguerrero5 has left #aria 00:44:47 bkardell has joined #aria 00:45:15 Zakim, show the agenda 00:45:15 I see 7 items remaining on the agenda: 00:45:15 1. Update from Open UI, Part 2 [from ZoeBijl] 00:45:15 2. Menu Element [from ZoeBijl] 00:45:15 3. snap-to-activate [from ZoeBijl] 00:45:15 4. Process discussion with W3C [from ZoeBijl] 00:45:15 5. Update from Open UI, Part 3 [from ZoeBijl] 00:45:15 6. OpenUSD Accessibility API, element, and other accessible format types like SVG+ARIA [from ZoeBijl] 00:45:15 7. Purpose and priorities of the ARIA WG, including review of new web features? [from ZoeBijl] 00:45:19 Zakim, next item 00:45:19 agendum 1 -- Update from Open UI, Part 2 -- taken up [from ZoeBijl] 00:45:20 Adam_Page has joined #aria 00:45:24 spectranaut_ has joined #aria 00:45:24 alisonmaher has joined #aria 00:45:31 masonf has joined #aria 00:45:40 present_ 00:45:40 present+ 00:45:43 elguerrero has joined #aria 00:45:46 present+ 00:45:52 present+ 00:45:54 present+ 00:45:55 present+ 00:45:59 present+ 00:46:06 present+ 00:46:14 present+ 00:46:16 Jamie has joined #aria 00:46:42 siri has joined #aria 00:46:46 nico has joined #aria 00:46:54 present+ 00:46:59 present+ 00:47:23 SH: one of the things being incubated by ?? is interest invokers 00:47:28 there’s a new interest event 00:47:35 or declaritively for JS 00:47:36 s/??/open-ui 00:47:37 s/??/OpenUI/ 00:47:44 the really cool part is that ?? 00:48:06 right now the way you do hover cards etc 00:48:22 usually when you use your mouse to hover 00:48:27 this is done with hover and focus events 00:48:27 flackr has joined #aria 00:48:29 and this doesn’t work for everyone 00:48:39 with interest invokers we have specific events for this 00:48:54 this means you can in theroy you can make this work for voice control 00:49:00 by having VC use a custom command 00:49:05 ?? 00:49:16 lots of possibilities to make this accessibility 00:49:26 browsers provide the interest event 00:49:36 devs will have to use that to make the UI functional 00:49:47 Scott and I have been providing feedback in the group 00:49:55 present+ 00:49:59 but we would like further feedback from the group 00:50:00 present+ 00:50:09 present+ 00:50:12 *starts slides* 00:50:22 open questions 00:50:38 1. Does the aria-details for desktops SRs? Compare to aria-actions? 00:50:55 2. Should the ::interest-hint pseudo element be excluded from the accessibility tree? 00:51:00 3. Voice control contacts? 00:51:04 4. Optional: touch access 00:51:09 LR: I want to clarify ?? 00:51:21 the plain ones would be when you have a popover with text content 00:51:41 the other would be anything besides just text 00:51:42 the way we implemented this 00:51:42 mehm8128 has joined #aria 00:51:42 with plain text there’s no aria-details 00:51:48 we use aria-description 00:51:51 q+ to clarify interestfor vs custom interest events 00:51:59 with the other ones we ?? 00:52:03 the name stays the same 00:52:09 you add an aria-description 00:52:31 it’s quite nice because the SRs i tested speaks the name + the description and the relationship 00:52:56 ?? my take would be that an event should happen 00:53:10 one way to verify this would be to alt+tab and then alt+tab back into the window 00:53:11 and then ?? 00:53:19 is this splitting that just chrome does? 00:53:24 SH: that is interesting 00:53:35 i do want to mention that this is not just a relationship for popovers 00:53:46 this event will fire even if it’s not a popover 00:53:58 it’s a programmatic event, so you don’t know what it would do 00:54:02 can you clarify ?? 00:54:05 LR: yes 00:54:14 the case i was describing was just interest for the popover 00:54:23 MF: if it’s not a popover you’re on your own 00:54:31 SH: this is about ?? interest 00:54:38 what is the mechanism for idnicating interest 00:54:44 LR: so not declaritive? 00:54:49 SH: not neccesarily 00:54:52 it could be both 00:54:59 this is more about specifically about this being a new event 00:55:05 it’s about how do you trigger that event 00:55:38 LR: i agree that from a semantics perspective this should be implemented 00:55:49 from aria-details, from a SR user persepective, needs some tweaking 00:55:58 sarah has joined #aria 00:55:59 maybe a good outcome from the discussion could be ?? 00:56:04 q? 00:56:06 this is an informal survey of users 00:56:14 what is the shortcut of going to aria-details 00:56:19 and nobody knew 00:56:29 JT: for declaritive… 00:56:33 we have aria-expanded 00:56:39 it will, or should, fire an event 00:56:46 when an interst target appears or disappears 00:56:52 and it also declares aria-details 00:57:00 your interest is in regard ?? 00:57:09 in which case you would have to ecplicitly set aria-details? 00:57:24 SH: my question is more about how you explicitly trigger interest 00:57:34 for example if you’re in browse mode 00:57:37 JT: couple of things 00:57:48 1. AT sniffing 00:58:06 2. i’m not following using the aria-details mechanism 00:58:15 it’s not an action, it’s a query 00:58:18 ?? 00:58:36 but even if there were asking for the details relationship, it’s not interest, it’s a programmatic query 00:58:45 an action might be acceptable 00:58:51 q? 00:58:57 ach Jamie 00:58:58 ack Jamie 00:58:58 Jamie, you wanted to clarify interestfor vs custom interest events 00:58:59 ack me 00:59:15 MK: the way you’re talking about this 00:59:29 it sounds liek there’s a difference from someone looking at the accessibility tree 00:59:31 and at an event 00:59:35 is that correct? 00:59:39 is that necessary 00:59:56 i forget if interestfor is limited to popovers? 00:59:57 MF: no 01:00:00 SH: ?? 01:00:03 and everything else 01:00:11 interestfor=popover 01:00:28 MF: essentially there’s only delcaritive ?? attribute 01:00:35 SH: there is the event right? 01:00:38 that you can listen to? 01:00:40 MF: yea 01:00:53 JT: but the browser won’t trigger it? 01:00:57 so neither should AT? 01:01:03 front-endian-jane has joined #aria 01:01:03 SH: oh i thought it would trigger it 01:01:06 present+ 01:01:10 MF: no there’s no interest event 01:01:12 there’s no API 01:01:16 q+ 01:01:21 LR: can you clarify what feedback you want? 01:01:26 SH: essentially… 01:01:37 interestfor pointing at a popover or other elements 01:02:03 i assume we want the method of indicating interest to be the same between those events 01:02:16 MK: do you mean in the accessibility tree? 01:02:19 do you mean authors or users? 01:02:22 SH: i mena suers 01:02:26 s/suers/users/ 01:02:33 s/mena/mean/ 01:02:53 LR: one idea i once had 01:03:05 right now the aria-details relationship only happens when the itnerst target is shown 01:03:08 what would happen 01:03:14 the first thing people would say is ?? 01:03:24 could we indicate in the element that there is more content? 01:03:31 maybe using aria-expanded and collaps? 01:03:32 s/itnerst/intrest 01:03:49 SH: the problem with that is that you could have interst on an element that has aria-expanded 01:03:57 say you have an accordian header 01:04:02 s/say is ??/say is we can't expose the details relation because the target isn't in the accessibility tree/ 01:04:18 aria-expanded would be for the content, but the interest could be for a separate tooltip 01:04:28 MK: the SR user could request the actions 01:04:32 which sets focus 01:04:39 with focus there the actions get exposed 01:04:46 that’s how we get around the sniffing concern 01:04:48 but in this case… 01:04:54 couldn’t you do the same thing with… 01:04:57 SH: you could 01:05:03 MK: you do have a problem in the ations page 01:05:04 rrsagent, draft minutes 01:05:06 I have made the request to generate https://www.w3.org/2025/11/11-aria-minutes.html daniel-mac 01:05:12 the thing we didn’t address 01:05:16 stuff that’s not focusable 01:05:24 does it need to be focusable? 01:05:30 MF, SH: yes 01:05:32 q+ to flag that declarative vs imperative shouldn't be different, can expose has-interestfor:true or similar 01:05:33 buttons and links 01:05:38 MK: ?? 01:05:43 jarhar has joined #aria 01:05:44 ask the AT to set focus? 01:05:51 SH: i think aria-actiosn would work 01:06:05 MK: wondering if we have the same AT requirements 01:06:15 or would that cause issues for SR users? 01:06:18 q? 01:06:30 siri: you said whenever you hover it shows 01:06:31 SH: yes 01:06:38 siri: the issue i see 01:06:39 ?? 01:06:48 SH: that’s definitely an example 01:07:04 on wikipedia you get previous if you hover over articles you get a preview 01:07:08 same with social media 01:07:18 if you hover a username you could get a preview of the profile 01:07:45 siri: most of the time we’re talk about SR users 01:07:45 present+ Daniel 01:07:46 what about voice control users? 01:07:48 q+ to ask edge cases about invoking events and delays 01:07:52 SH: that’s the third question on the list 01:08:07 rrsagent, stay 01:08:17 q- 01:08:27 Subtopic: ::interst-hit pseudo element 01:08:43 SH: it’s part of the button or link you want interest for 01:08:47 we discussed this in OpenUI 01:09:11 my proposal was to not have this in the accessibiltiy tree if we do this with specific AT fucntions (??) 01:09:27 it would be a pointer target 01:09:34 JC: it would be a pointer target 01:09:38 so you can click it? 01:09:39 ack siri 01:09:46 but you wouldn’t expect an event on it 01:09:48 SH: yes 01:09:56 but it wouldn’t prevent you from adding it 01:10:10 i wouldn’t expect AT to have to interact with it 01:10:18 JC: didn’t we talk about this for aria-actions? 01:10:19 ?? 01:10:28 i would expect that would be the way to invoke it 01:10:38 SH: it’s not just there as a way to show interest 01:10:57 the element that has `interestfor` still shows the popover/associated element 01:11:08 Matt_King has joined #aria 01:11:11 so show on focus will already happen 01:11:35 MK: you said that the author could indicate the availability for `interestfor` 01:11:55 does that mean that the browser is in reposonse to attribute is automatically showing something next to the element 01:11:58 that’s a tab target? 01:11:59 SH: yes 01:12:13 q+ to clarify when the pseudoelement would be shown 01:12:16 the presentation would depent on how you style it 01:12:28 MK: so the author is providing that element in CSS? 01:12:28 SH: yes 01:12:33 it would be a CSS pseudo element? 01:12:45 MK: and it would appear when? 01:12:45 JT: always visible 01:12:53 MF: with the `content` property or something 01:13:12 MK: that presents a problem with WCAG probably 01:13:18 having two targets so close to eachotehr 01:13:25 ?? 01:13:39 SH: yea voice control and screen readers would be the two relevant ones 01:13:42 MK: ?? 01:13:53 SH: that’s also the other reason i think it shouldn’t be exposed 01:13:54 qv? 01:13:57 the use case driving this 01:14:02 you can expose this with ?? 01:14:21 and that means if you’re using a SR sometimes there might be an extra button for something that has interest 01:14:24 and sometimes there isn’t 01:14:35 MF: i think it’s important to remember that it’s auxillary 01:14:48 akc jcraig 01:14:52 ack jcraig 01:14:52 jcraig, you wanted to ask edge cases about invoking events and delays 01:14:57 q- I'll ask later :) 01:15:01 q- 01:15:09 JC: iOS has a “two tab” behaviour 01:15:20 specifically on iPad where you have desktop sites 01:15:23 say a fly out menu 01:15:42 the two tap will essentially trigger the hover event 01:15:52 allowing the flyout menu to show 01:15:58 most of the concerns or open issues 01:16:02 are related to the mainstream interface 01:16:13 i’m just trying to pass these along 01:16:17 there’s no real concern 01:16:21 the ?? 01:16:36 the descoverability of long press has been logn been discussed 01:16:41 it’s useful for lots of things 01:16:52 there was another one that may be dismissed 01:17:01 there was long, medium, short keyboard delays 01:17:05 these seem to be gone? 01:17:09 MF: yea these are gone 01:17:13 it’s no times 01:17:16 the keywords are gone 01:17:27 times are there 01:17:30 JC: ah ok 01:17:42 MF: there is an explicit thing in there for user agent overrides 01:18:10 JC: the other thing that hasn’t been fully considered are things like the Apple Vision Pro situation or tmaybe meta glasses 01:18:20 i think that’s it 01:18:25 don’t need a response right now 01:18:31 just so you can think about it 01:18:36 SH: thank you 01:18:46 yes i want to talk about that with you jamie and maybe matt 01:19:03 *jokes about having interest for the topic* 01:19:34 show agenda 01:20:02 front-endian-jane has joined #aria 01:21:05 *discussion about another meeting* 01:21:18 This is the whatwg schedule: https://github.com/whatwg/html/issues/11711#issuecomment-3499143498 01:21:45 move to next agendum 01:21:45 agendum 2 -- Menu Element -- taken up [from ZoeBijl] 01:22:06 DF: hi 01:22:21 one of the things we’ve been working on in the OpenUI is menus 01:22:26 the word menu is brutally overloaded 01:22:41 we specifically talking about system menus 01:22:50 like those found in operating systems 01:22:56 but also web applications 01:23:03 a word processor for example 01:23:18 the point of this presentation is to make everyone aware of the proposal 01:23:29 and have discussion about the accessibility considerations 01:23:37 the motivation is that this is a common pattern on the web 01:23:46 we did a survey on n sites 01:24:01 the wya to trigger these is ?? 01:24:08 hovering works universally 01:24:16 but keyboard and clicking are sparse 01:24:34 activating items works mostly with click and keyboard 01:24:37 but not universally so 01:24:45 also looping 01:25:01 so using arrow keys to move between menus and submenus 01:25:12 implementations vary 01:25:22 there are a bunch of other weird behaviours 01:25:26 present+ 01:25:26 such as `Tab` 01:25:33 support varies wildly 01:25:44 we have a lot of interesting proposals 01:25:49 such as the Popover API 01:26:07 *shows test page* 01:26:21 this is all keyboard navigation 01:26:40 we have (exclusivity) checkable menu items 01:26:52 this whole thing is using prototype ?? 01:26:59 the code is pretty simple 01:27:08 we have a new `menubar` element 01:27:17 and `menuitem` 01:27:28 and `menulist` 01:27:33 you can make radio menu items with a `fieldset` 01:27:47 we started by kicking up dust and tryign to handle everything 01:28:01 we learned pretty quickly there’s a lot of difficulty and complexity 01:28:02 s/prototype ??/prototype ??, no JavaScript/ 01:28:08 Apologies for stepping out abruptly. There's a critical VTT captions topic in Timed Text WG being discussed now. 01:28:10 especially with regards to accessibility 01:28:27 this resulted in us splitting off navigation bars 01:28:38 which would be a `navigationbar` element 01:28:47 thank you to all the accessibility people for being patient with us 01:28:59 Sarah, Scott, other people in the room, and probably others! 01:29:16 this means we can focus on menubar 01:29:59 LR: when you showed the example you said the `menubar` has `menuitem` in it 01:30:07 shouldn’t it have `menulist` and then `menuitem`? 01:30:25 DF: the `menubar` first has `menuitem` and these then invoke the `menulist` 01:31:02 the basic high level thing here is that we have native ARIA role mapping 01:31:10 `menubar` to `menubar` 01:31:16 `menulist` to `menu` 01:31:34 `menuitem` to `menuitem` 01:32:00 we also have a bunch of discussion around `aria-expanded`, `aria-checked`, and `aria-disabled` 01:32:46 we were landing on the behaviour of `` has `aria-disabled=true` 01:32:53 to make them “soft disabled” 01:33:01 we also discussed `aria-owns` 01:33:07 and how we shoudl expose the hiarchy 01:33:22 in the DOM we don’t nest `menulist` inside `menuitem` 01:33:28 those are siblings 01:33:50 should they be siblings in the accessibility tree? 01:33:57 or should they represent the visiaul hiarchy with `aria-owns` 01:34:04 it was suggested to keep them as siblings 01:34:13 a big part of this is keyboard support 01:34:14 ??? 01:34:19 the other thing is orientation 01:34:25 horizontal/verticle 01:34:33 which could use `aria-orientation` 01:34:46 jugglinmike has joined #aria 01:34:51 ~Fin~ 01:35:05 q+ 01:35:07 q+ to ask about accesskeys, menulist labelling, a11y tree parenting, grouping and posinset/setsize 01:35:13 q+ to ask how you are going to stop people using it for navigation menus 01:35:17 let’s open up the floor 01:35:52 q+ lucas 01:35:56 dbaron has joined #aria 01:36:01 Rahim: thank you for the presentation 01:36:10 question around the implementation like mega menus 01:36:12 ack Rahim 01:36:16 one common pattern that i come across a lot 01:36:21 if you have a menu 01:36:29 really you have a trigger to toggle the menu 01:36:38 sometimes they marked as menus 01:36:43 sometimes are details 01:36:51 DF: good question 01:36:59 all design items that would support a mega menu 01:37:15 everything would go into the `menulist` (??) 01:37:31 all the difficulty around mega menus is around ?? 01:37:49 i like to think we kinda support it out of the box 01:37:57 q+ 01:38:21 ZB: wouldn’t that be more for the `navigationbar` element? 01:38:25 DF: yea ?? 01:38:44 another is that they (??) have much more toolbar commands 01:38:47 ack Jamie 01:38:47 Jamie, you wanted to ask about accesskeys, menulist labelling, a11y tree parenting, grouping and posinset/setsize 01:38:55 JT: some quick points 01:39:06 have there been consideration for accesskey 01:39:37 MK: if you type “RE” in a menu it will go to the menuitem that starts with that 01:39:44 JT: do menu items ?? 01:39:49