Meeting minutes
<smockle> w3c/
<sarah> present_
New PR Triage
sarah: Added "transparent generic definition", and added a reference to aria-live. Want others' thoughts
Rahim: (James, Valerie, Adam all offer to review ARIA PR #2599)
keithamus: Can skip ARIA PR #2598, don't want to spend too much time. Needs more work before it's ready for review
jamesn: Should this be in draft status?
keithamus: I can do that
jamesn: Cynthia has offered to be an editor for core-aam and svg-aam
WPT Open PRs
jcraig: unless there are updates, can move on
jamesn: no new deepdives, and none are scheduled. Any proposed ones?
Deep Dive planning
ARIA IDL updates: enumerated attribute conversions, new "enumerated" wai-aria type, IDL examples
Rahim: the status of this, we are all in agreement, which attributes should be converted to enumerated. I'm writing wpt tests to test the new behaviour, all browsers will fail for now
Rahim: keith and anne brought up the fact there is overlap between valid keywords, that map to the same state. For example, false/undefined/empty string might all map to the false state. So I think simplification can happen
Rahim: I wanted to check about what would be the most tenable approach for simplification
(rahim reads his options as written in the pull request)
Rahim: Anne said we don't need to specify "undefined", just the empty string
keithamus: my opinion is that we should aim for the minimum set that apply to the state. where the invalid state maps to false
keithamus: the string of "false" mapping to false, the empty string mapping to "false"
keithamus: engines will have one canonical keyword
keithamus: the string of empty string and the string of undefined are not represented in the engines
keithamus: the string of foo is not represented in the engines, but still maps to false (i.e., the invalid value default)
keithamus: these are not values that the engine understands
Rahim: luke from igalia is going to be adding some more spec updates regarding reflection/enumerated, introducing "empty value default"
Rahim: where we have empty strings, the empty value default would be a good way to document that state
Rahim: there are some attributes that don't reflect in conventional manner. like aria-invalid, it has spelling grammar true and false... but if I pass any string value that is not a valid keyword, the invalid value default is the true state
Rahim: the only case where the false state is different than invalid value default, which is the true state (i.e., the invalid value default doesn't act as catch-all like all other attributes with multiple keywords for the "false" state)
keithamus: aria-invalid, for invalid value default would map to the true state
cyns: I think option 1 is the easiest to understand
cyns: I don't see a strong reason not to do it that way
keithamus: those values are not valid values, so why do we chose to list those, when there are infinite values we could list
cyns: the values we list are values that existed in the past, and already referenced in spec
keithamus: so does the spec reflect what authors do, or what authors+engines should do
cyns: undefined existed in previous versions of this document
keithamus: maybe for that reason we can have a note
keithamus: explaining the historic stuff
Rahim: that is the reason why I opted for reason 1 initially (i.e., listing out every single possible keyword, despite duplicates)
jcraig: did I hear keith say that for something ... for html "checked" the undefined string as the content attribute value, maps to the false state)
sarah: aria-checked does have an undefined state, but the string undefined would be null (i.e., Undefined state, which is no state = null)
sarah: I was going to say what keith said about the note was right
sarah: an fyi for authors
keithamus: I would like to add a caveat to option 3
keithamus: we shouldn't use RFC
keithamus: in the notes
jcraig: aria-pressed changes the role.... (something about this scribe didn't catch)
sarah: aria-checked to tree items removed default selected state.
mattking: those items are not selectable
jcraig: this is important to call out in that informative note
Rahim: some attributes have an undefined state, which maps more to the javascript undefined
mattking: if the value is not present
keithamus: the options of an attribute to have no state... so you don't have to use the terminology undefined, you can say "no state"
Rahim: I vague recall anne specified saying to explicitly name the state, rather than relying on no state (i.e., null)
keithamus: maybe we can deviate from naming it the "undefined" state
keithamus: "empty state" maybe? indeterminate state?
Rahim: options: no state, indeterminate, undefined, empty
jcraig: this might expose an implementation detail... there is work that can only be done by core accessibility work of the engine, state could be determined by implementation....?
jcraig: reference there is more computation to be done before it can be determined
keithamus: we should have a discrete well named state
keithamus: ... something about firefox
Rahim: you never specify an undefined state, because these things map to the enumerated states
keithamus: it is conceptually the no state
keithamus: we have something that is either successfully parse as an enumerated attribute, or it is no state
Rahim: why in the html spec is this named sometimes, and other times different
Rahim: popover seems different
keithamus: algorithms that like to use that state within an algorithm
keithamus: you have to name it in order to refer to it
Rahim: aria-attributes... do they need to be referenced by algorithms (if not presently, perhaps as a future-facing consideration)?
smockle: I think indeterminate is bad because its used in aria spec for other reasons
<smockle> e.g. confusion with https://
keithamus: if we don't want "no state", we could name it, we could skirt around some of the problems by explaining away from the name undefined state
Rahim: sounds like keeping it the undefined state is ok
keithamus: yeah
Rahim: sounds like there is more of a consensus for 3
Rahim: any objection?
Rahim: keeping the empty string is ok as well, it should be a valid key word.... that would be covered by special empty value default
Rahim: which luke will be adding
Rahim: sounds like agreement!
Rahim: jcraig you recommended a note....
jcraig: I've come around to keithamus suggestion of no state
Rahim: thanks everyone~!
ariaNotify spec draft
<Jacques> w3c/
Jacques: this can't merge until commitment from another browser. I wanted to get clarification on when I can consider this PR to be complete/approved
… before shipping this in Chrome, wanted to get positive signal from ARIA WG
… would also gently request review
jcraig: Rahim and I will discuss, and what screen reader changes would be needed. Will refresh myself on the details of this proposal
Jacques: also talked to Jamie Teh. Regarding implementations, this is working in the Origin Trial and working with all the major screen readers. Should also work today and if it doesn't, would be worth calling out
jamesn: rather than just relying on the browser vendors who need to look at this, should have someone from this group review it. Can I ask for some other people to look at this?
Matt_King: I may be able to review it (can't commit)
jamesn: any volunteers?
… will assign myself, but will ask someone internally as well
Jacques: going back to my first question, will it be obvious to me that we're OK and waiting on browser commitments?
… we're wanting to ship this in Chrome/Edge but to ship in Chrome, we want positive signals from the ARIA WG
… questions around why the spec draft hasn't been reviewed yet
spectranaut_: you can put me on the review as well
keithamus: maybe some GitHub staff members would like to review it?
Clay: not sure if my reviewing it would add necessary endorsement of it, curious about feedback from other folks
jamesn: we are supportive but if a signal is needed, we can review it and ensure it's in the state you like
sarah: I can review as well
jcraig: one thing that would be helpful, due to many aria notification/notify issues...there was an issue that cross-linked all aria notification issues? Anyone have that link?
<smockle> https://
jcraig: found it
Matt_King: (to jamesn) we can have non-members of the ARIA WG put reviews in?
jamesn: it's a public repo, so they can comment (but if they comment positively, I can put it in from me)
cross root ID references
<jamesn> Explainer:
<jamesn> Recent Presentation:
<jamesn> https://
<jamesn> (from Igalia/
<jamesn> Two ways to activate the Chromium flag for testing:
<jamesn> A) Enable the flag chrome://
<jamesn> B) Launch the browser with the command-line flag --enable-blink-features=ShadowRootReferenceTarget
<jamesn> Intent to experiment thread with more background links:
<jamesn> https://
spectranaut_: the explainer that is linked to (above) is a draft that reflects an opinion (Alice') and feedback is welcome
jamesn: this is the missing piece to implement web components accessibly, and will make our lives much easier and make possible what is not possible today