Meeting minutes
New Issue Triage
https://
cyns: assign to me, i've worked on this
spectranaut: 1.3?
cyns: yep
spectranaut: next --
https://
scotto_: for triage purposes we shoul dbe good to go, might need discussion later. it's assigned to me anyway
spectranaut: sounds good
cyns: 1.3?
scotto_: it's HTML AAM
New PR Triage
https://
scotto_: this one needs review, and a discussion
scotto_: steve faulkner has started in on making sure the outline matches what exists in reality
scotto_: a good time to work on it. the hgroup is being respecified to allow for a single heading element and perhaps paragraph elements to serve as subheadings
scotto_: there's a bunch of hgroups in the wild that contain multipl eheadings
scotto_: this PR is to indicate that these hgroups should look at their children, and the highest level heading should be respected
scotto_: for discussion -- is that what we want? does this tie into dpub? does it need something like a a role of subheading?
scotto_: that's the gist, i just need reviewers and people to weigh in on discussion if necessary
spectranaut: so maybe this should be an actual meeting discussion?
scotto_: or can be resolved in the comments
jamesn: does this need to wait until the PR from steve lands?
scotto_: yes, arguably, but could discuss anyway. doing something with hgroup as it exists now, there's room for improvement
scotto_: we could review the current [hgroup], but i'm mainly looking for discussion right now
jamesn: should this be a draft PR then?
scotto_: i can do that, i just wanted to discuss today
spectranaut: reviewers?
jamesn: i will
spectranaut: cool. next --
https://
spectranaut: seems like a small change, editorial?
jamesn: i believe it is, we could just change this example
pkra: yes it's an example, but the change is in AOM
jamesn: a change to use something that isn't as complicated
jamesn: lgtm as is, right now.
pkra: i'll take a look
spectranaut: cool, next --
https://
spectranaut: just an update to an example, already reviewers assigned
Deep Dive planning - today (before this meeting) - OpenUI, next week Dialogs
spectranaut: we just had a sync up with OpenUI and now having regular meetings to improve comms with them
spectranaut: any plans for new ones or any that anyone would like to add?
aaronlev: we might want to put some of the specific things that are discussed in OpenUI into those deep dives
scotto_: +1
jamesn: once they get tagged w/ us, then we might want to
aaronlev: right - there's lots of overlap. sounds like ther's a lot of discussions re: aria happening. not too late to get involved, but we'll want to soon -- I also worry it might flood us all out a bit
jamesn: let's wait to see what gets tagged to us before making any decisions
aaronlev: if i find somethin specific for a deep dive i'll add something
jamesn: +1
APG Migration - do we need group approvals?
spectranaut: from Jemma - go ahead!
Jem: two things - we're aiming at updates for APG on May 18. wondering if APG would need to go through an approval process. if so, what's needed, what steps do we need to do, etc.
jamesn: to clarify - every time that an APG note was published in the past, the WG gets a chance to review first (though we usually gave standing approval)
jamesn: do we want to allow APG-TF to publish without approval? I personally say yes, as many TF members are also in the WG. APG's update process is also very thorough
jamesn: but it's a groupdecision, please let your opinions be known
[silence]
jamesn: realisticall, we might want a CfC just to get the news out there. I don't think it could hurt
jamesn: would also give APG the ability to publish updates without WG being involved?
spectranaut: sounds good to me
jamesn: i can do that today, i'll make it a 48hr one - shouldn't need much debate
Jem: the reason we're working on a redesign, we want to be able to keep it as up to date as possible, rather than having to wait so long for approvals etc
spectranaut: making it more evergreen
Jem: right!
spectranaut: that's great!
Combox example code is missing accessible name for the listbox
spectranaut: this is what PR 1728 was related to, right?
siri__: i think this is taken care of
jamesn: it's the same thing as previous. we were discussing in APG on Tuesday (4/26)
Bryan: i think we decided to go with the fact that listbox needs to be labelled, even if it's not explictly focused, and the combobox is
jamesn: which is to say, we're going with Jon's example
Can we close? Inconsistency between native and ARIA listboxes when implicit aria-selected is provided agendabot]
spectranaut: just wanted to make sure we could close this issue. Sarah, do you think your PR sorts this?
sarah_higley: i believe so, but if anyone else has thoughts please let me know!
spectranaut: i think we can close then, just wanted to make sure everything was covered
sarah_higley: please reopen if anyone disagrees :)
Support aria-description
Bryan: I think the last comment was asking for more clarification, not sure of its current status
scotto_: I agreed with jcraig's review, my only other comment is concering the HTML elements. either needs to be outlined as a subset to allow for more clarity, or we need to pull in ALL the stuff. not sure what the best way forward is
Bryan: I'm not sure either. aaronlev, jamesn, any comments?
jamesn: i dont have any
aaronlev: let me take a look
scotto_: my feedback in my review is that i agreed with jcraig, but I wasn't sure about the inclusion of the HTML attributes
scotto_: title makes sense, but I'm not sure about value, for instance. there's a case that these things should stay part of the accname for these elemnets, rather than descriptions
scotto_: particularly because of WCAG - if some of these things aren't part of the accname, they won't be as accessible for STT
scotto_: i think this might need some review in general, it might not be right
aaronlev: we could make a followup issue
aaronlev: it's basically to help simplify things for a browser when calculating a name or description
aaronlev: we'll probably uncover more things as we discuss. it's not that i disagree, but maybe just to go with the flow for now
scotto_: that makes sense. but if it changes here, maybe it needs to change elsewhere
scotto_: and details/summary, summary doesn't provide anything to accname anyway...
scotto_: there are things covered here that aren't in HTML-AAM and vice versa. so really, where does it need to live?
aaronlev: i was just trying to make it readable, really. i think having a table with an order of preference is much easier to read, rather than what exists (outline of logic)
cyns: more of a test driven spec - inputs and outputs - than implementation driven?
aaronlev: kind of like a checklist, i just want to make things readable
scotto_: if we want to keep examples i think that makes sense, but also need to know this doesn't cover everything
<Jem> ack
scotto_: i'm fine either way, but if there are varying rules, we should say see HTML AAM for examples.... or exactly what to do. there's a lot in many places
aaronlev: that makes sense, and would love some help.
aaronlev: as long as the info is covered, and it's *understandable*, I don't really care what spec it's in as much
aaronlev: i think it's more an issue of readability and human-optimization, vs. browser implementation
scotto_: so, what would WG like? to include all applicable elements *here*, or make HTML AAM spec in line with this table? which i'm happy to do. if that's the case, I'll remove steps 3-5 and reference HTML-AAM
<Jem> +1 to Scott's suggestion
scotto_: same info, but less hunting for things
aaronlev: sounds good to me, i'd like to review
Bryan: it makes sense to document it as fully as possible, if you're willing to help with that. can get a lot lost in translation
scotto_: so do it all in accname?
Bryan: right
scotto_: that sets a precedent then that accname is where we specify everything
aaronlev: for names and descriptions, yeah
Jem: my +1 was for HTML-AAM
scotto_: in recent memory, i got lots of pushback from SVG and Math about defining anything in HTML for those bits of content - they wanted me to point to their specs
scotto_: i'm fine with bringing this HTML content over, but the other editors may not be
aaronlev: can we see a draft of what your thinking, with everything collated but linking out?
<sarah_higley> sorry, have to drop early. +1 to HTML AAM
<Jem> +1 to Aaron's suggestion
scotto_: yeah. i'll move forward with things, let me know your opinions as you have them
Initial aria-textseparation (depends on generic PR being merged)
spectranaut: what's the status of this one then
scotto_: i think we talked about this recently - matt is going to do the work on it, and in the short term i said Core-AAM could have a note in it that div and span map to generic, but the CSS display affects how AT will respect those
scotto_: can someone help write the note for that?
spectranaut: info for what needs to be done is in Core-AAM #112
spectranaut: this would be a good "good first issue" issue
spectranaut: lets add a tag like that to core-aam
spectranaut: how urgent is this?
scotto_: it's been blocking me for a bit, to be honest
scotto_: div generic and span generic had different mappings. to say they're both the same generic is disingenuous, and loses nuance
jcraig: i can try, add me to it please
scotto_: i'll add you to the assignees
spectranaut: Core-AAM issue #112
spectranaut: are we just waiting for Matt then?
scotto_: nothing else at his point, that note is what will give us some more breathing room on this
1.3 triage
spectranaut: who's ready to volunteer for more?? [laughter]
spectranaut: maybe what we should do is find issues that aren't assigned to anyone and close or reassign
<jamesn> https://
spectranaut: there are 22 issues that don't have assignees
spectranaut: let's begin!
https://
jamesn: my answer to that issue's question is "yes"
pkra: I added this to the owned elements project, relates to cleaning up spec about owned children, descendets, etc.
spectranaut: do you think it will be resolved inthat work?
pkra: it COULD be
spectranaut: so let's leave this in 1.3, then?
jamesn: first thing we'll have to check is if Firefox and Safari do the same as Chrome. if so, should be relatively simple
jamesn: aaronlev, is there a test case for this?
aaronlev: no, but we might've had one somewhere...
jamesn: it'd be helpful for us to all test the same thing on all browsers
aaronlev: i cannot volunteer to write a test case
jamesn: if someone were to write one, could you tell us/them what you meant, then?
aaronlev: that I could do
spectranaut: i can write a test case
spectranaut: if the test case passes, easy! if not, more difficult!
spectranaut: next --
https://
pkra: this has a PR and is waiting. should be simple
spectranaut: no need to discuss then
jamesn: is it waiting on me?
pkra: i think it might be - have a look if you feel it
jamesn: i'll look
spectranaut: next!
https://
pkra: another editorial
jamesn: one of the editors has to handle this one
pkra: assign me
https://
spectranaut: we discussed this, i think.
jamesn: my first question, do we envision changing the association list stuff into stable in 1.3? we didn't put it in 1.2...
jamesn: do we see association list etc etc etc as useful things in ARIA, or were they just for role parity that no one asked for?
scotto_: we need to do them now, term and definition aren't DD DT DL elements - so it's hard to know what to map everything to for parity
scotto_: it's a little confusing as is, and there's not a lot of consistency
jamesn: i'm not sure exactly how much use ARIA would get out of these
siri__: fwiw I don't recommend using DD/DT/etc. often either
jcraig: i want to clarify: sarah_higley voted for the first option, though what I had listed was actually two steps
jcraig: i have no strong opinion on which of the two (list and associationlist) is needing to be kept
jcraig: we shouldn't add any more restrictions than necessary
jamesn: what's that mean if you have listitemkeys and listitemvalues in the same list though?
jcraig: i'm not sure, but I'd wait until/if we see antipatterns emerge
spectranaut: does this need to happen in 1.3? is it a mapping issue?
jcraig: if we're pushing this to 1.4, we should also push associationlist
jamesn: +1
spectranaut: do these need to stay in the spec then?
jamesn: i don't object, I think it could help with HTML-AAM
scotto_: we could drop the idea of making roles for these and specify them individually, noting they aren't consistently mapped and are a little quirky
scotto_: as is, though, there is a problem
jcraig: it'd help with consitent results from browser devtools, and would help with testing moving forward
jcraig: we could improve reliability if we map those
spectranaut: that's a good argument
jamesn: lets take path of least resistance, put it in 1.3
spectranaut: do we need to discuss this more? I feel we didn't reach consensus
scotto_: yeah, agenda+ it
jamesn: i think that's reasonable. i don't have objections to jcraig, as we don't have separate OL, UL
spectranaut: let's get it in a meeting, and then we could find a volunteer