<Wilco> scribe: Wilco

ACT stand-up

Wilco: Got a rule in call for review

Dan: Label in name AT test, about half way done

Mark: Looked at label in name changes. Looks like a good compromise. Will put a comment on it in GH

Tom: Working on keyboard trap rule, got the technical stuff resolved. Major piece is to update the rules format

Wilco: Don't remember what we need to do there for the rules format update

Tom: I'll leave that for a separate PR then

Helen: Need to go through the feedback

Sage: Been trying to suss out what to do. Hoping to learn as I go

Jean-Yves: A good place to start might be to look at Wilco's call for review

Sage: I'm familiar with GitHub

F2F Survey -- please reply before the end of the month

https://www.w3.org/2002/09/wbs/114156/f2f-2025/

Jean-Yves: We've sent a survey to the list about organizing a F2F meeting Q1 next year
... Please have a look, fill it in before the end of the month

Wilco: Survey fills out before the end of the month

Tweak definition of focusable

https://github.com/act-rules/act-rules.github.io/issues/2210

Tom: We have a few definitions to handle keyboard bumpers. You can have a case where something loses focus and then regains it. But strictly by definition it wouldn't be.
... This is not something you run into a lot. I have seen cases where a component forces focus to the wrong place, but then you need to move focus back. It can happen when dealing with 3rd party

Wilco: We should consider if this needs test cases. I'm leaning no personally.

Jean-Yves: It would need to go into a rule
... What about if the focus moves between elements repeatedly?

Wilco: If we don't have a real example of that I don't think we need to worry about it

[Target size]: UA controlled rule

https://github.com/act-rules/act-rules.github.io/pull/2182

Jean-Yves: This is part of what I did for the target size rule. That became a huge PR
... To make it more manageable I broke it up by rule.
... Got a lot of feedback last week.

<Jean-Yves> scribe: Jean-Yves

Wilco: the rule of UA exception feel more like Inapplicable cases than Passed ones.
... we do not want that to be part of every other rule's applicability
...  having a separate rule can only make it Passed/Failed, so not good.
... the idea is to allow the composite rule to filter applicability of its atomic rules, but it requires an update from the rule format.

<Wilco> scribe+

<Wilco> Tom: What would be the spec change?

<Wilco> Jean-Yves: Currently when you have a composite rule, the applicability has to be a union of the atomic rules.

<Wilco> ... If we did that here it would mean each atomic rule would need to hav "except if it's a UA controL"

<Wilco> ... So we'll want to allow that exception only in the composite rule

<Wilco> ... That will make the rules easier to write, and less cluttered with repeated stuff

<Wilco> Tom: If that's the case, do the atomic rules not report to WCAG?

<Wilco> Jean-Yves: The atomic rules already don't report directly to WCAG

<Wilco> ... We have an internal guideline that the test cases respect the SC they are meant for.

<Wilco> ... You can find those in the "Beyond WCAG" rules list. They are mostly atomic rules used in composite rules

<Wilco> Tom: I think the big challenge is how to report results out for tools.

<Wilco> ... I don't know how our tool would report if we meet the atomic rule. We only report on the composite level

<Wilco> Jean-Yves: For example, target size we have a 24 by 24 rule. It has nothing on user agent control in its test case. For that rule the pass test cases pass the SC, and the failed ones fail the SC.

<Wilco> ... Those can still be reported correctly

<Wilco> ... It will be on us to make sure the test cases are built that way

<Wilco> Tom: The risk you run there is there is an implicit exception.

<Wilco> Jean-Yves: We'll probably want a background note saying way there is no UA exception in the rule.

<Wilco> ... There is also an implementation question. I know this will require a change for our tool

<Wilco> Wilco: We didn't allow logic in the composite rule to avoid problems with implementations.

<Wilco> ... I don't expect this to create problems for most implementations.

<Wilco> Mark: I don't expect problems from our tool

<Wilco> Carlos: Me neither

Office hours meeting

<Wilco> Jean-Yves: I think this was good, it helped move things forward.

<Wilco> Carlos: Agreed, something to repeat.

<Wilco> Helen: It was good that this was flexible, lets me come in and out when I could

<Wilco> Wilco: I will not be available to run it on September 26th

<Wilco> Carlos: I'll be able to run that one

Final thoughts

<Wilco> Wilco: Welcome Sage. Thanks for joining office hours everyone!

<Wilco> Sage: Learning a lot! You're all a delight

<Wilco> Mark: If people are interested, we can probably host

<Wilco> Dan: Learned about keyboard bumpers today

<Wilco> Tom: Office hours was productive. Got to block off some work

<Wilco> ... Heads up. Taking some vacation in September

<Wilco> Carlos: Great to see a new participant.

<Wilco> ... Lets go to Ddenborough!

<Wilco> Jean-Yves: Can't wait for vacation! Thanks all!

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: Jean-Yves, thbrunet, CarlosD
Present: Jean-Yves, thbrunet, CarlosD
Found Scribe: Wilco
Inferring ScribeNick: Wilco
Found Scribe: Jean-Yves
Inferring ScribeNick: Jean-Yves
Scribes: Wilco, Jean-Yves
ScribeNicks: Wilco, Jean-Yves

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