17:00:44 <RRSAgent> RRSAgent has joined #aria
17:00:49 <RRSAgent> logging to https://www.w3.org/2026/05/14-aria-irc
17:00:49 <Zakim> RRSAgent, make logs Public
17:00:50 <Zakim> Meeting: ARIA WG
17:00:54 <spectranaut_> agendabot, find agenda
17:00:54 <agendabot> spectranaut_, OK. This may take a minute...
17:00:54 <agendabot> agenda: https://www.w3.org/events/meetings/690d057f-db6d-4169-b13f-68d7f1336b59/20260514T130000/
17:00:54 <agendabot> clear agenda
17:00:54 <agendabot> agenda+ -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-04-30+repo:w3c/aria&type=Issues
17:00:55 <agendabot> agenda+ -> WPT Open PRs https://bit.ly/wpt_a11y
17:00:58 <agendabot> agenda+ -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates
17:00:59 <katez> katez has joined #aria
17:01:03 <spectranaut_> chair: spectranaut_
17:01:05 <agendabot> agenda+ -> Declarative Overscroll feedback https://github.com/w3c/aria/issues/2785
17:01:05 <agendabot> agenda+ -> Simplify aside mappings https://github.com/w3c/html-aam/issues/607
17:01:43 <filippo-zorzi> present+
17:01:46 <katez> present+
17:03:15 <flackr> present+
17:04:28 <CurtBellew> CurtBellew has joined #aria
17:04:59 <vmpstr> present+
17:05:00 <Daniel> scribe+
17:05:12 <Daniel> zakim, take up next
17:05:12 <Zakim> agendum 1 -- -> New PR Triage https://github.com/search?q=is%3Aopen+is%3Apr+created:%3E=2026-04-30+repo:w3c/aria&type=Issues -- taken up [from agendabot]
17:05:12 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:05:14 <giacomo-petri> giacomo-petri has joined #aria
17:05:17 <giacomo-petri> present+
17:06:07 <Daniel> Daniel: No need to talk about this one,  AccName editors should review
17:07:03 <Daniel> katez: Worked on this
17:07:12 <Daniel> ... Coudln't merge
17:07:35 <Daniel> spectranaut_: Editorials need 2 reviews as well
17:07:47 <Daniel> David: I can do it
17:07:51 <Jacques> Jacques has joined #aria
17:08:02 <Daniel> spectranaut_: No need to talk about the conditionally required roles
17:08:05 <Daniel> zakim, take up next
17:08:05 <Zakim> agendum 2 -- -> WPT Open PRs https://bit.ly/wpt_a11y -- taken up [from agendabot]
17:08:05 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:08:07 <giacomo-petri> a/Worked on this/Worked on https://github.com/w3c/aria/issues/2783
17:08:16 <giacomo-petri> s/Worked on this/Worked on https://github.com/w3c/aria/issues/2783
17:08:42 <Daniel> spectranaut_: Add foundational tests for aria-description and aria-describedby
17:08:58 <Daniel> ... These are using the tentative tester. I can look at that
17:09:20 <Daniel> spectranaut_: Add dialog to html-aam roles
17:09:28 <Daniel> jcraig: I'll take a look and merge it
17:09:50 <Daniel> spectranaut_: We have an html aam one for aside as well, will talk about it later
17:09:53 <Daniel> zakim, take up next
17:09:53 <Zakim> agendum 3 -- -> Deep Dive planning https://bit.ly/aria-meaty-topic-candidates -- taken up [from agendabot]
17:09:53 <github-bot> I can't comment on that because it doesn't look like a github issue to me.
17:10:19 <Daniel> spectranaut_: We had a deep-dive about menus (new HTML menu, menuitem, menubar elements)
17:10:26 <Daniel> ... email me or Daniel  to get the recording
17:10:59 <Daniel> ... For future deep dives, also in the last meeting Matt wanted us to discuss how the position of menu items in a menu is communicated to screen readers
17:11:52 <Daniel> spectranaut_: There is a deep-dive tag to be added to the deep dive proposals
17:11:54 <Daniel> zakim, take up next
17:11:54 <Zakim> agendum 4 -- -> Declarative Overscroll feedback https://github.com/w3c/aria/issues/2785 -- taken up [from agendabot]
17:12:33 <Daniel> dgrogan: Support for overscroll
17:12:45 <Daniel> ... When you're browsing the web on the phone, pull from the top, and have it refreshed
17:12:59 <Daniel> ... Also, swipe left and right on the message and have it archived, deleted, or otheer action
17:13:16 <Daniel> s/David/drogan/
17:14:17 <Daniel> vladimir: Talked about this at OpenUI, CSS and WhatWG
17:14:36 <jcraig> It'd be good to link the standards positions links in the issue proposals
17:14:59 <Daniel> ... Multiple use cases. Accessibility related questions are listed here
17:15:09 <Daniel> ... First is inertness
17:15:36 <Daniel> ... At first the menu is hidden, all contents within the menu will be inert
17:15:59 <Daniel> ... When it's open, I think it makes sense for the rest of the content to still be inert, so that you're interacting with the top-level item
17:16:20 <Jacques> Jacques has joined #aria
17:16:29 <Daniel> ... Question whether we should inert all contents of the overscroll or just the ones of the container
17:16:38 <Jacques> q+
17:16:47 <spectranaut_> ack Jacques
17:17:15 <Daniel> Jacques: Are you saying that when these are over the rest of the document is inert?
17:17:39 <Daniel> Vladimir: This is thee reason I think we should do full inertness
17:17:40 <Matt_King> Matt_King has joined #aria
17:18:00 <Matt_King> present+
17:18:08 <Daniel> Vladimir: For navigation we'd like to add default aria actions for cases where there's no buttons to access these items
17:18:47 <Daniel> ... There's several ways to create these areas. One is with buttons and another is with actions
17:18:51 <jcraig> q+ to ask about the implementation of aria-actions here
17:19:16 <Daniel> ... No strong opinions about how mouse should access these areas
17:19:48 <spectranaut_> ack jcraig
17:19:48 <Zakim> jcraig, you wanted to ask about the implementation of aria-actions here
17:21:01 <Daniel> jcraig: ARIA actions came from an iOS paradigm and it's now more than screen readers. In the iOS API there's a functional response to calling on an action. In the web implementation, there isn't a functional response because that would be a way to identify ATs
17:21:16 <Siri> Siri has joined #aria
17:21:28 <Daniel> ... We implement it with a simulated event that clicks on a designated area
17:22:17 <Daniel> ... Not sure how all of this would work if it's behind the scroll
17:22:29 <Daniel> ... Have you thought about how this proposal would work if there's nothing to click?
17:22:47 <Daniel> Vladimir: We send a specific new overscroll event when the scroll begins and when it's over
17:23:07 <Daniel> ... One possibility for an action is to do scroll into view so as to cause the same events to fire
17:23:22 <Daniel> ... The visuals of it would be swiped
17:23:32 <Daniel> ... By default, I don't think we've considered your suggestion
17:24:15 <Daniel> jcraig: There's more considerations to be made
17:24:26 <Daniel> ... aria-actions is a set of id refs
17:24:56 <Daniel> ... With the lack of that there's not real indicatoin to the user what is happening, maybe only through color, which brings usability concerns
17:25:21 <Daniel> ... I don't see a direct path as to how the markup would be set up
17:25:37 <Daniel> Vladimir: There can only be one element on the overscroll area, currently there's two in the email example
17:25:43 <Daniel> s/email/mail/
17:25:55 <Daniel> jcraig: There's an actionable element
17:26:16 <Daniel> ... In iOS you might have two to start with but if you do a quick swipe there may be more
17:26:25 <Daniel> Vladimir: I don't think we have that pattern supported here
17:26:43 <Daniel> jcraig: It's not about how quickly, it's about the total distance
17:27:09 <Daniel> flackr: You could do that with sccripts
17:27:37 <Daniel> ... There is an element you're scrolling to and if you want, that element could in itself contain multiple buttons
17:28:23 <Daniel> jcraig: There could be multiple button elements inside the overflow but only one would be the default
17:28:58 <Daniel> vladimir: This whole menu element would be the default in this particular example
17:29:18 <jcraig> s/be the default/have the commandfor and therefore be the default/
17:29:18 <Daniel> Vladimir: Last item is the support for something likke back drop or dismiss
17:29:52 <Daniel> ... It would be nice if there's a visual indication that covers the content to indicate that it's inert
17:30:00 <Daniel> ... It would also be fully stylable
17:30:29 <Daniel> ... The dismiss question is that all menus that exist today have the pattern that if you click outside of them they are dismissed
17:30:37 <Daniel> ... Should this one have it too?
17:30:55 <Daniel> s/?The dismiss/The light dismiss/
17:31:29 <Daniel> Vladimir: Last issue is autoactivation, we've touched on it
17:32:24 <Daniel> ... If you have a trigger, maybe that should also activate the action
17:32:41 <dgrogan> q+
17:32:45 <jcraig> q+ to ask light dismiss in the concept of "Dismiss" https://wicg.github.io/aom/explainer.html#user-action-events-from-assistive-technology
17:32:46 <Daniel> spectranaut_: Questions?
17:32:47 <Jacques> q+
17:32:48 <spectranaut_> ack dgrogan
17:33:55 <Daniel> flackr: The part that is problematic is that this menu is part of the scrolling container, we want it to be interactive, but we also don't want the other part of this container to be interactive
17:34:07 <Daniel> ... The scrolling container itself is arguably not interactive
17:34:29 <Daniel> Vladimir: When the menu is open, should that textarea be interactive at all?
17:35:33 <Daniel> Matt_King: What happens in the accessibility tree?
17:35:49 <Daniel> flackr: It feels identical to using a dialog
17:36:44 <Daniel> jcraig: The inertness is also true and the menu contents would be also innert when the menu is not active. That would clash with how aria-action works
17:37:52 <Daniel> Matt_King: The way I experience actions in iOS natively, as I am exploring the actions they are not inert, I can still explore the element that has the actions on it. Does the ability to direct touch that element go away in this example?
17:38:28 <Daniel> flackr: Whether or not the element and its content need to be inert is also an open question
17:39:27 <Daniel> jcraig: You cannot trigger and aria actions in the background with an inert content
17:39:45 <Daniel> ... Also not clear if you'd still be able to remain on the element once these other things are shown
17:40:02 <jcraig> ack me
17:40:02 <Zakim> jcraig, you wanted to ask light dismiss in the concept of "Dismiss" https://wicg.github.io/aom/explainer.html#user-action-events-from-assistive-technology
17:40:28 <Daniel> Matt_King: It'd be OK if the menu trigger,  once press, would put focus on the menu
17:41:41 <Daniel> jcraig: To the light dismiss, VO has the scrub gesture, and also if there's a keyboard connected you can use the escape key
17:42:08 <Daniel> Vladimir: If you have two or three containers and you verscroll within all of them and then you hit escape, is the expectation that all of the close?
17:42:34 <Daniel> flackr: I'd say this would buble up to the top-level. Escape is interacting with the different component, the one which has focus
17:42:55 <Daniel> jcraig: The event target wouldd be critical. If you are on the title then you'd need a back drop
17:43:09 <Daniel> ... Or maybe the event targetis tight to focus
17:43:16 <Daniel> Vladimir: Makes sense to me
17:43:28 <Daniel> jcraig: Bubling to the container seems the right way to interact with it
17:43:34 <spectranaut_> ack Jacques
17:43:53 <Daniel> Jacques: If you can close the menu content, if you don't have atouchpad, how would you open those?
17:44:19 <Daniel> Vladimir: For some examples there is no button to open them. Could we have an implicit aria actions targeting this?
17:44:27 <jcraig> maybe contextMenu?
17:44:45 <Daniel> Jacques: But aria actions simulate mouse clicks
17:45:25 <Daniel> jcraig: When you are on the main content, instead of triggering synthesized scroll events we do it through ccontext menus
17:45:37 <Daniel> ... Keyboard users I don't know if there's a consistent way to do that for all platforms
17:45:58 <Daniel> ... Presumably you'd want some button or trigger
17:46:21 <Daniel> Vladimir: There are users that don't use the keyboard proficiently
17:46:32 <Daniel> jcraig: Didn't you say the mouse wheel would be explicitly disallowed?
17:46:45 <Daniel> Vladimir: Yes, but these users should be able to access the content
17:47:10 <Daniel> flackr: When you are scrolling with the mouse wheel you are not expected to triger these actions
17:47:36 <Jacques> q?
17:47:44 <Daniel> ... Some mouse wheel users may not know how to scroll horizontally with the wheel
17:48:02 <Daniel> Vladimir: This would be broken, but it would be broken for most windows users
17:48:25 <jcraig> q+ to ask if there are standards-positions trackers yet… I didn't immediately find one for WebKit
17:48:50 <Daniel> janewman: It would work only on mobile, seems problematic at least
17:48:55 <spectranaut_> ack jcraig
17:48:55 <Zakim> jcraig, you wanted to ask if there are standards-positions trackers yet… I didn't immediately find one for WebKit
17:49:08 <Daniel> jcraig: Is the standards position tracker created?
17:49:32 <Daniel> Vladimir: This is early stages. We plan to request stage 2 in that group and then we'll be filing position requests
17:50:01 <Daniel> Matt_King: With this relying on aria-actions which we still haven't finilized in ARIA, what would happen if we make changes to aria-actions?
17:50:35 <Daniel> flackr: This isn't using the way developers would write aria-actions, this relies on the browser
17:51:36 <Daniel> jcraig: In the context of mobile edge swipe behaviors, have you consider disambiguating the default user agent behaviors?
17:52:50 <jongund_> jongund_ has joined #aria
17:53:07 <Daniel> Vladimir: We typically don't intercept these
17:54:20 <Daniel> vladimir: I think there's some implications of focus navigation if we use the inert. What should focus behavior be when closing the menu or moving out of it?
17:54:35 <Daniel> jcraig: This needs to be considered in the contesxt of an AT that has the show menu actions
17:55:05 <Daniel> ... Typically it returns to the triggering element that was clicked, but in this case the focus may still be somewhere else when you're triggering the actions
17:55:22 <Daniel> flackr: And if that part of the page it wouldn't be on the tree
17:56:13 <Daniel> jcraig: But you'd still need to consider whether it's OK for the AT to follow focus, but presumably that would happen after the container is inert.
17:56:37 <Daniel> Vladimir: Next steps would be to file more specific issues
17:56:52 <Daniel> ... We'll bring those back when we think we are ready to make decissions
17:57:01 <Daniel> spectranaut_: We'll try to be more clear on how we make decissions
17:57:17 <Daniel> rrsagent, draft minutes
17:57:18 <RRSAgent> I have made the request to generate https://www.w3.org/2026/05/14-aria-minutes.html Daniel
17:58:57 <jcraig> s/But you'd still need to consider whether it's OK for the AT to follow focus, but presumably that would happen after the container is inert./But you'd still need to determine whether the expectation for the AT is to follow focus back to the triggering element, or in the case of aria-actions-based trigger, whether the engine should also retain the element with ART focus... But in either case. that would happen after the container is no longer
17:58:57 <jcraig> inert./
18:02:05 <jcraig> rrsagent, make minutes
18:02:06 <RRSAgent> I have made the request to generate https://www.w3.org/2026/05/14-aria-minutes.html jcraig
18:02:29 <jcraig> present+
18:02:31 <jcraig> rrsagent, make minutes
18:02:32 <RRSAgent> I have made the request to generate https://www.w3.org/2026/05/14-aria-minutes.html jcraig
19:24:15 <jongund> jongund has joined #aria
19:34:20 <jongund> jongund has joined #aria
19:52:33 <jongund> jongund has joined #aria
19:52:49 <jongund> jongund has joined #aria
19:58:33 <jongund> jongund has joined #aria
20:11:37 <jongund> jongund has joined #aria
20:12:02 <jongund> jongund has joined #aria
20:22:55 <jongund> jongund has joined #aria
22:03:11 <jongund> jongund has joined #aria
22:03:15 <jongund_> jongund_ has joined #aria