Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
Daniel: No need to talk about this one, AccName editors should review
katez: Worked on this
… Coudln't merge
spectranaut_: Editorials need 2 reviews as well
drogan: I can do it
spectranaut_: No need to talk about the conditionally required roles
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
<giacomo-petri> a/Worked on https://
spectranaut_: Add foundational tests for aria-description and aria-describedby
… These are using the tentative tester. I can look at that
spectranaut_: Add dialog to html-aam roles
jcraig: I'll take a look and merge it
spectranaut_: We have an html aam one for aside as well, will talk about it later
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: We had a deep-dive about menus (new HTML menu, menuitem, menubar elements)
… email me or Daniel to get the recording
… 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
spectranaut_: There is a deep-dive tag to be added to the deep dive proposals
Declarative Overscroll feedback
dgrogan: Support for overscroll
… When you're browsing the web on the phone, pull from the top, and have it refreshed
… Also, swipe left and right on the message and have it archived, deleted, or otheer action
vladimir: Talked about this at OpenUI, CSS and WhatWG
<jcraig> It'd be good to link the standards positions links in the issue proposals
vladimir: Multiple use cases. Accessibility related questions are listed here
… First is inertness
… At first the menu is hidden, all contents within the menu will be inert
… 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
… Question whether we should inert all contents of the overscroll or just the ones of the container
Jacques: Are you saying that when these are over the rest of the document is inert?
Vladimir: This is thee reason I think we should do full inertness
Vladimir: For navigation we'd like to add default aria actions for cases where there's no buttons to access these items
… There's several ways to create these areas. One is with buttons and another is with actions
… No strong opinions about how mouse should access these areas
<Zakim> jcraig, you wanted to ask about the implementation of aria-actions here
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
… We implement it with a simulated event that clicks on a designated area
… Not sure how all of this would work if it's behind the scroll
… Have you thought about how this proposal would work if there's nothing to click?
Vladimir: We send a specific new overscroll event when the scroll begins and when it's over
… One possibility for an action is to do scroll into view so as to cause the same events to fire
… The visuals of it would be swiped
… By default, I don't think we've considered your suggestion
jcraig: There's more considerations to be made
… aria-actions is a set of id refs
… With the lack of that there's not real indicatoin to the user what is happening, maybe only through color, which brings usability concerns
… I don't see a direct path as to how the markup would be set up
Vladimir: There can only be one element on the overscroll area, currently there's two in the mail example
jcraig: There's an actionable element
… In iOS you might have two to start with but if you do a quick swipe there may be more
Vladimir: I don't think we have that pattern supported here
jcraig: It's not about how quickly, it's about the total distance
flackr: You could do that with sccripts
… There is an element you're scrolling to and if you want, that element could in itself contain multiple buttons
jcraig: There could be multiple button elements inside the overflow but only one would be the default
vladimir: This whole menu element would have the commandfor and therefore be the default in this particular example
Vladimir: Last item is the support for something likke back drop or dismiss
… It would be nice if there's a visual indication that covers the content to indicate that it's inert
… It would also be fully stylable
… The dismiss question is that all menus that exist today have the pattern that if you click outside of them they are dismissed
… Should this one have it too?
<Daniel> s/?The dismiss/The light dismiss/
Vladimir: Last issue is autoactivation, we've touched on it
… If you have a trigger, maybe that should also activate the action
spectranaut_: Questions?
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
… The scrolling container itself is arguably not interactive
Vladimir: When the menu is open, should that textarea be interactive at all?
Matt_King: What happens in the accessibility tree?
flackr: It feels identical to using a dialog
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
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?
flackr: Whether or not the element and its content need to be inert is also an open question
jcraig: You cannot trigger and aria actions in the background with an inert content
… Also not clear if you'd still be able to remain on the element once these other things are shown
<Zakim> jcraig, you wanted to ask light dismiss in the concept of "Dismiss" https://
Matt_King: It'd be OK if the menu trigger, once press, would put focus on the menu
jcraig: To the light dismiss, VO has the scrub gesture, and also if there's a keyboard connected you can use the escape key
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?
flackr: I'd say this would buble up to the top-level. Escape is interacting with the different component, the one which has focus
jcraig: The event target wouldd be critical. If you are on the title then you'd need a back drop
… Or maybe the event targetis tight to focus
Vladimir: Makes sense to me
jcraig: Bubling to the container seems the right way to interact with it
Jacques: If you can close the menu content, if you don't have atouchpad, how would you open those?
Vladimir: For some examples there is no button to open them. Could we have an implicit aria actions targeting this?
<jcraig> maybe contextMenu?
Jacques: But aria actions simulate mouse clicks
jcraig: When you are on the main content, instead of triggering synthesized scroll events we do it through ccontext menus
… Keyboard users I don't know if there's a consistent way to do that for all platforms
… Presumably you'd want some button or trigger
Vladimir: There are users that don't use the keyboard proficiently
jcraig: Didn't you say the mouse wheel would be explicitly disallowed?
Vladimir: Yes, but these users should be able to access the content
flackr: When you are scrolling with the mouse wheel you are not expected to triger these actions
… Some mouse wheel users may not know how to scroll horizontally with the wheel
Vladimir: This would be broken, but it would be broken for most windows users
janewman: It would work only on mobile, seems problematic at least
<Zakim> jcraig, you wanted to ask if there are standards-positions trackers yet… I didn't immediately find one for WebKit
jcraig: Is the standards position tracker created?
Vladimir: This is early stages. We plan to request stage 2 in that group and then we'll be filing position requests
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?
flackr: This isn't using the way developers would write aria-actions, this relies on the browser
jcraig: In the context of mobile edge swipe behaviors, have you consider disambiguating the default user agent behaviors?
Vladimir: We typically don't intercept these
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?
jcraig: This needs to be considered in the contesxt of an AT that has the show menu actions
… 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
flackr: And if that part of the page it wouldn't be on the tree
jcraig: 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
Vladimir: Next steps would be to file more specific issues
… We'll bring those back when we think we are ready to make decissions
spectranaut_: We'll try to be more clear on how we make decissions
<jcraig> inert./