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.
StefanS: grid allows for more.
spectranaut_: please add to the issue for discussion next week
spectranaut_: assign to daniel
New PR Triage
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
jamesn: yes editorial. will merge after speaking with daniel
WPT Open PRs
draft pr web-platform-tests/
jcraig: Snuck in through DOM reflection tests mid-Interop 2024
Deep Dive planning
spectranaut_: remove deepfdive tag from complex dashboard issue w3c/
aaronlev: need james teh for deep dive re: w3c/
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/
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.