wilco: Next friday we have a joint meeting with the silver TF and AG, 3 hour meeting starting at 4pm Eur or 10 EST
... Going to review one outcome of WCAG 3, looking at errors and methods. Going to setup a survey that will go with the agenda. Pls fill out the survey
... survey is 4 questions looking at different aspects of the outcome we are going to do a deep dive on
... Given that we have a 3 hour meeting on friday should we still have thursday meeting?
daniel: going to be off on thursday anyways
trevor: can be available, could also pile up some reviews for the week after
aron: Will have to do some work with the schedule
wilco: Going to leave it up for now, if we get too many regret we will cancel
wilco: went through a bunch of these, 2 weeks of checks to go through
... device motion based changes, checked by both aron and susan. no problems can accept it.
aron: looked at the motion-based changes to content that was rejected previously, this rule didn't have the same problem
wilco: document has landmark with non-repeated content
trevor: problem with applicability/an assumption for better defining the repeated content that is used in the test cases
daniel: fine letting it through
wilco: document has an instrument to move focus to non-repeated content - both kathy and I had problems with this
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/1588
kathy: the applicability seemed too broad, but unsure if there is a way to make it more narrow so that it only applies to pages w/ repeated content
... it looks like there are techniques that specify the location of the skip link. This only checks a skip link exists. I don't think the rule covers those techniques.
wilco: need to take another look at it.
... It doesn't need to fully test the technique, since they are partial failure tests. Bothers me, but not enough to prevent accepting
kathy: fine with that, would really prefer the applicability to be narrowed
aron: the applicability needs to be objective, using block of repeated content adds subjectivity into it.
wilco: this is similar to the comment on the previous rule. Def for non-repeated content after content says it is unambiguous
... Is that enough to prevent the rule from being accepted as a proposal
kathy: I am okay with it
wilco: marking as accepted
... going to document has heading for non-repeated content
aron: We had previously blocked bypass blocks with headings, so felt this was similar
wilco: element in sequential focus order has visible focus rule - susan says hard to understand
... it is very technical, but by no means the worst. I don't think its particularly problematic
aron: expectation relies on color changing, we have had some problems with defining what color is, hue is color, but like black and white are not
wilco: I think thats a valid point
... We need to define color more definitely
aron: there is a technique with a long note about it. they give the example of pink and red being the same color just different lightness.
wilco: AG had a conversation about this awhile back that the use of color SC is the use of Hue and is not about brightness
... given the discussion, inclined to believe it should be rejected
... element marked as decorative is not exposed - checked by trevor and kathy
... form field label is descriptive - daniel said rule is hard to understand
<Wilco> https://act-rules.github.io/rules/cc0f0a#assumptions
daniel: put issue up, an assumption says the labels are intended for sighted users which seems incorrect
wilco: its stated awkwardly, i think its saying something doesn't stop being a label if its not available to assistive tech
... I don't think its phrased in an inclusive way
daniel: would prefer it not pass for now
wilco: I think the fix is really straightforward, I think we open a PR and accept it assuming the PR is accepted
daniel: I will open a separate PR for this
wilco: going to mark as accepted
... focusable element has no keyboard trap - test descriptions need updated
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/1586
<Wilco> https://act-rules.github.io/rules/ebe86a#applicability
wilco: focusable element has no keyboard trap via non-standard - trevor has an issue
trevor: had a bunch of small comments on the expectations and test cases
wilco: have a problem with how we would know when to stop using the navigation, how do we know the order or limit
aron: the problem is the definition of cycle
trevor: potentially stop when you hit the same element again in a cycle
wilco: may have to push some random sequence of buttons
aron: agree is ambiguous, but isn't it a quick fix to change to using can't move to browser UI instead
wilco: Doesn't really fix anything
aron: then agree that we could block it
wilco: I was actually going to say we accept both this and the device motion one
trevor: agree, I think these problems are largely theoretical
wilco: propose we do the same for the device motion