Meeting minutes
New Issue Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
<spectranaut_> w3c/
spectranaut_: a couple of svg-aam issues.
jamesn: just clearing up the spec, right?
spectranaut_: the link one sounds like something we want to talk about
cyns: we're looking into UA behavior
… html is very permissive.
jcraig: webkit will expose links with click handler as clickable but not necessarily as link.
jamesn: note the heuristics for chrome on click handlers, too.
spectranaut_: next up #2750 logical properties.
… scott responded.
pkra: this was a question in a personal conversation. I didn't have an answer. Scott pointed to focusgroup similarity.
spectranaut_: others we have discussed already.
… Daniels' is editorial
… I left a comment for Rahim's issue.
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
<Jacques> I can help clarify wrt focusgorup similarity, but we can leave this to when we discuss this in the agenda.
spectranaut_: first up the PR cyns mentioned.
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: no new ones
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: any plans?
janewman: did we want to do one focusgroup?
… I don't have anything pressing but getting more eyes always helps.
spectranaut_: is there a specific aspect we should focus on?
janenewman: I just recall the last discussion calling for a deep dive.
jcraig: deep dive idea: valerie's work on accacia and rahim's work on accessibility properties. could we use a deep dive for that?
spectranaut_: sounds good.
… once things land.
jcraig: yes
cyns: setting aside some test writing time would also be a good idea.
check mappings and a11y of HTMLButtonElement's declarative scroll commands
spectranaut_: we briefly discussed this a few meetings ago.
… we ended with questions.
… in particular, what's announced when these buttons are clicked.
… how is scrolling announced.
… there's been an update.
daniil: to recap, we want to add scroll events for html buttons.
… the question is how the changes in the scroller are announced.
<jcraig> Explainer update here: https://
daniil: first proposal is that it shouldn't be connected to the buttons at all but separate.
… proposal: snap change event. Contains snap target.
… could be used as some way to understand which element is in view.
<jcraig> Deep link to scrollsnapchange: https://
daniil: problem: it only works with snappable containers, with limited implementations.
… 2nd proposal: declarative live regions.
… live region would have idref to scroller.
<jcraig> deep link to Daniil's new aria-live-source proposal https://
daniil: the bowser could detect which element is in view, we can extract which element is active, take its label and without changing the DOM the browser sends the even to the OS that something has changed, e.g., with label.
… this would allow us to avoid requiring changes to AT
… problem is that you cannot really change much.
… but it's simple to subscribe.
… if this lacks flexibility, then a new event might be an option. Firing on any kind of scroller. Browser gives you the elements in view. You can then format it as you want and update the aria-live content.
jcraig: thanks for the explainer updates.
… regarding aria-live-source. What's currently possible with aria-live, in particular atomic, and the events you described, I think you can already do this.
… if it requires JS, then it should work already.
daniil: the goal is to have no JS needed. The idea is that aria-live is subscribed to the scroller. Then the aria-live is populated automatically by the label of the element in view.
jcraig: do you update the label?
daniil: no, the label comes from the element in view.
jcraig: thanks for clarifying.
<Zakim> jcraig, you wanted to ask why the aria-live wouldn't already work?
scott: option 2 seems a bit more elegant, especially with aria-notify.
… for option 1, the markup seems a bit confusing to me.
… I can imagine aria-live-source acting a bit like labelledby. It's different in that you're not putting anything into it.
… of course we want the accname for whatever is shown.
… that could be done by role=status or alert right now if labelledby would point to the ID which changes
… not saying that's how it worked. just conceptually similar.
… I wonder why wouldn't we just use aria-notify since that's sort-of the future of aria-live / live regions.
… and since we don't want to add new features that aren't testable.
… anyway, I'm more in favor of option 2.
matt: on option 2. you said you have flexibility here.
… is option 2 also not requiring JS to get this kind of flexibility?
… or is it the AT that's more flexible in presenting or filtering.
daniil: I mean just the author.
… in the first option with aria-live-source, it's the browser that sources things.
… in option 2, it's the author.
matt: so option 2 needs JS to format?
jcraig: yes.
matt: ok, then it doesn't achieve the objectives of option 1 but gives the flexibility.
<spectranaut_> After the third bullet in this section is the 2nd example https://
jcraig: if it's really as simple as "DOM announcement of an aria-label", could it not be done from the scroll snap change?
… or is there a downside?
matt: how would AT handle that?
… announcement with properties like aria-notify to enable AT to properly filter or control presentation?
jcraig: maybe not even aria-notify. Just on scroll snapped event, we could say that the expected behavior is triggering a live region event with the computed label.
… it's then separate from really both live and notify.
… it just gets routed to the platforms. maybe using live-like treatment under the hood.
daniil: I thought it should be opt-in.
jcraig: does it need to be opt in? Can we think of reasons it's too chatty or users don't want it?
matt: feels like at least authors should opt in.
… when they do want a specific behavior.
… often what's snapped into view is a container that contains a lot of stuff, may not be named meaningfully.
… e.g. subset of a collection
… like a few thumbnails at once
… might need author control.
jcraig: if they label the items, they could have granular control.
… there might be times where it's chatty but users would be able to cancel e.g. speech updates.
… but you're sitting on a button that you're activating.
… and by default you get an update.
matt: right. I think there might be a situation where authors want more control than the name of a container.
… generating containers and naming them might be a bigger ask.
spectranaut_: recap, jcraig is suggesting making option 1 but as a default.
jcraig: for option 2, you could use prevent default .
scott: I'm more in favor of jcraig's revision of option 1. Not asking authors to create an aria-live element somewhere.
… from a quick test, if I understand the feature correctly, then putting aria-labelledby on a visually hidden status element, pointing to it, hiding/showing that. It's announcing the correct thing. So it seems we could already do option 1 easily.
jcraig: just to clarify. this will obviously depend on how my suggestion is written up.
… I think the request to make this opt-out could be possible.
… and yes, notifications are not testable. But this seems more like a new behavior not a new feature as such.
matt: I like this direction, in particular if there is an opt-out.
… and if the events help identify the source.
… e.g. when we talk to AT vendors, they tend to need a way to identify where the events come from.
spectranaut_: any other questions right now?
daniil: having this on by default seems risky. This proposal is independent of the buttons themselves. If we're discussing this, we should be able to apply this to any scroller.
… or should it depend on the button specifically?
jcraig: you're saying the announcement would happen in many other scenarios?
daniil: yes. And also not just on snappable. These buttons can be used outside snapping. E.g. scroll to TOS.
jcraig: I think it should not apply to any scroller. Snapping has a more specific intent.
daniil: but then scroll-snap-end event is sufficient?
jcraig: then the question might be if authors can prevent the announcement.
daniil: it just gives you the even, it doesn't update anything, just gives you the information
jcraig: I have to spend more time on the opt-out considerations.
… I might be misunderstanding this.
daniil: how would you envision the opt-out?
jcraig: usually when you change focus, things get trampled over.
scott: clarifying question: this may be unwanted, e.g., when multiple items are in the available viewport. Say in a TOC. If you scroll, the other elements might not be out of view. Figuring out which accname to announce.
… in the carousel example, it's often assumed that if you only show a particular panel at a time, the off-screen content should be hidden.
… but from other work on carousel, that content is not necessarily hidden, so it might still contribute.
… I still feel like aria-notify is still the better path to follow.
<jcraig> I'm coming back around to option 2
matt: re "all scrollers". It matter a lot what's triggering a scroller. In the case of the button, it's useful because it's outside the controller.
<jcraig> the new js event
matt: if the focus is inside, but say a keyboard event scrolls a feed you're inside, then announcements would be very confusing.
… it matters a lot.
jcraig: thanks. I'm coming around back to your point of view.
daniil: thanks. if scott could add a comment. And perhaps we could split out the buttons.
Change tooltip to name prohibited
spectranaut_: scott could you take a look at my comment?