Meeting minutes
New PR Triage
chrishtr: is it all open PR we're looking at or a filter?
spectranaut_: all PRs on ARIA
spectranaut_: created in the last week
<chrishtr> w3c/
chrishtr: I was wondering about #2577, is there a process in this meeting to make progress on that?
spectranaut_: if you want to discuss is at the next, you can always `agenda+` it
<spectranaut_> w3c/
spectranaut_: we can look at it right now
chrishtr: I'd like to understand if there's anything blocking landing it?
spectranaut_: we don't land until there are 2 implementations
jcraig: I thought there was a scenario with one implementation and support from another, or some variant of that?
spectranaut_: let's check our documentation
chrishtr: this one has a positive decision from Gecko and Webkit
spectranaut_: the reason we're hesitant to land it is that we'd have to pull it from the spec when we want to release if there's no implementation, which is extra work
spectranaut_: so ideally we'd like to be more clear on whether they actually plan to have it somewhere in the near future
chrishtr: would a comment from them suffice?
spectranaut_: yes that'd help
Jacques: this would need platform APIs probably
keithamus: yes you're right on that
spectranaut_: yes it's just a platform API
chrishtr: is testing in WPT a requirement for new things?
spectranaut_: we'd like it but it's not blocking
keithamus: I can't make a firm commitment at this point but will say GitHub sponsored this a while ago and if one of them would be interested in landing it I would be happy to coach them through it
chrishtr: for purpose of landing this, that's probably not firm enough?
spectranaut_: exactly
jcraig: I'll give you another not firm enough statement… we certainly intend to at some point but don't have a timeline at this point
<spectranaut_> w3c/
spectranaut_: ok, let's talk about the next PR… from jcraig
jcraig: it's 6 years in the making
jcraig: we had full review across the board
jcraig: and not quite good enough support from Chromium
jcraig: this has been a long time coming and I would love to see it merged during or before TPAC
jcraig: reason there is a new PR is that previous ones were before Prettier and other tooling so wasn't worth redoing. So it's the same content but a fresh PR
jcraig: keithamus specificially would be nice to have review this as we haven't had a Mozilla review for it yet, we did have a Google review before
keithamus: I'll happily review it
chrishtr: jcraig, who reviewed from Google?
jcraig: Aaron Leventhal and Brian @@@ and I think Valerie
chrishtr: is implementation (in WebKit) straightforward?
Rahim: relatively easy aside from finding descendant nodes matching the criteria; but yeah pretty easy
Rahim: didn't have to implement anything new, methods I used were already available
jcraig: we thought it'd help with @@@ search, but authors didn't like it so we switched to depth first search… should be easy enough either way
chrishtr: will check with people from Blink so we can unblock this
<Rahim> WebKit PR for nameFrom: heading: WebKit/
Rahim: quick question for jcraig on the PR… (2650)
Rahim: re roles affected: I wasn't aware form and region get name from heading?
jcraig: great question, could you put it in the PR? that was from the previous patch, hadn't looked back to check why we had it for form and region
matt: I thought we left region out of this… because it requires a name and if you don't explicitly add a name the region the AT will ignore it?
jcraig: yes… but this PR and previous PR had changed that. Will take that as a note, this is why I rerequested review
matt: that change to name from region happened at a point that may have been before the last review?
matt: and we also changed dialog during that time?\
matt: could become a tricky validation rule?
jcraig: I'll take these notes
matt: we'll need to think about how it affects validation and authoring rules and normative statements
jcraig: if you want to review this, matt, I'll add you
matt: simplest way to move it forward may be… that it doesn't affect region or form
jcraig: if that's the right solution it would be easiest, but if it's the wrong solution probably not?
spectranaut_: any more comments on this PR?
siri: may be good to have names from headings, but if the author wants can they override this?
jcraig: this never overrides names from authors, aria-labelledby and aria-label would override
siri: in the next version of ARIA, having labels requirement changes, how does this work?
jcraig: previously for dialogs it explicitly said it must have a label now it says SHOULD
spectranaut_: then we have two more issues that are editorial, we don't need to talk about them
WPT Open PRs
spectranaut_: there is a new PR from Mike… for web features
mike: I can have a look over this
TPAC planning
spectranaut_: just a reminder, we'll be planning to agenda soon, please add F2F candidate issue asap if you have them
CSS: handing the a11y of anchor positioning
Daniel: Peter sent regrets
spectranaut_: Peter wrote in the issue we have two implementations for anchor positioning
spectranaut_: should we wait for Peter for this one?
spectranaut_: let's discuss in another week
chrishtr: if next week I can make sure Chrome folks are present
Should ARIA boolean-like attributes behave like HTML boolean attributes?
Rahim: James raised a good question re how ARIA IDL attributes are different from HTML IDL attributes
Rahim: if you use `aria-required` with empty string, it results in false
Rahim: should boolean-like ARIA attribute behave like HTML boolean attributes?
jcraig: some will equate to false, some are true/false/undefined, where undefined is a separate value than false and it means something different which implementation figures out
jcraig: it's based on element or some other determinable aspect of the DOM
jcraig: there's a lot of overlap that's possible
keithamus: there are a couple of attributes in HTML that behave the same as these, that have enumerated keywords of true and false
keithamus: like spellcheck, writing suggestions and draggable
keithamus: all three, I think, reflect the content attribute and resovle to true or false but that's not reflected to the IDL
keithamus: i don't think it's particularly alien for these properties to do what they do
keithamus: this has a higher degree of web compat risk and potentially paints us into a corner, would have a stronger objections to this than I did to the prior work for enumerated attributes
Rahim: I figured as much, thanks James and keithamus
Rahim: now that we've migrated a lot, might be worth looking at more of these attributes and ensure to align with best possible IDL types
front-endian-jane: this would also cause a number of problems on the author side of things, as there's so much documentation about this. On the author side we can see more confusion about how HTML does booleans than how ARIA does booleans
front-endian-jane: not a 100% against this, but if we change this it could cause a lot of uproar among authors
jcraig: I also vote for the enumerated string values, also considering the extensibility argument that keithamus brought up
jcraig: because it's never been boolean, we can be sure there's no authors that are using this for comparison
jcraig: so there's less web compat risk for enum than boolean
jcraig: and there's no web compat benefit to changing it to boolean as far as I can tell
giacomo-petri: wanted to add to author confusion point that jcraig brought up… I see a lot of code with aria-disabled=true/false, eg aria-disabled=false. Can imagine changing this would cause a lot of problems with authors
jcraig: to clarify, giacomo-petri… when the author set the value to false, what wouldn't work?
jcraig: wouldn't it still be an invalid value?
jcraig: that falls back to false?
front-endian-jane: I can't remember the exact details, but I've seen something similar to what giacomo-petri was saying
keithamus: I think the general thing to take away from this, enumeration with a string true or false is probably a bad idea, want to use aliases like on or off instead… if we had something like aria-checked=on or =checked, might have eleviated some of this
ARIA IDL updates: enumerated attribute conversions, new "enumerated" wai-aria type, IDL examples
Rahim: more IDL fun!
Rahim: got some good feedback from James and Anne
Rahim: first issue, aria-haspopup… I believe true and menu are synonyms… which is the canonical value, true or menu? and how should ARIA reflection works when this is provided?
keithamus: I think we should define it such that it's not the string 'true'… I think there's already mechanics for the canonicalisation of keywords
keithamus: so if there was a string 'true' in the DOM it would be returned as 'menu' in the IDL still
keithamus: so just depends on which way we would canonicalise
Rahim: in IDL reflection, do we want 'true' or 'menu' to reflect as the same values, should they be synonyms?
jcraig: wanted to ask Matt_King… sorry if you're the wrong person… wasn't there a point we made 'true' the canonical value?
Matt_King: in 1.1… I'm not sure if it became an antipattern… what happened was the original values were only added to get some compromise in what we needed for just the combobox role
Matt_King: we kept true as a synonym to menu for compatibility
Matt_King: I kind of lean into keithamus's direction… based on how aria-haspopup has been used now… quite a few people argued for using the values of haspopup in other places than combobox, particularly buttons
Matt_King: not sure if there's consensus on that… can't see what the problem would be of making menu the canonical value
spectranaut_: re Rahim's question just wanted to say re how ATs handle these values… aria-haspopup=true is handled as aria-haspopup=menu in accessibility APIs
spectranaut_: so menu is the default
<spectranaut_> https://
Rahim: ok so 'menu' would be the canonical keyword with 'true' as a synonym
Rahim: someone asked me… why would aria-haspopup return null instead of false?
Matt_King: it's like aria-pressed… if you have a button where it's not set it's null but if there is one it's false
jcraig: may be different if there's a native control that uses aria-haspopup where we'd use undefined as the missing or invalid value
Rahim: ok so aria-haspopup will return undefined state which is null
Rahim: false and empty string return false I believe
Matt_King: this could be one of the places where we want 'false ' to return 'undefined' because we had 'true' return 'menu'… enumerated things that initially, in ARIA 1.0 was a boolean
Matt_King: maybe we should go away from false entirely here
jcraig: not sure if undefined is any better in that regard
Rahim: so sounds like 'false' remains a valid keyworrd?
jcraig: have to think about that some more
keithamus: would be open, but would probably raise similar conversations up until this point, especially regarding web compat
keithamus: if we start returning entirely new values, a lot of guidance may have to be updated
jcraig: hm maybe not worth doing in that case
Rahim: next question, how do I specify undefined in the attribute values table?
Rahim: please review that when you look at the PR
Rahim: there's some overlap between concepts of undefined state, and the "undefined" string value
Rahim: last time I took away it's okay to use an undefined state, but undefined string value is provided to the content attribute it would be for a missing value default
Rahim: folks that are interested, please take a look at that section
Rahim: when MDN talks about content attributes, they list undefined as an actual value, which I think wasn't the intention, it was for the absence of the value to be undefined
Rahim: another question, last time we talked about this there seemed to be consensus to add an undefined state. My question is should all ARIA attributes that support null be specified as an undefined state?
Rahim: there's an explainer linked from the PR description, it has a table for all the updated attributes,
Rahim: should everything that has `null` be undefined state?
jcraig: I think that's probably editorial errata in the past?
keithamus: I think I mentioned a while ago… I think we don't have to have the undefined state, if we don't mention it in prose
keithamus: there might be no point in labeling a state… labeling them the undefined state might make it more confusing
jcraig: i recall you suggested 'no state'
jcraig: I recall because we had the string value of undefined that had previously been there, we wanted the reflection to match that
jcraig: even if the string value you assigned could map to something else
jcraig: but not sure if there's a benefit to keeping that in this scenario over the NoState suggestion (Update: There is not. Either fine with me.)
jcraig: re Rahim's question , to my recollection everything we call null also means undefined
Rahim: re undefined state discussion, Anne chimed in and discouraged us from going with no state
Rahim: he recommended we name that state
Rahim: will follow up with him and perhaps keithamus and jcraig
<jcraig> s/I recall because we had the previously assignable string value of "undefined" that had previously been there, we wanted the reflection to match that/I recall because we had the string value of undefined that had previously been there, we wanted the reflection to match that conceptually, hence the named Undefined State/