Meeting minutes
New Issue Triage
spectranaut_: For aria #2509, about how Chromium/Firefox ignore presentational children. What are we doing there?
jamesn: do they really ignore everything, or just certain roles? I'm not sure how comprehensive Wilco's testing was. Worth clarifying
… Firefox does it for everything except `img`, but does it do it (ignore) for every `input` element
scott: I wanted to respond that this needs to be something more nuanced
jamesn: that buttons don't allow it means that there's history and we may want to revise, i.e., usage is so common. Have workarounds for making it a button even though it is
aardrian: need more detail from Wilco
spectranaut_: I can follow up after the meeting
keithamus: for Firefox, I believe if it has `role="presentation"` but has an `aria-*`, it gets exposed
jcraig: may want to look into Shadow DOM implementations for HTML5 `input`s; there are buttons inside text fields, and variety of things not allowed in DOM but allowed in HTML implementations of standard elements
scott: there are a lot of issues around presentational children; needs to be a whole clean-up of this stuff that could be tracked from this one thing (i.e., #2509)
jugglinmike: working on AT driver (protocol for automating AT interaction). Would like to write in core-AAM things that have more significance to the implementor and from that standpoint, not clear that core-aam is set up for external references
<jcraig> https://
jugglinmike: wanted to start referencing terms that are not stable or may change for folks that are actually maintaining them (and why)
spectranaut_: wanted ARIA group to see this issue but the suggestions in the issue (core-aam #248) look OK if anyone else wants to weigh in
<Zakim> jcraig, you wanted to mention https://
jcraig: there's a number of different automation efforts (e.g., aom #203). For example, the WebDriver extension defined in aom #203 defines different ways to trigger an accessibility event, focus events, show menu on an element, etc. May get you part of the way there, doesn't allow you to send an event to AT itself; the goal is for WebDriver to simulate an event on behalf of the AT or behave as if the AT is simulating the event
jugglinmike: good to know about this; the design of a lot of the APIs on what's capable by WebDriver and web platform itself. This could impact what is necessary for AT driver. Folks may not be using AT driver exclusively, could be using WebDriver as well
jcraig: could run in the WPT CI environment without automating AT but there are similarities. In your issue (jugglinmike), references a BiDI only implementation so there's overlap. This is discussed at least one a month in the a11y interop meetings which I can send you an invite for if you'd like
spectranaut_: can continue the conversation in part in the a11y interop meetings
Rahim: nothing to add for `display:contents` html-aam issue, thanks for adding css-aam label
New PR Triage
WPT Open PRs
jcraig: wpt #51918, LGTM
spectranaut_: can merge this now
Deep Dive planning
New in-line 3D HTML model element
lola: for WPT open PRs, how does that work? I was hoping to get feedback on a PR I opened. What is the process for this (i.e., to add the labels)?
jcraig: you're doing the process right, thanks for the reminder
spectranaut_: calling it out during this agenda item is reasonable, thanks
jcraig: I will look at it right now
jcraig: this is like USDZ (3D format that is standardized between Apple and Pixar and other companies)
… in the explainer there's an accessibility section; the `<model>` has fallback content which could be a `<video>` or `<img>`
… this issue was a heads-up for this particular group, and Scott has looked at the issue. In conjunction with this issue, Brandel (issue creator) is looking at USDZ modeling itself; the `<model>` element could have fallback but the model itself can be made accessible. Heads-up for the ARIA group that new mappings will be needed for html-aam, etc.
aardrian: was wondering if this was more like `<canvas>` but sounds like more like `<svg>`
<aardrian> So _not_ VRML come back to haunt me.
jcraig: this is a collaboration with Pixar, could have a whole movie in a single USDZ (contained in a single HTML element with its own video/audio track)
keithamus: I have a couple questions: the `<model>` have an interaction attribute. Can click and drag to rotate a model (curious if there's more than that). Like glTF, will this be something that has controls where you can scrub timeline, are we expecting something similar for the `<model>` element?
jcraig: I had similar questions but technologies can be used in unexpected ways by developers. For instance, if you had a long timeline but using interactive state to jump between scenes in the timeline, how do you make that part accessible. It's a good question, lots of TBD answers thus far
<jcraig> w3c/
jcraig: I'm also working on the above VTT issue on disambiguating VTT in a way where you can use VTT in other formats (e.g., timeline in a model for a USDZ, could have accessibility of the scenes in a metadata format tied to particular timecodes that match the scene)
… immediate expectation is not for `<model>` to be used this way, but hopefully there are hooks in place for accessibility
keithamus: was thinking that this was much wider scope than `<svg>` or `<video>` in terms of model complexity
spectranaut_: is there any more past raising the feature and gathering thoughts on improving accessibility?
scott: happy to get involved for anything specific
jcraig: nothing immediate for scott but just a heads-up for the ARIA group. XR/AR is here to stay, exciting so please be involved
Concerning navigation "menus" (open ui related) #2510
scott: there is a proposals in openui around standardizing menu elements, taking the concepts of menubar/menu/menuitem into HTML. One area that has been brought up is supporting use cases where menus perform navigation; larger topic around making menu navs (see APG) is the contentious topic that if we want to do this, it should make sense as opposed to just making menu/menubar where menu items act as links
… some people like the APG menu nav example, others dislike it (both a11y advocates and users). Good opportunity to make this pattern better, better expose roles, make it more clear that a collection of menu items behave as a navigation than what standard menu items are understood to be
… meet in the middle when people do make navigations using elements, as they are with the ARIA roles, what can we do to make people's experience better
… e.g., a `menuitemlink` role so it could be included in the screen reader collection of links on a page
<aardrian> hah!
jamesn: I think this is broader than menu items; if we are going to look into things that add to link status (collection). Could have a property that we apply to buttons/links, like a pseudo double (additional) role
… I see why people want to do this, I come across menu link navigations as they're common. And I see why someone would want to do that in websites to, so we should explore it but not just looking at menu items
aardrian: I have a broader concern with this proposal. Didn't fully do the work (or prior history), haven't considered affordances gained/lost, understanding of AT. Scott said that we should "meet in the middle" so long as as the middle is not extreme and to jcraig's point, must be explored with knowing the objective/end goal is outside "this is a nifty idea"
… for example, they misquoted Scott and the transcript, didn't go into detail on menu item browser treatment, etc.
spectranaut_: what stage is this issue?
scott: there is desire to work on this, and I've already provided feedback on the initial draft proposal. I filed an issue missing from the proposal use case...because this is early on, I want to get this on the ARIA WG's radar and don't want to be the only one advocating for this
… there is legitimacy to this and I think that we (ARIA WG) can help
<Zakim> jcraig, you wanted to mention iOS trait-style accessibility mixins…
jcraig: just a quick heads-up to Adrian, it would help for you to list this in your comment (didn't see them in your comment) and your specific concerns, e.g., terminology of guidelines, APG patterns, etc. Or post a new comment for the proposer to go back and research
<aardrian> jcraig openui/
jcraig: James N. mentioned a concept called role mixins (or add-on roles) which is a pattern that iOS has had. What are roles/states/properties is essentially a trait that you can add to an element and don't require strict management. One of the reasons why iOS development is popular is that it makes assignment of these traits easy
… agree with simplifying ARIA or a similar pattern
jane: something I've seen for every web app that I've worked on; it's an issue that should be resolved and documentation has been confusing. The broader conversation about broadening this into something that can be worked on would be nice to see
<aardrian> please minute "ARIA sapling"!
keithamus: as an ARIA sapling, I sympathize with Adrian's comments in the thread. It would be awesome to be sent literature on why this is a bad idea or how we need to consider these things (i.e., historic context)
… don't know why it's a bad idea, but know that it is. Please explain why it is and I can relay these concerns
aardrian: I linked in the comment which I mentioned to jcraig in this chat, I've linked stuff I've written before including the links that Scott provided in the issue. Also linked to ARIA stuff but between those two comments, may be useful to you but if there's anything wrong/out-of-date, let me know as I try to update those regularly
scott: I've provided most of those links (both in my original response and Google doc)
<aardrian> keithamus Research suggestions: openui/
<aardrian> keithamus My original comment with links: openui/
jcraig: I wanted echo James' comment (thanks); my comment is not on this issue but in general, I think it behooves us to try to be understanding of people asking for a11y help. We (a11y community) have a tendency to do this, i.e., taking a purist view
… it behooves us to help those people that care to make it accessible rather than telling them to "do something else" because they may not be in a position to do so
spectranaut_: keithamus looks interested in catching up on this; it would be nice to flesh out something like a link mixin attribute
aardrian: I'm not sure what the broader issue is (i.e., link mixin). Is it more due diligence?
jcraig: iOS has traits (e.g., `UIAccessibilityTraitHeader`, `UIAccessibilityTraitLink`); most a11y APIs have something that is tree role/property-based
… can't do it as a `role` because there can only be one role with potential fallbacks. Could be something like `aria-labelsynonyms` (e.g., element that supports multiple labels). Something like `aria-roleaddons`
cyns: UIA control patterns is something that it can be modeled on which is more flexible than how ARIA roles work
aardrian: can leave Scott's issue open so it can be populated with the outcomes of this discussion