scribe+ dan_tripp

ACT stand-up

giacomo: worked on new rule. aria roles that require accName. updates in ARIA on eg. alertdialog. giacomo updated examples.
... folks are welcome to re-review it. + worked on couple more items.

wilco: working through comments on the new "all rules" page.
... from Daniel, WAI staff. TF side: review on rules format candidate recommendation.
... TF meeting - starting to use as dedicated work time for some of these rules that have been stuck in review for years.
... wilco has been assigned one of the aria rules.

todd: haven't done any work- thursday is physical therapy day - hope to be out of the woods soon.

<CarlosD> scribe+ CarlosD

<CarlosD> Dan_Tripp: Working on making examples work locally or on a Netlify preview

<CarlosD> ... currently it does not work because URL's break

shunguo: been out for a couple of weeks. back this week.

kathy: to add to wilco's TF update: rules format is being reviewed by AGWG for candidate recommendation. on the agenda this tuesday. they're going to add some comments, if there are any. we should have some feedback by next week.

helen: "I've done nothing".

sasha: same, unfortunately.

ARIA ID Reference Error Processing - Requires ACT review https://github.com/act-rules/act-rules.github.io/issues/2337

giacomo: it's simple. new change in aria spec says that b/c of dynamic nature of modern websites, it's allowed to have non-existing references in eg. aria-controls.
... so we'll need to update some of our rules.

wilco: that's that rule we never implemented b/c we thought it wasn't a good idea.
... anyway, what does that mean for this rule? does it need to be deprecated?

carlos: so there is no exception for aria-controls?

giacomo: I think the aria-controls requirement for combobox has been removed.
... yes. aria-expanded is required. aria-controls is no longer required.

wilco: makes sense.

giacomo: scrollbar still has aria-controls as required.

wilco: so it's required, but you can leave it empty?

carlos: or pointing to an element that does not exist?

wilco: how is it required if you're allowed to leave it empty? feels like an oversight by them.

giacomo: probably scrollbar is the only role that requires a valid reference.

carlos: and they do state: authors must specify aria-controls to specify scrollable area.
... so it's strange that we can have non-existing ID in there.

helen: are you saying that people need to code accurately? if that's the case, we should sack most of the internet.

wilco: <in favour>
... but, to the rule, what does that leave for it?

carlos: at least we can get rid of the combobox part?
... but what we do regarding the scrollbar.

wilco: if you're allowed to leave it empty, it's not required, is it.

carlos: but according to aria, it is required.

giacomo: it's saying that in general you can set it empty or DNE. but for scrollbar you need a valid value.

wilco: I suppose that is a fair reading of it.

shunguo: aria-controls used to be required in aria 1.2. in 1.3 it's not required.

helen: how does it define valid?

shunguo: that ID has to exist. you have a good point. yesterday there was a customer issue. was using 3rd party library that has an ID. they used it in multiple places. so in their page they have duplicate IDs. since we don't have an ID uniqueness rule any more.
... so if we have aria-labelledby etc., should we check if it exists? or if there are multiples?

helen: eg. label vs. duplicates.

shunguo: always point to the first.

helen: wondering if this requires going to the aria github, asking to clarify?

carlos: this was prompted by a PR clarifying author responsibilities on aria 1.3. which giacomo opened.
... so does it make sense to clarify for the scrollbar role?

giacomo: I think main point was to enable authors to inject code, clone items, same template multiple times.
... probably didn't care about scrollbar. definitely makes sense to raise the concern.

carlos: we need clarification.

wilco: I propose we add this to the PR. can you clarify if aria-controls on scrollbar is required?
... do it on PR rather than new issue.
... that will tell us whether we should deprecate the rule or narrow it down to just scrollbar.
... and if this is narrowed down to just scrollbar: do we need to remove the secondary req from this rule?
... if so, I don't think that any of the failed examples fail wcag any more.

shunguo: I'm checking which element could use a scrollbar. just image?
... seems to be rarely used.

wilco: not following.
... scrollbar is it's own role.

shunguo: which element can use scrollbar?

wilco: any scrollbar region.

shunguo: like a div.

wilco: I'm not sure I've ever seen an aria scrollbar.
... people don't build their own scrollbars, do they?

<giacomo-petri> Added our feedback here: https://github.com/w3c/aria/pull/2235

helen: they might add it in. who knows. I've seen scrollbars within scrollbars.
... but it does happen when people don't know what they're doing.

carlos: we have a decision for this one: giacomo will you follow up on the pr?

giacomo: yes, I added our comment.

carlos: I think the idea of what you're doing in taskforce, is something we should also do here in CG.
... so I'd like to use remainder of time to get through open PRs.
... which are in need of review.
... let's start at the top of the list w/ 'reviewers wanted' label.
... at the top: one from giacomo. focusable element has no keyboard trap.

<giacomo-petri> https://github.com/act-rules/act-rules.github.io/pull/2340

giacomo: it's simple. the rule says , background notes say only needs nav in one direction. not both.
... allows users to nav backwards through content. not forward.
... I know that it's not a best practice. so I removed failed ex 2.

wilco: I think it should be a passed example. our passed examples don't need to be best practices. that's sortof the point. they're supposed to be edge cases.

giacomo: I would argue that someone might think that it's enough.

wilco: it is enough.
... we can add a note saying "this is bad, but it is a pass".

carlos: we have that already in the background note for the rules.
... I agree with adding that note "this is not a best practice".
... are you really against that, giacomo?

giacomo: no. if we add that note, I'm fine.

<CarlosD> https://github.com/act-rules/act-rules.github.io/pull/2332

wilco: it just needs some reviews.
... in other rules we first do the spec title, then the section. here we didn't do that.

carlos: so it's just changing the title of the acc req.

<CarlosD> https://github.com/act-rules/act-rules.github.io/pull/2322

shunguo: this one is related to things like aria-controls. we want to make change for aria 1.3 for combox.
... removed aria-controls. did a few examples. seems like I did this one last century.

giacomo: the aria-expanded is required, but the aria-controls is not required?
... are we changing it?
... this rule is checking for allow states and properties, not required ones?/

shunguo: yes, see our example description. aria-controls is required -> changed to aria-expanded.

carlos: giacomo is saying that instead of changing -controls to -expanded, could change description from "required" to "permitted".

giacomo: it works as-is. not opposed. but maybe having "aria-controls is permitted" is more consistent with the rule.

carlos: I think the idea of having some with the required role makes sense b/c the expectation mentions inherited supported or required states and properties.
... it would be nice to have a mix of supported and required. if we stick with aria-controls, we would have only one passed example with the required state.
... so the change makes it more balanced, on the different ways it can pass.
... this note that you added shunguo: what does everyone think about it? should we replicate this across aria rules?

shunguo: this rule is specifically for combobox. I think we have another rule for general aria states and properties. not specific regarding the role.

carlos: but the note that you've added is quite generic. basically it says that aria required states and properties may change...
... that's not a note that is specific to this rule.
... so should we replicate this across all aria rules?
... I think it would make sense to have it as a note on an example.
... I'm not following why it needs to be background for this rule. b/c this rule is not specific about aria-controls or combobox.

giacomo: now we have a process where the aria group requires our review when their changes might change the act rules. so I think it's our responsibility to keep our examples up to date.

wilco: agree.

carlos: so we should take this note out of the rule?

giacomo: yes.

carlos: does everyone else agree with that?

helen: take silence as a yes.

carlos: shunguo, could you remove the note?

shunguo: I remember this note was added because of a review.

carlos: do we want to add notes to every aria rule, saying which version of aria it applies to?

wilco: I think it's useful in certain rules. we've done it in a couple of places.

carlos: let's keep this and see what the aria working group thinks of it.
... you now have 3 approvals, shunguo.

wilco: can we talk about kathy's PR 2301

<CarlosD> https://github.com/act-rules/act-rules.github.io/pull/2301

wilco: I'm wondering if this is worth doing. b/c: why are we splitting this rule up? what's the benefit?

kathy: we had a rule already for captions that included a test of accuracy of captions. the new rule separates the check for the presence of presence and accuracy.
... b/c accuracy of captions would be a manual test. presence of captions is automatic.

wilco: is it though? now that we've added the requirement that you need to know if captions are necessary?
... i.e. tools can't detect if captions are necessary. the tech doesn't exist.

kathy: ok. it was also trying to follow on the image accName rules.

wilco: just not sure it adds much. not against it. not sure we gain anything from it.
... do other people think that it's a useful thing to do?
... an automated tool can detect if captions are there. can't detect if they're needed.

carlos: so wilco you're arguing that instead of the two rules, we just need the one?

wilco: just not sure it's worth it.

carlos: are you questioning whether it's worth having a rule that captions are accurate?

wilco: I'm questioning the having it separate from the rule that checks if captions exist.

carlos: compare to what kathy said previously - image alt text, two rules.

wilco: that's a different scenario. if it doesn't have an alt attribute, that's a problem. if a video doesn't have a caption: we don't know if that's a problem.

carlos: that is true.

kathy: but I think if there is no caption, that would be the check for the first rule f51b46.
... that applicability is: this rule applies where the video contains audio that is not silence.

wilco: is that even right?
... how is 1.2.1 a secondary req for this rule?
... (rule f51*). that's not right. this rule applies to video with audio.

kathy: it's b/c it may be a media alternative to text.

wilco: how does that relate to the video-only criterion?
... I'm sorry, that's a different problem. that's not what the PR is about.

kathy: in the applicability of f51, applies to every non-streaming video w/ audio (not silence).

wilco: so video-only SC should not be a secondary req for this rule.
... we're overtime. need to go.

This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: CarlosD, Dan_Tripp, todd, giacomo-petri, Kathy, sashanichols, Helen, Wilco, shunguo
Present: CarlosD, Dan_Tripp, todd, giacomo-petri, Kathy, sashanichols, Helen, Wilco, shunguo
No ScribeNick specified.  Guessing ScribeNick: Dan_Tripp
Inferring Scribes: Dan_Tripp

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)