Meeting minutes
<spectranaut> spectranaut: val explains what da needs to do
zakim/ next item
New Issue Triage
spectranaut: first item is pr triage
spectranaut: the first item is on html-aam issue #431
scotto: this was the acc team figuring out how to do accessible automated test rules they had some innacurate ideas about what was allowed here
scotto: leave open for now because theres more to be done
spectranaut: issue #1765, consider calling out aria-hidden expectations for focusable elements--this is a clarification
scotto: has had conversations with multiple developers over the past few weeks. we could use some clarification since aria hidden has changed over the years. it's not always going to hide stuff and the definition doesn't say that
moved to 1.4 milestone
chlane: interested in helping. thinks we need to surface this in aria-hidden definition
spectranaut: moving on to core-aam #130
… doesn't need to be discussed, just a bug in spec
spectranaut: in aria #1764 further clarifications to form role
<siri> Can you add me to aria-hidden issue? Interest to learn the process
scotto: john raised issue in html spec about how form roles need accessible names, but that may not be needed or only needed when the form is a landmark. questions why someone is using a form role or why this is needed
StefanS: if there are multiple forms present this can be helpful
scotto: it would be good to put that in the guidance
StefanS: potentially not needed if there is only one instance on a page, but there could be a use case with multiple forms
moved to 1.4 milestone
CurtBellew: if you had more than one form element on a page you'd have a case for giving it an accessible name. if you had two regions on the page and you wanted them to have a unique name im assuming this would go along with this as well
spectranaut: next issue is #1763 on aria
jcraig: i just assigned that to myself
New PR Triage
spectranaut: first one is html-aam #430
scotto: an issue joanie created long ago before generic existed to indicate there are many elements in html that are not mapped but might bcome mapped if accessibility is added to them. this has largely went away, but there are still instances where a developer could expose not mapped elements and expose them
… would appreciate reviews, or being told to close this as unneeded
jcraig: you can add me as reviewer, can you clarify what you mean by 'if we dont need this anymore'
scotto: take the style element. its not mapped since its not supposed to be exposed, but if someone were to put one in the body of their html and render it as display block--this pr spcifiys that language. potentially helpful in a few instances or might be unnecessary
jcraig: i think a note is super useful--whether we need to go into detail about every possible way is not necessary
scotto: definitely would appreciate any feedback we have on it
spectranaut: next pr is #1766 on aria from jcraig
jcraig: adds CEReactions IDL property. asked for alex's review, but happy to have other reviewers as well
spectranaut: is this editorial?
jcraig: definitely more than editorial, but isn't anything that requires additional tests for aria because they're already tested in the rendering engine and different places
spectranaut: i'll take a look too
… next pr is #132 also from you jcraig
jcraig: we have some weird menuitem in group guidance. we're going to take it out of webkit and remove the guidance
spectranaut: next is #429 on html-aam from scotto
scotto: there is a html-aam issue related and a chromium bug related. this adds language to indicate that a required element should not be immediately exposed as invalid. which is inconsistently the case. html had an issue filed against them as well. this pr adds language to indicate users should wait for an interaction before exposing required fields as invalid.
siri and jcraig added as reviewers
scotto: would make sense to put aaron on here as well since he's already on the bug
<siri> shirsha
spectranaut: last one is also on html-aam from scotto #423
scotto: this adds to the naming steps for button elements a missing label element. because label works on these things and that's been a long standing mission from the naming steps. nothing changing, just a light review
jcraig: can you tell me what that means to add a label
scotto: right now the naming steps list out 'first use aria-label aria-labelledby, next use aria-' but the label element also works to name these. and takes precedent as the second step. label will always win out over sub tree or title.
jcraig: this doesn't need to be called out expclicitely by ACC-Name
jcraig: you can put me on this. i dont have the abiltiy to put myself on these
MichaelC: try refreshing--maybe it will pick them up
spectranaut: were they just added
MichaelC: should be in the same group that i expanded the permissions for. everyone had read access and you need triage access to be on issues
CurtBellew and dakahn offer to review
CurtBellew: noticed label isn't called out like id expect so this seems like an opportunity
scotto: there are a number of inconsistencies with how these elements handle their naming. we're finally going down the path to get the necessary docs to write these things to reflect reality
… so thats coming someday or i might quit the internet
everyone: don't quit!
jcraig: this probably needs some tests
scotto: yeah i do agree. so i could use some help on where we could post those test. i know we have platform tests, but this has been a spec that hasn't really had anything going up there. happy to write the tests myself
siri: help me understand
<jcraig> <label>bar<button>foo</button></label>
scotto: you could have a button element and you could have a label element -- the button element could have an empty subtree, but the label element could have content in it
… in the cases of nesting a button inside of a label theres more to do
<jcraig> ^ Is this "foo" or "bar" or "bar foo" or "barfoo" <label>bar<button>foo</button></label>
spectranaut: the fact that we dont have tests seems like somethign we need to resolve. an action item for a later meeting
Deep Dive planning
spectranaut: deep dive planning. next week we have dialogs and the week after that we have popup. any other items anyone wants to have deep dive for
dakahn: what kind of things can we have deep dives on
jcraig: anything tangentially related to what we're working on but that might run over a regular meeting
Announcement: TPAC registration is open
spectranaut: reminder that cpac registration is open and early bird rates last till august 5th. also there is a charge for remote attendance
scotto: so we have to pay to go to a meeting? sign me up!
<MichaelC> https://
Reminder: 1.3 prioritization action items
spectranaut: we started to talk about how to prioritize 1.3 and as a first step we talked about putting labels on the issues assigned to us so we can prioritize what we need to keep/move. please look at all the issues assigned to you under the 1.3 milestone. jcraig did all his homework already so good job!
Review/revise mappings for input type=file
spectranaut: review revize mapping for input type="file"
scotto: why dont we skip this one this week
… lets do the white space one
"Whitespace characters" underspecified
spectranaut: so this is a 1.2 blocking issue. its something we have to get resolved. the issue is that white space is under defined as far as i can tell.
… looks like theres been some discussion on this
pkra: just checking if we needed to do more work on this. looked at the aria tracker to see if it had come up in the past year or two. i dont have any particular feelings about it
jcraig: i have a feeling that we should avoid at all costs specifiying the particular unicode. if html does this already we should point to that
<pkra> https://
scotto: i believe they do. i linked to the html-aam in pr. i started working on this back in 2019 and then the world ended so i stopped. html does have something specified
… in #239
… i had taken a stab at doing something for this in html-aam. dont remember what i wrote, but linked to it here if there was anything useful for core aam. if we are going to define this it makes sense to not just do it in html aam
… i would submit this is not the place for this. we should point to html have alread identified
jcraig: space separated tokens is different in this context, but id be surprised if html didn't have this defined
pkra: there are links to the html spec and white space definitions. there are braille specific white space attributes to consider
spectranaut: its not clear we can just point to the html spec or any of the others
jcraig: theres probably someone who knows the answer to that but not on this call
… in the html working group would be my guess. one of those editors
spectranaut: if you think someone from html could answer a question ehre could you ask them in an issue
jcraig: i will
spectranaut: sounds like no one is enthused to champion this issue for the sake of 1.2 getting out the door
pkra: are we talking about core-aam or 1.2? it was filed against core aam
spectranaut: my understanding is its a change we'd have to do to 1.2. or is 1.2 blocking but maybe MichaelC would know
MichaelC: i dont know the answer off hand
scotto: i think its core aam 1.2 not aria 1.2
spectranaut: isn't core aam 1.2 blocking aria 1.2
MichaelC: once it transitions to CR
spectranaut: is this something that blocks it going to cr?
MichaelC: i dont think so. we can always just say we're not addressing this issue now and go to cr and see if people object. since we're going evergreen shouldn't be a big issue
spectranaut: maybe the next step is to get input from jcraig from html. doesn't seem urgent
pkra: unicode has a concept of whitespace--why is that not what people refer to when they talk about whitespace
spectranaut: if you want to look that up and reference it in the issue--i dont know why
scotto: we need this resolved--do we count white space characters and whitespace characters alone as an ACC-Name? seems like a bad idea
pkra: surprised this hasn't been solved. how is this something that a lot of specs haven't run into?
spectranaut: looks like all the specs are doing it on their own
jcraig: all the more reason to not duplicate that work. find the best one and point to that
spectranaut: anything else to say?
Columnheader roles do not work with the abbr attribute
spectranaut: its another scotto issue, sorry. we only discussed half of this last time. said we wanted to discuss aria-cellheaders
scotto: dont think we can get through that in 5 minutes
spectranaut: maybe we'll stop 5 minutes early for once
rrsagent