Meeting minutes
<spectranaut> hi everyone, we have a new zoom link, stay tuned
<jamesn> https://
<jamesn> that is the old one - don't use that as it is not updated
<scottono> passcode....
<spectranaut> james is working on adding the correct link to the invite
oh did it change? that might explain some things
<jamesn> the correct info is in the meeting invite now
New Issue Triage
jamesn: bunch of new issues today
jamesn: #164?
spectranaut: no need to discuss today
jamesn: #1868 - editorial, i'll fix
pkra: give it to me
jamesn: #1866 - tracking issue, editorial, targetd for 1.3
jamesn: the acknowledgement section is getting long, shortening seems good
jamesn: #1865, already made a fix, PR against 1.2 to update participants is out there'
jamesn: should be shortened into a paragraph style, rather than a bulleted list (still a list in markup though so can be easily skipped if needed)
jamesn: #458 - jcraig?
jcraig: scottono and I have talked about it already (btw, ER stands for enhancement request)
jamesn: can we have a label for enhancement or something instead?
spectranaut: make it so!
jcraig: i'm on it
jamesn: #185 - yep, agree. is this a duplicate though? jcraig?
jcraig: yeah, i've got a PR for that
jcraig: will mark it as a dupe
pkra: i don't think your PR necessarily solves this jcraig
jamesn: once we get rid of some of the levels, this may no longer be an issue
jcraig: assign to me in any case, i'll sort it out
jamesn: #184 - could this go into core aam instead? i'd be okay awith that. joanie only wanted things that were different by platform in there, this should be consistent
jamesn: could go into ARIA itself, too
jamesn: once we have the text we can figure out where to put it
scottono: makes sense
sarah_higley: functionally it's already there it's just not descriptive
jamesn: i'm most comfy with accname being its home. might be better to change the shortname though
spectranaut: agree
jamesn: #1863 - on the agenda
jamesn: #457 - agree. will assign scottono
jamesn: #1861 - on the agenda
New PR Triage
jamesn: #186 - some updates were made, needs reviews
jcraig: would prefer priority for this, will create conflicts the longer it's out there
jamesn: will also add melanie, we'll take whoever approves first (melanie or bryan)
jcraig: should be more editorial than anything
jamesn: other spec that refer to this will need to be changed too, right? e.g. "in step 2D of accname..."
jcraig: in theory the links should still work. if they're still looking for 2C, the list style should still be there
jamesn: oh! got it
jamesn: i'll try to add a githack link so we can see the full preview (with CSS) when i review it
matt_king: 2A 2B 2C etc. are still there, right? what happens if we rearrange?
jcraig: we could do that, but the references won't rely on the numbers anymore, will rely on the step title (like "Computation" etc.)
jcraig: any legacy link should remain working in perpetuity
matt_king: wondering if the brokenness of those kinds of static references would be more obvious if the letters weren't there (just a ponderance)
jcraig: that COULD happen, i wanted THIS update to be as minimal as possible
jamesn: next is #1867 - this will be merged, review if you like
pkra: add me
jamesn: daniel, can you merge once peter reviews?
daniel-montalvo: yep, will do
jamesn: #459, already merged
jamesn: #183, has 4 reviewers, no changes, let's get some reviews in
jamesn: #1862, on the agenda
jamesn: #1860, waiting on two reviews
Deep Dive planning
jamesn: any proposals? if not, let's move on
[silence]
H1 F2F Survey
jamesn: survey is out for F2F, please fill out whether you're planning to attend or not (not selecting ANY checkboxes for dates/locations would be read as not attending)
jamesn: there are options to signal attending remotely if that's doable but physical is not
jamesn: the sooner we can do this, the better, for budgets etc
jamesn: current proposal is Adobe or Google hosting
jamesn: i'll send the link out to the list, it's in the agenda if people need it
Review deprecation processes for ARIA attributes (and roles?)
jamesn: no process for this right now, would probably be helpful to have
jamesn: from my POV, we shouldn't have to deprecate all changes. not everything being removed, or planning to be removed, should have to go through deprecation before that
jcraig: one other potential is a synonym. presentation had lots of confusion as to why we didn't deprecate, but added the "none" role and called it a synonnym
Matt_King: another instance of something like that is the application role
jamesn: we tried to guide usage, but there's nothing normative that REQUIRES it only to be used in certain places
Matt_King: we changed that in 1.1 i thought?
jamesn: there's only one MUST in there, discussing non-decorative text
jamesn: we only really wanted to guide people into NOT using it, not deprecate it
jamesn: there's been a number of changes made in the spec where we removed the ability to use something on a given element WITHOUT going through a deprecation process. i don't think we should start doing that, as it might cause more confusion than it alleviates
jamesn: formally, sure, it might be good. but in practice it can lead to more confusion than not
spectranaut: seems that it might be whether or not it can be clearly deprecated or not. is it not widely adopted; is it not accessible; does it break something? things like that might not need to go through a deprecation process
jamesn: we got pushback on the globals where people had one of them on their pages, and we removed it/deprecated it because it wasn't doing something useful, and people got confused by that
jamesn: not sure what the difference might be between removing something, deprecating something, or a prohibited attribute. one is just marked as an addition to the spec (prohibited), and the other is marking as deprecated and giving X time before removal
spectranaut: this is making me realize we should have an "update validators" step on our review/publication process
scottono: my pov is that, if it's not helpful, and it's causing false positives etc., it's better to just remove and deal with any pushback
jamesn: if something is actively making things worse, it's better just to remove, and not deal with deprecation
scottono: +1
spectranaut: that segues into...
Remove aria-expanded from listbox
jamesn: this almost feels like a red herring; i don't think that's consistent with other removed attributes, feels more like an exception to the rule
sarah_higley: the other attributes mentioned were those global ones
jamesn: and this isn't like that
jamesn: are there thoughts that aria-expanded on a listbox does ANY good?
Matt_King: we DID mark it as deprecated in the APG, has been so for about a year or so
jamesn: the fact we deprecated that in 1.2, then does it make sense to remove them in 1.3?
Matt_King: it does to me
Matt_King: we point people looking for it to the select-only comboboxes, which is now pretty well supported
jamesn: so removing this would be a GOOD thing, because they'd get validation errors if they're using the old 1.1 comboboxes, right?
Matt_King: i don't see any harm - there _may_ have been in 1.2, but there was language added to address concerns with input type=text, so there's no need for expanded on listboxes
jamesn: so then, does the old 1.1 pattern work?
Matt_King: yeah, and the example is still there in the index, but it's not linked from the pattern or other examples
jamesn: so then why remove something that does something people kind of want and works?
Matt_King: it's an antiquated substitute, and the new approaches should work even better
sarah_higley: in theory a menu could be built similarly, with aria-expanded, but we don't support that
sarah_higley: the APG isn't a spec, and a listbox being built that does a bit more harm than good. if we go with precendent that anything announced should be added to a role, that'd be a lot of work to add things to the spec
jamesn: so the listbox expands itself?
Matt_King: not really - when it's collapsed, it's more like a div with one element, then expanding that would create a separate list with listitems
jamesn: that makes me feel better about removing it, as aria-expanded doesn't technically allow for that
Matt_King: it's definitely a bit wonky
jamesn: so then how about we just remove it? objections?
[silence]
jamesn: i hesitate about the deprecation because i know what the JS is doing and does for that, from when we did the globals, and it's hacky and gross
jamesn: it would make already treacherous code worse
Matt_King: so there is a bit more harm than good; there are implementations out there using it; it'd require validator changes to actually throw an error...
Matt_King: even if we just call it no longer valid or remove it, it doesn't mean things just stop working
sarah_higley: but it doesn't _work well_ as is
jamesn: if things don't work, then we should make the change so validators can let people know
sarah_higley: that was from a while ago and I'd have to check again to confirm
jamesn: okay, thanks sarah_higley
Draft: aria-actions addition to the ARIA spec, VoiceOver feedback
jamesn: i just want to make sure people have seen this and read it
jcraig: in summary, sarah_higley, aaron, and I had a discussion about this. a lot of it is based on what Apple does for AT
jcraig: this is different, because it doesn't rely on other elements having something done to them, but because we tied it to a click event in the webAPI, there's a chance it could cause a focus change or click on some other element. so we were discussing if it'd undo the benefits of aria-actions
jcraig: i think most people would use it as intended, and the risk is low.
jcraig: we did find some things that'd be unexpected, but the cost to dev and user is minimal, given what the API would allow people to do
jcraig: the question that remains is what happens when authors do this? we could outlaw it in the spec with some MUST NOTs for UAs. my opinion is to synthesize the click anyway, there could be some weirdness, but it should allow users to to figure out what's going on anyway
jcraig: my general view is not to outlaw something authors could use for good
Matt_King: i have some comments about this that I'll leave in the issue