Meeting minutes
Change tooltip to name prohibited
wilco: we have a project board now.
<Wilco> https://
wilco: dan's PR 2075 wasn't merged?
kathy: that link is 404
wilco: ah yes there's an access problem
… I'll screen share then
… will figure out access later
… dan's PR is ready for call for review
… send call for review email to CG mailing list
… look in inbox
… unsure - ping on slack or smt
godwin: website work. doesn't render well. I put it up on personal url to see what it looks like.
… didn't realize that script made a commit to w3c rep
*repo
… also want to write up a developer's guide in the project somewhere.
wilco: ping me when you've got anything ready for review
godwin: I think it's ready.
wilco: giacomo you mentioned you were interested in a "thing has accName" project
… do we want to note that on this project board as a potential future project?
giacomo: yes
wilco: (adding it on project board)
… that's all the project work.
… (stops screen share)
Change tooltip to name prohibited
giacomo: nothing special. just aria WG decided that tooltip can't receive accName. we have a rule for that. but not impacted b/c we don't have examples for tooltip.
<Wilco> act-rules/
giacomo: but if we want, we can add an example.
wilco: so do we want a rule for this? my feeling is that this doesn't map to any wcag reqs.
… any disagreement? i.e. this should be an aria-only rule.
giacomo: if you set accName to tooltip, potentially it might override the content of the tooltip. that's the real problem.
… depending on UA/AT.
shunguo: tooltip for accname is from "co-mapping" (?)
… for some things like buttons, tooltip, input field - tooltip can be part of accname.
<Wilco> https://
(core mapping not co-mapping)
wilco: I don't mind the rule
giacomo: I'm not asking for new rule. asking if we want to add example to existing rule.
… rule ~ "are aria global properties used where not permitted"
… so pretty straightforward
giacomo: we fail eg. divs, paragraphs, role=none, ... that's it
wilco: specifically aria-label/labelledby prohibited, correct?
giacomo: yes
… might be useful to provide example w/ non-generic role
wilco: problem potentially is that this is not prohibited in aria 1.2, which this rule still maps to.
… actually that's a good reason not to do it.
… however, it might also be time for us to switch to 1.3.
… that would be a larger project.
giacomo: aria is an evergreen spec. it changes when the tech has already supported things.
shunguo: accName calculation is a big one. we can't just ignore it.
wilco: we should probably create a project to migrate to aria 1.3.
shunguo: so if we think tooltip shouldn't have an accname, we should first open issues there (?)
wilco: is it time for us to migrate to aria 1.3?
shunguo: agree
… my understanding is that it's now a living document.
<giacomo-petri> +1 to migrate
shunguo: it's more like html 5 today.
wilco: I agree
… so let me add that as a project.
me: is this "living document" status documented?
shunguo: no
… not official
wilco: difference is that html 5 is an "actual living doc" but aria just uses it's editor's draft.
ARIA normative change -- Add heading and separator roles to feed's allowed accessibility children
<Wilco> act-rules/
wilco: this is an open PR. not in the spec.
… probably generic for all of these issues. the FYI is: they're adding some allowed roles to "feed".
… this feels unimpactful. one this lands, we may want to do something. I don't think this changes existing rules. I think we can just say "yup, acknowledges".
giacomo: I checked act rules for aria. not impacting. might be worth for us to clarify. changed from "required a11y children" / parents with "allowed".
… we might want to clarify what it means. generic/intervening - aria wants to say that empty elements are ok.
… list required listitem children. now /allow/. so now you can have <div role="list"> without listitem children. but we as act might want to add something.
wilco: we already allow empty parents, don't we?
wilco: this is not saying "this has to own it". it's saying "it can only own it".
… i.e. not requiring. prohibiting other.
… would you suggest thought that we should require certain children?
giacomo: not really. something like: rule that says here are the aria-allowed children.
wilco: we don't test this the way aria says. we've done it this way: "you can have these children and nothing else".
giacomo: we probably need to change the definition.
wilco: yes this rule does need to be updated.
… as per aria 1.3.
ARIA normative change -- Relax aria-valuenow requirement on slider role
<Wilco> act-rules/
wilco: I think this is a similar story. not merged yet, but it will be.
… and once it is, we should probably add an example.
giacomo: we have passed example 13 in "aria state or property permitted" but not impacted
wilco: another example would be good here.
ARIA normative change -- Add transparent generic definition and update accessibility parent and child defs
<Wilco> act-rules/
wilco: this is probably more impactful for us.
… I like that we have a definition of this now.
… we're finally defining this. long time coming.
giacomo: all the 1.3.1 are not listed in aria rules. but of course they are affecting wcag SCs. but filter should display both. should be both in 1.3.1 and aria section.
wilco: they're mapped though
… problem is bigger than thta
*that
… it's listed under SC 1.3.1. but it has 1.3.1 as a /secondary/ requirement.
… I don't think we want secondary requirements at all. this is not guaranteed to fail 1.3.1.
… godwin we have more work there
<Wilco> https://
wilco: (sharing screen)
… showing rule X. a11y reqs mapping. under ARIA 1.2. 4.1.2 is a secondary requirement.
… let me check if this is the approved version of the rule. no. this is the proposed version.
… let me go to the approved version. can't. it doesn't have an approved version.
… so this rule should not be ... want ... where did my requirements mapping go? weird. will have to investigate.
godwin: this was raised on changes page. all of the links say "proposed" in the url no matter what state they're in.
wilco: that shouldn't happen.
godwin: you can't go to deprecate it. that will be a 404. they're all just "proposed".
wilco: those links should be the approved...
… we have a redirect from approved to proposed url. all should link directly to approved versioin.
… is that not the case? no it's not.
godwin: is it supposed to be with "approved" in the url?
wilco: no, just doesn't have "proposed".
… so we have some work here.
kathy: question about 1.3.1 as a secondary requirement. in passed example 3, if aria-expanded is not valid on a tree or something, and it is expanded, I can see why that would be a 1.3.1 issue.
… if you have aria-expanded undefined on a tree that's not expanded. then 1.3.1 could fail there.
wilco: yes agree. the state is not conveyed. probably more 4.1.2. but yes.
kathy: I thought you were saying that 1.3.1 should not be a secondary requirement.
wilco: no I think it should be.
… I don't think it should be /listed/ under 1.3.1. only listed under "primary" req.
<Zakim> giacomo-petri, you wanted to talk about transparent/generic definition (after this discussion)
giacomo: you mentioned how this might affect our rules. I just checked and found a bunch of failed examples that now should pass. eg. <ul> with empty divs inside.
… goes with "allowed a11y children". so we can work on them together.
wilco: I'll give that a "maybe". I saw james gregg (?) made a change request. probably safe to wait until that's resolved.
giacomo: james' concern is: they want flexibility in removing element from a11y tree.
… what is relevant for us is "ul with empty divs inside" are no longer failing.
wilco: the other thing is: I don't think firefox works this way yet.
… I'd want to wait until firefox is on board.
… I think firefox ignores those generics. there's still an accessibility problem. I tested this about two weeks ago.
AOB
wilco: final thoughts?
me: label in name PR progress - great - thank you
kathy: congrats dan. lotta work.
giacomo: thank you all.
sasha: no thoughts today
godwin: not much. should consider adding me to scribe list.
shunguo: not much. I was very busy for first few months. thank you.