W3C

Accessibility Conformance Testing Teleconference

08 September 2022

Attendees

Present
ChrisLoiselle, Daniel, Helen, kathy, thbrunet, ToddL, trevor, Wilco
Regrets
-
Chair
Wilco
Scribe
thbrunet

Meeting minutes

<Helen> @Chris you can find the code in: https://www.w3.org/2017/08/telecon-info_act

Sept 15th meeting cancelled

<dmontalvo> 3zakim, start meeting

Wilco: next week cancelled due to TPAC

Wilco: Two new rules for survey the week after.

ACT rules sheet

Wilco: Object element - merged this week. I think ready for CFC. I don't think needs another survey. Agree?
… okay, ready for CFC.
… Five rules to bring to AG. Would like to bring Object element also. Unless objections, going to add for AG. Hearing no objections.

dmontalvo: Condition related to text node not being empty.

Wilco: I thought that was fine, might need a conversation

trevor: Text content - popped out PR for essential text change definition. Not sure if other situations. I'm guessing some more obscure.

ToddL: Heading is descriptive - have not had a chance to look.

thbrunet: I'll talk to Wilco some more about contrast offline

Open ACT pull requests

Wilco: 1920 - secondary requirements.
… added a secondary true flag to accessibility requirements where I think we should treat requirement as optional. Updated tool for mapping.
… We're still working on the text, but wanted to see if objections for this bit.
… This is related to AAA only, ARIA seems more controversial

Helen: I looked at it, and looked fine to me.

kathy: Would this immediately update implementation?

Wilco: Pretty much, yes. Some things that are partially consistent would become consistent.

Wilco: So if everything's correct, but you're not reporting a AAA it would become consistent
… Everything else stays the same, but solve a problem for implementers. How it's shown is future, but fixes the inconsistency.

Wilco: I started a new rule (1919). Still in draft.
… 1917, scrollable elements. Need more reviewers.
… 1916, essential text definition. Adding Daniel, Helen.
… 1873, Image no text, is this ready? Looks like. Should I merge?

ChrisLoiselle: I think so, yes.

Wilco: I think everything else has been addressed.

Priority issues

Wilco: 1875, link is name being working on. 1853, 1849, 1367 high on my todo but haven't progressed.

Annual review of approved rules

Wilco: We have agreement to review published rules at least once a year
… We have a few that were reviewed more than a year ago. Proposing we assign two checkers to each rule. Have a couple of weeks for everyone to review with survey. If both agree with as-is, move on. Otherwise, we can review.
… Anyone not available to do this in the next 2-3 weeks.

kathy: I probably can't in the next 2 weeks, but 3 weeks probably can.

Wilco: I think we can do that.

thbrunet: Do we need to stagger by due date?

Wilco: I don't think necessary.

Wilco: I'll assign names and send out an email with instructions.
… You'll fill out a survey and verdict columns will be filled out.
… 17 rules, 34 reviews, 9 on this call. 3-4 each.

thbrunet: And two new rules to survey, right?

Wilco: Yes

Secondary accessibility requirements

kathy: Sent email about this yesterday. This is PR 531 for secondary accessibility requirements.
… We talked about this section that explains the secondary accessibility requirements.

Wilco: At a high level, this is changing rather a lot. Going to be difficult to see if the changes are additions to the rule format. Safer way may be if we can constrain what we do and to most by adding sections. I drafted up a proposal. I think it covers most of what we might need.

<Wilco> https://github.com/w3c/wcag-act/pull/531/files#r965857800

Helen: I agree with what you're saying there. Basically requirement might be stricter than the rule.

kathy: I like how you've worded it. I wonder... we've been concerned when we describe specific scenarios, if we don't cover all of them, we have to come back to update the rules format. I want to spend some time thinking over whether that covers everything.

trevor: Can you explain the second more? Feels like different than what we originally went over.
… My understanding was originally second scenario was that the tests in the rule could be passed using a different mechanism than what is tested in the rule. For instance keyboard trap. Here, way I'm understanding it, the applicability of the SC is different than the rule. The requirement only applies to specific test cases.

Wilco: Kind of the same thing, but maybe a second example would be useful.
… Keyboard trap, whether or not SC is satisfied depends on that scenario, there are other ways to meet that requirement.

trevor: If the rule fails, you can't say that the requirement is not satisfied because there's a scenario where it's satisfied.
… I'm getting a little tripped on how how it applies to certain test cases and saying which test cases it applies.

Wilco: I still think it's kind of the same thing. The way we know a test case fails is by applying the non-standard rule or applying the standard rule. There's something outside of the current rule saying whether or not this SC fails.
… Maybe it's the example.

trevor: Getting stuck on the first sentence.

kathy: I like this example better than the keyboard trap example for what I think this description is covering. When Trusted Tester maps to the keyboard trap standard even when only doing this rule, that's part of the instructions that Trusted Tester has for testing this SC, but it's not the only one. So, I wonder if when we have implementations that include this non-standard rule in the greater test for the SC, we shouldn't be failed

ling it immediately based on that rule anyway, so should the rule even map to it?

Wilco: So the question is whether it should even map to 2.1.2?

kathy: I can see 2.1.2 in the background, but should it be mapped to the SC at all?

Wilco: Yes, the reason we need it to because of how the implementation mapping works, we need a finite list that an implementer can report as not satisfied. If you report as a failure to keyboard trap, that's a correct response.

kathy: I think in the composite rule it's okay. But if you're looking at the individual rule, I wonder if we should not list the SC there.

Wilco: If we don't do that, the consequence is that implementers of the composite rule cannot implement the atomic rules.

kathy: I think that's the phrasing that's complicated. You fail 2.1.2, but you're not failing it yet.
… I think someone outside of this group would have trouble understanding.

Wilco: Let me try a different approach. If we have our failed example of a keyboard trap and we use that in a composite rule and we use it in non-standard, that example fails 2.1.2. But if we use that example in the composite rule and we say it has to report 2.1.2 and we use that same example in the atomic rule, we're saying you can't report 2.1.2.
… Presents a contradiction.
… We're requiring you to fail in the composite, but requiring to not fail in the atomic.
… One way to solve that is that the atomic has to list 2.1.2 as a secondary/partial requirement. Another way is that we don't require that you report the correct SC.

Helen: What I understand for part 2. One calls out a SC for what fails. Technically also fails, but not being called out in this rule.

thbrunet: I think circling back to Trevor, one scenario is that some examples pass an additional SC. Another scenario is that is may or may not fail based on a larger condition

Wilco: Looking at another angle, all SC's that might fail from that rule may need to be listed.

Helen: If you had 20, that would get annoying.
… For example, image button.
… The one bit in that rule might fix the other issues.

kathy: For contrast enhanced. Would have had to list minimum because it also fails. Would this apply, or would people need to list both.

kathy: Opposite of number 1.

Wilco: I don't think we'd want that listed?

thbrunet: I'd be concerned that they'd skip.

Wilco: I don't think you'd have the AA rule including the AAA success criterion

kathy: We have requirement that any requirement that fails has to be listed.

Wilco: Because we're running out of time, maybe take this one step back. Maybe we should focus discussion and edit one section first and then edit other after.

kathy: How can we make this cleaner?

Helen: Can we branch on branch?

kathy: Can I close this PR and open a new one?

Wilco: It will be kept even if closed, so we'll have that information.
… feels like current PR is boiling the ocean a little bit
… Is that a good next step?

kathy: Yes - I'll try to make it more readable

Wilco: Still have page state on the agenda, but not a two minute topic.

trevor: I can send something out.

Wilco: I think we need to continue on secondary requirements.
… Something to consider for new focus appearance. Maybe some new state things to explore there.

Minutes manually created (not a transcript), formatted by scribe.perl version 192 (Tue Jun 28 16:55:30 2022 UTC).