Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: 2 new PRs
… aria#2738
… from pkra
pkra: scotto made a suggestion
… it’s editorial, no need for other reviewers
jamesn: aria#2736
… also editorial
Daniel: cyns will review, and then it’s good to go
pkra: Daniel, someone flagged that a deep link had changed?
scott: when we changed the dynamic IDs created in core-aam, we tried to keep those so that IDs wouldn’t break
… but that evidently wasn’t done in SVG-AAM
Daniel: I’ll look into it
pkra: we should double-check that they don’t switch back
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
<jcraig> web-platform-tests/
jcraig: there’s 1 worth discussing ☝🏻
… getting very close to acceptance
… or we could put it on the agenda for another meeting
… just want people to be aware of the changes that are near to being approved
<melsumner> p+
jcraig: on line 1285 of testdriver.js
… we’ve effectively landed on 2 new webdriver methods
… some are purposefully redundant
… method names are verbose, but we decided that was important for clarity
… everyone, please be aware of these new accessors
… you can come from the a11y tree, or you can come from the DOM tree
… to get a11y properties
… extremely close to being approved
… we’ve got 2 semi-functional implementations
… Chromium people, please get your comments in
… very close to shipping in Gecko and Webkit
… this will really open up testing to the vast majority of ARIA
… Rahim will be presenting at CSUN 🎉
… we’re kind of capped out at what we can test in WPT, other than what spectranaut_ is working on with Acacia
… could mean tens of thousands of new tests
… could lead to a sea change in browser interop
… would love to get more reviewers on this
Deep Dive - Meeting with CSS - not finalised yet - more details forthcoming
jamesn: we’ll schedule this for next week
… next Thursday, in the hour before this meeting
… we’ll provide details
<spectranaut_> Add an ::interest-button pseudo element w3c/
Wide review working drafts - HTML-AAM to start then other AAMs need to go through CR process so we will create snapshots and ask for wide review. agendabot]
jamesn: about ready to create HTML-AAM going through the CR process
… every X number of years, you need to take a spec — even evergreen ones — to a recommendation
… just a heads-up
… this does trigger pattern exclusion aspect of the w3c process
Daniel: I reviewed, and the last time I saw activity was in 2021
jamesn: a number of things will be going through this process
… doesn’t really impact anything
… but will trigger wide reviews
… no action needed, other than editors of those docs and Daniel
New controls attribute for img element
jamesn: scott?
scott: I wanted to bring this up to get additional thoughts on it
… there is an HTML proposal to add a `controls` attribute to images, much like video and audio
… not sure what the controls would be other than play/pause, and maybe a button to show alt text
… my reason for bringing this up is that with audio and video, those elements act as a group container for other content within
… for images, those have never been groups — except SVGs
… screen readers don’t really let you navigate _inside_ an image
… we could have a similar note in HTML-AAM as with audio/video for how controls should be exposed and mapped
… but I’m thinking it’d need to be a sibling
… or browsers would need to sprout a container for the image plus its controls
… if there are any other thoughts, please review and comment
… I basically just think a toolbar “inside” an image just won’t work
… implementors, especially, please consider how you would actually do this?
jamesn: if we were to say that the control thing has to be a sibling, would you expect pushback from HTML folks?
… or could it be put in the spec?
scott: I don’t think it’d be a problem; they should already know
jcraig: platforms do have the ability to put child nodes inside of images
… there’s an existing svg-aam issue that I filed about that specific thing in the context of accessible svg
… right now, you have to expose it as a group instead of an image
… because of limitations in ARIA
scott: that’s what I was alluding to — the browser could “sprout” a group around the image
<melsumner> Question: how do you imagine backward compat working?
scott: so that AT could find it when navigating by images
jcraig: that describes today, but could we see a way to allow images to begin exposing themselves _as_ a group?
… currently within ARIA, there’s no distinction between types of groups
scott: I think my concern here would be that anything to be done here that would require — especially in Windows, where people won’t be updating their AT along with browser updates — I would be nervous about
… if it ships in HTML, it should “just work” without requiring AT changes
jcraig: with the <div role="image"> example you’ve written in the issue, are you suggesting that implementations should be able to account for that? And change the role to `group`, or recognize the author’s intent somehow?
scott: I put that in there just to illustrate using ARIA
… but this will be an HTML feature, so there’s nothing an author should have to do
… the question is “what would we want the implementation to be?”
… so that screen readers, etc., don’t also need to be updated
giacomo-petri: when you navigate an image, you don’t expect content inside
… if you have a “group image”, how can you determine that it is just a group of related images inside, or if it’s because there are controls inside
Matt_King: how do we learn more about the use cases for this controls attribute?
scott: this is a proposal in HTML
… for a controls attribute
Matt_King: what problem is the proposal solving?
scott: I don’t have an answer for that
… the suggestion was essentially to just copy what the video and audio elements already do
… but this isn’t the same as those elements, since they are already serve as a group
Matt_King: okay, I’ll review and leave some feedback
… also, big +1 to your mindset that we shouldn’t break anything
<Zakim> jcraig, you wanted to say I think we could align on the same behavior for the native example as well as your ARIA example <div role=image aria-label=foo> text goes here <button>bar</button></div> and to mention WebKit's similar precedence with the button for playing animated GIFs when "reduce motion" is enabled.
jcraig: I don't recall offhand if this is tied to the Reduce Motion settings, but there’s a button to play animated GIFs if auto-play is disabled based on the RM preference
… but wanted to respond to scott
… I think there’s a path forward that could satisfy the principle of not making additional work for the web author, and make the native attr proposal work, while also allowing your currently invalid ARIA example to work as the author intended. Hopefully with no changes needed to the AT clients that are slower to update.
jamesn: please review and add comments
<jamesn> GitHub: w3c/
<jamesn> github w3c/
<jamesn> github: w3c/
Scoping focusgroup to scenarios defined by aria roles - 5 minutes for inital thoughts only
jamesn: we want a quick primer on this rather than a full discussion
… people need to digest
… maybe agenda or deep dive for future
Jacques: we’ve discussed in prior calls
… applying a minimum role inference on buttons in a focus group
… the first two examples in the ticket are what we discussed months ago, the third example is what I’m proposing
Matt_King: I have one knee jerk reaction
… with aria-actions, we have buttons inside tablists, so if a button is referenced, so you might not want to convert its role
jamesn: in which case they could explicitly re-declare role="button", but that may not be desirable
Jacques: correct
jamesn: it sounds reasonable to me
… in a lot of ways, it’s making ARIA roles “native”
Matt_King: in both cases, you’re saying ARIA is now affecting browser behavior?
Jacques: it wouldn’t actually change the keyboard behavior, just the ARIA role inference
Matt_King: I see, because ARIA already affects mappings
… then I think you should consider incorporating aria-actions support
Jacques: I’ll have to look into that, great callout
jamesn: shall we schedule some time next week to talk about it?
Jacques: yes, please
… there’s an explainer
… and then I can update it again
check mappings and a11y of HTMLButtonElement's declarative scroll commands
jamesn: is anyone familiar with this?
<sakhapov> sakhapov
sakhapov: please open the explainer
… in the Example Usage section
… there is an HTML button
… we want to introduce new commands
… that would allow scrolling
… e.g., `page-inline-start`, `page-inline-end`
… the a11y part is how to declare it to the user
… browsers should mount it to `aria-controls`
… if the scroller has an `aria-label`, we take that name to announce what the button does
… e.g., “Next page, document preview, button”
… this is the first part of the proposal
… second part is button has state management
… it becomes disabled when the scrolling position is at the corresponding end
scott: I read through this earlier today
… and understand where this is coming from
… having consulted on the CSS carousel proposal
… the thing that struck me here was the explicit use of `aria-label`
… and appending it to the button accname
… for this use case, does it actually make sense to include them in the accessible name of the previous and next buttons
… but I do agree it makes sense to announce when the new content has been revealed
… so I see the intent
… but a little unsure of it at this time
… with the aria-controls mapping, if we could get that to be useful, then maybe it could apply here
… that’s my initial feedback
… focusing heavily on `aria-label`, but there are other ways to name a button
<jamesn> Act jamesn
sakhapov: how would the user know what the scroller does?
scott: no one looking at the page would know what it is either
jamesn: the aria-label in this proposal refers to the scrolling group, not one of the grouped items
sakhapov: correct, it’s the name of the scrolling group
… it’s not possible to put the scrolling buttons inside the scrolling region
jamesn: this needs clarifying in the explainer
jamesn: what happens when the button is pressed?
… what announcement will AT users get at that time?
… we need some sort of announcement, and how would the author specify something custom if they didn’t want the default behavior?
sakhapov: makes sense
jcraig: I echo some of jamesn’s concerns
… should be up to the web author what gets announced
… as one example, on the Mac side a button would confirm “pressed”, which would sometimes trample the thing that comes later
… so we changed to an earcon
… just want to make sure that we’re overspecifying in a way that the downstream AT can present to the user based on what the user wants
spectranaut_: do we need more discussion on this?
jamesn: I think we need explainer clarifications first, then more discussion