W3C

– DRAFT –
ARIA WG

24 October 2024

Attendees

Present
Adam_Page, ChrisCuellar, filippo-zorzi, giacomo-petri, hdv, jcraig, katez, pkra, sarah, scott, smockle, StefanS, zakk
Regrets
-
Chair
ValerieYoung
Scribe
pkra, jcraig

Meeting minutes

New Issue Triage

spectranaut_: core-aam#238
… listing downstream AT support for AAMs.
… sounds interesting. would be good to get input.

jcraig: connects to the other issue

spectranaut_: ok, let's move to aria#2361
… about shipping features with incomplete API mappings & AT support

jamesn: can we agenda this?

jcraig: sounds good.

spectranaut_: to recap, this was triggered by colIndexText etc on Mac.

aaronlev: it has windows support.

jcraig: we don't plan VO support. There's no webkit implementation right now for lack of OS API.

aaronlev: NVDA and JAWS support it. I think Firefox also has support.

jcraig: part of the concern came from WPT tests passing for chrome & firefox on Mac but it doesn't do anything.
… that's somewhat of a limitation of the testing setup since it doesn't do anything.
… then there are notes on Apple specific in the issue.

spectranaut_: let's continue next week.
aria#2359 clarifying tables, grid, treegrid
… from melsumner and scott conversation, let's agenda.

w3c/aria#2359

StefanS: grid allows for more.

spectranaut_: please add to the issue for discussion next week

w3c/aria#2357

spectranaut_: assign to daniel

New PR Triage

w3c/aria#2360

spectranaut_: scott filed update legend to provide name to optgroup

scott: legend element allowed as customizable select in HTML

open question in the PR

scott: what takes precedence... happy for reviews, but draft PR still pending the HTML discussion

keithamus: will review in the meantime

w3c/aria#2358

jamesn: yes editorial. will merge after speaking with daniel

WPT Open PRs

draft pr web-platform-tests/wpt#48797

jcraig: Snuck in through DOM reflection tests mid-Interop 2024

Deep Dive planning

spectranaut_: remove deepfdive tag from complex dashboard issue w3c/aria#2162

aaronlev: need james teh for deep dive re: w3c/aria#2162 (comment)

no good time to deep dive with all: Australia, US, and EU

spectranaut_: discuss with Jamie... maybe have a two-part deep dive?

giacomo-petri: okay by me

spectranaut_: will coord with jamie and suggest a time

9.3 Presentational Roles Conflict Resolution does not consider custom element use cases

Deep Dive planning

aaronlev: melsumner suggested deep dive on w3c/accname#95

will discuss to consider a time at next week's meeting

9.3 Presentational Roles Conflict Resolution does not consider custom element use cases

jamesn: i'm assigned... it's on me in any case. aaronlev is there anything left to clarify from Chrome issues?

happy for others to take this work on too?

sarah: are there custom elements defined in AAMs?

scott: identified as generic

need a change if moving them to none

jamesn: need a way to account for conflict resolution

keithamus: where is that defined

jamesn: hopefully linkable to html def

scott: make them "silly `role=none`s"

wrapper is none or generic

they can either be something or contain other things

keithamus: can be confusing. is it an autonomous element with functionality, or just a silly div

scott: you're spot on... in some cases, if you want attrs to the internals, whether light dom or shadow dom...

some attributes are ignored, but some are not... e.g. "gerrymandered" attrs

sarah: i volunteer to make the AAM PR... and help jamesn with presentational roles conflict PR

aaronlev: write the way you think it should work (not necessarily based on chrome implementation) and implementors will review

[\[AriaNotify\] Is NotificationId the right name?](w3c/aria#2329)

DougG: keithamus, clay, and doug are here

keithamus: name "notificationID in contention... proposing type

sarah: did we resolve whether this would be part of the initial v1?

keithamus: wanted enumeration of category names, and what would validation look like? unsure, so motivated to not ship it immediately.

happy with a "fast follow" (1.01 release)

keithamus: I think the functionality is pretty well defined in that we know what we're presenting to AT - a stable identifier so they can reason on the type of message.
… open question is: how useful is that? We're discussing this with AT and others.
… semantics around the value are in the air but that I think that doesn't preclude discussing the name. Letter vs spirit of law.

<Zakim> jcraig, you wanted to bikeshed notificationClassName which does not imply enumerated value list

keithamus: a fixed identifier that's sent to provide AT

jcraig: I wasn't aware that this identifier was considered for something like an enumerated list of category names.
… sounds like you want it to be an enumerated list.
… what if we use notification class name
… it seemed an open-ended thing that authors would define. ID would seem to be a unique thing.
… but it sounds like it's somewhere in between.

keithamus: that sounds about right. It's supposed to be heavily re-usable.
… we're currently categorizing apps to figure out if they fit into a category for which we could prescribe.
… it might not be too prescriptive. But we're hoping to get some level of collaboration between authors and AT to work out.
… so class name seems like a reasonable suggestion.
… to be clear it's a scalar.

clay: do we need notification to be in there?
… could it be notification priority / interrupt / etc

<Zakim> smockle, you wanted to see if we can get consensus about whether the option needs a “notification” prefix

clay: is there some other use of "type" that people are concerned about?

<Zakim> jcraig, you wanted to discuss the instagram an zoom notifications list

jcraig: I don't have a problem nixing that.

<sarah> +1 to "type"

jcraig: but I wanted to talk about instagram and zoom notification use cases.
… in the f2f there were different goals from different stakeholdesr.
… whether we want AT or platform APIs do the notification management while apps send as much as they want.
… or if we want the apps to manage.
… in the draft doc we had a section on this. zoom is short (now?) instagram still quite long.
… I don't think that level of granularity has a place in the API. But others in the room had differing opinions.
… if the latter remains a goal, then I think it needs to be broader.

sarah: it would help to understand what screenreaders might do here.
… at tpac, things like earcons came up. jaws customizations per app came up.
… I would appreciate this kind of a list if we have it.

aaronlev: radical idea: instead of making it very wide and then having to control a potential mess, what if we create a group to brainstorm as many different class names as we can, e.g., in a wiki.
… then give us a couple of months to discuss those.
… we'll know it won't be everything but we'll know we support those in v1. Then if people come with additional use cases, we can open it up widely.
… that's easier than boiling it down later.

keithamus: that's something we're after right now.
… starting with our own at github. Spent hours to just start with our, asked other teams.
… to recap sarah, some kind of list so we know what we're talking about before naming this. That's a good takeaway.

jcraig: was using "incoming chat" as as strawman. If we take chat applications, there'll be hundreds.
… but if github has over 800 types, how much of a chance do we have to come up with a taxonomy.

aaronlev: but would you agree it's useful to do the exercise?

jcraig: yes. just the github list would be valuable in say a gist.

keithamus: right. I can give a few now if that helps.

<Zakim> jcraig, you wanted to use "incoming chat" as the straw man example

keithamus: 4 come to mind immediately.
… dynamic forms, e.g., search. 15 search results. could be aria-live but we have reasons not to.
… for soft navigations we announce the title
… select range of checkbox, e.g., issue list. top checkbox selecting 25, announces that.
… we don't announce receiving notification but if you focus it, the computed label is the number of notification.

jcraig: that's github notifications?

keithamus: yes. that's our intenal.

jcraig: seems like those might boil down? I heard something like status change, count change.

aaronlev: yes that's what I had in mind.
… maybe it's 20 instead of 800.

keithamus: Right. majority is status or count. Some others might fall out of this.
… then there's live updates, e.g., when a comment comes in.
… might be we want something more specific there.
… that's something we've discussed quite a bit, figuring out the direction.

aaronlev: I could imagine some might feed back into other aria discussions, e.g., characters left for input of post.

sarah: one other piece of information I'd welcome is now just how authors are using notifications but also how AT users, incl. speech and braille, would want to receive them, e.g., mute some.
… would that be served by the type string or, as I think it's right now, by the text string.

keithamus: one of problems is that the strings change, counts or "message from X".

<Zakim> jcraig, you wanted to compare to system notifications levels of control.... per app/domain allow/deny and where/how/persistence.... all "types" or "classes" are left up to the apps' settings.

sarah: right, it's regexping right now

jcraig: I think this work will touch on what went wrong with aria-live.
… comparing that to system notifications: users can block entire app, some, does it go away, persist.
… beyond that it's business logic of the app.
… instagram has 30/40 types you can shut off individually.
… so I agree we should talk to AT users.
… anecdata is "let me turn them off"
… but having granular control in the website's settings (not the screen reader settings) seems like key here.

Minutes manually created (not a transcript), formatted by scribe.perl version 238 (Fri Oct 18 20:51:13 2024 UTC).

Diagnostics

Succeeded: s/having granular control /having granular control in the website's settings (not the screen reader settings) /

Succeeded: s/Topic: Neew PRs//

Maybe present: aaronlev, clay, DougG, jamesn, keithamus, spectranaut_

All speakers: aaronlev, clay, DougG, giacomo-petri, jamesn, jcraig, keithamus, sarah, scott, spectranaut_, StefanS

Active on IRC: aaronlev, Adam_Page, ChrisCuellar, filippo-zorzi, giacomo-petri, hdv, jamesn, jcraig, katez, keithamus, pkra, sarah, scott, smockle, spectranaut_, StefanS, zakk