<scribe> scribe: trevor

ACT Standup

wilco: closed out several PRs that were small but significant problems. going to AGWG, will put them into CFC. Spent rest of time reviewing PRs
... have not started on the implementation issue on rules with AAA standards not getting counted properly

kathy: Worked on the agenda item on background update. worked on presentation for ACT rules for conference.

trevor: ACT presentation, implementation review, reviewed some PRs

tom: Opened up a PR and just re-opened the CSS orientation rule. Have some question on the table rule referencing th vs td
... need to do more testing to see how they handle things. PR numbers 2131 and 2109

<thbrunet> For clarity, need more reviewers for 2131 and 2109.

helen: working on PRs, discussed 2064 and may need additional TF review. Need agreed definition of what autoplay is

wilco: Will put that as a future agenda item

shane: No big updates

Catherine: No big updates as well.

Nov 2 meeting cancelled

wilco: no meeting next week due to a bunch of people being out
... do have a few open surveys for us to start reviewing

<Wilco> https://www.w3.org/WAI/GL/task-forces/conformance-testing/wiki/ACT_Task_Force_Meeting_Agenda

wilco: due two weeks from today, november 9th.

CFCs from last week

wilco: Had a CFC for last week to approve 3 rules for review. Have only positive responses so going to send those to AG and ARIA

RESOLUTION: Approve CFCed rules for review by the working groups

wilco: Have more rules for CFC so expect to see that somewhat near in the future

Defining implementations

<Wilco> https://github.com/w3c/wcag-act/pull/541/files

wilco: High-level of this was to define consistent and partially consistent to implementations within the rule

trevor: Would maybe like to see a reference to the Earl document and the different check outcomes before we make the list ordering them.

wilco: Discuss some of them earlier in the document, but untested and cantTell may not be referenced
... Could we add a little bit of text of the outcomes next to our link to outcomes

trevor: I think that would be fine, they are pretty self explanatory

wilco: We could also just expand the definition

trevor: Yeah would be fine with that, just want the options to be enumerated

wilco: cantTell isn't in the outcome definition.

tom: definition also has an "incomplete" outcome

wilco: I think thats wrong, I don't think EARL has an incomplete. Error in the note, need to change that.
... on line 671 need to put cantTell
... we can add cantTell and include untested with a bit of explanation.
... What do you mean about not understanding the possible outcomes?

trevor: Before passed, inapplicable, and failed were the only options but bullet point references other outcomes, what are they

wilco: Need more work on this, need to get this merged to get a first public working draft. Please take a look at this for the next couple weeks

Secondary requirements explanations

<kathy> https://github.com/w3c/wcag-act/pull/542/files

wilco: Was everyone able to follow the screen share or did that make things harder?

kathy: This is the PR i mentioned last week about adding the explanation part of the secondary requirements
... wilco had a PR to put the explanation under the secondary requirement instead of it going in the background
... one other thing, used to have 4 different scenarios, but now we are down to 3 due to the rule is stricter scenario
... those a really the main changes from the original update
... previously was in the background section, now under the secondary requirement and uses more standard language

wilco: pretty happy with merging this in

trevor: took a look, but didn't add any comments and just approved it because it looked good

wilco: I do have one topic regarding secondary requirements to discuss
... saw secondary requirements starting to get used in CG that might be worth a conversation

<Wilco> https://github.com/act-rules/act-rules.github.io/pull/2007/files#diff-579ce0c887300ad57b274db4b0c63bfbcdbb8e74c9aaebdf54ad0b326fbb8cd3

wilco: let me intro this, there was a PR. He added 1.1.1 and 1.3.1 as secondary requirements, because if you have a link with an image inside of it and the image is used to give contextual information. If the image has a missing accessible name then the link purpose is not clear.

<Wilco> https://github.com/act-rules/act-rules.github.io/pull/2007/files#diff-579ce0c887300ad57b274db4b0c63bfbcdbb8e74c9aaebdf54ad0b326fbb8cd3

wilco: In failed example 1, have two different links where both have contact us links, but don't have distinct purpose
... don't think this is a 1.1.1 problem because you can decouple these issues. You can have one problem without the other.
... but we haven't very clearly defined that inside of the rules format. We are vague and allowing almost anything to be a secondary requirement

helen: Kathy explained it last week, it seems like this would be a secondary requirement because it only fails some of the test cases.

kathy: I think its very similar to the last scenario where we have the area example within a rule for links, so we do have 1.1.1 as a secondary requirement there
... are you saying because this is using an actual image thats why the could be separated. Because an area is both a link and an image it would make sense why things can be secondary
... in this PR, its an actual image in a link it changes the justification

wilco: yes, because you cannot have an area element without failing both. but here you could have a 1.1.1 failure separate from a 2.4.4 failure

kathy: if the image had an empty accessible name, you could still do something with the link to give it an accessible name

wilco: Yes, its kinda hard and convoluted

kathy: because you could still fix the link to have an accessible name you don't necessarily need to include 1.1.1

shane: Problem with how these are tied together, one can cause the other

wilco: concern I have with this, all of our needs a non-empty accessible name become 1.1.1 secondary requirement rule
... doesn't seem why we needed secondary requirements
... needed to allow people to fail certain accessibility criteria

trevor: So do we need to change the example?

shane: its two separate problems within the same test case

wilco: yes, they are separate

helen: Would we be adding in guidance that if you run into this problem, you should try to split them apart into new rules?

wilco: Already have that, that you shouldn't have multiple problems in one rule.

helen: Still might need to reduce ambiguity

<ShaneDittmar_> +1 to a less complex example

<catherine> +1

+1

<kathy> +1

<Wilco> Helen: 0

<Wilco> Helen +1

<thbrunet> +1

wilco: Still inclined to explain this better in the rules format and may also need to be used as a counter-example for when not to use secondary requirements

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)

Succeeded: s/2031/2131/
Default Present: thbrunet, kathy, Helen, Wilco, trevor, catherine, ShaneDittmar_
Present: thbrunet, kathy, Helen, Wilco, trevor, catherine, ShaneDittmar_
Found Scribe: trevor
Inferring ScribeNick: trevor

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.)