scribe+ CarlosD

ACT stand-up

Jean-Yves: no progress

CarlosD: Also no progress

Dan_Tripp: Updates to the label in name PR. Reviews welcome

Wilco: Did some reviews. Updates on the summary rule

giacomo-petri: Reviews and updated PRs

kathy: Need to look at summary rule

Rachael: No updates

ACT office hours

Wilco: To get more progress done and onboard people more efficiently, I'm planning on a one-month 4 hour meeting to do ACT work
... that would allow us to get some thing on the calendar to have dedicated time for ACT work

Jean-Yves: That would help. That aligns to what we were discussing earlier this year

<giacomo-petri> +1

+1

Dan_Tripp: Who do you picture will be online?

Wilco: Just have zoom open and whoever shows up is welcome... we can also open rooms to work in groups

Jean-Yves: If we're all on zoom we can more efficiently reach people when needed... it brings value

Wilco: What would be a useful time for this? On the same day of CG meetings? And we need to find a time that works both Europe and US

Jean-Yves: If we have a longer period we can overlap Europe afternoon and US morning

CarlosD: I would favor it in the weeks when we don't have a CG meeting

Wilco: That would overlap with task force

kathy: But we can have a working TF meeting

Wilco: starting next week and then every four week
... I'll set it up
... from 2pm to 7pm (CET)
... from 2pm to 7pm (CET)

ACT F2F meeting

Wilco: I will set up a survey
... we discussed it on Monday, and we're planning early next year

Color contrast rules [afw4f7, 09o5cg]: clarify behaviour on submit buttons https://github.com/act-rules/act-rules.github.io/issues/2204

Jean-Yves: Someone reported that we don't flag submit buttons for color contrast
... that is technically correct since the rule targets text nodes and in the submit button there is no text node
... historically, the rule ignored widgets because on their different states, then we added widgets in default state but ignored submit buttons

<giacomo-petri> +1 to another rule

Jean-Yves: including it would make the rule more complex... another possibility would be have a rule specific to submit buttons
... still we will need to add an example to this rule

giacomo-petri: I think it is good to have a rule for checking this instace, and to prevent increasing the complexity I would favor a new rule

Wilco: I'm not sure how the new rule would be less complex

Jean-Yves: The expection would be as complex as the current, but we would not increase the complexity of the applicability

Wilco: There are more edge cases that we didn't cover in this rule
... We can create lots of duplicates if we split this rule

tom: A button and submit button are basically the same

Wilco: Arguably this covers input button, because the text node is still in a closed shadow dom in the browser

Jean-Yves: But because it is closed we cannot access it

Wilco: Do our rules apply to close shadow dom?
... Do all browser do that?

giacomo-petri: Chrome does not
... If we include that what do we do with options?

tom: Options have text nodes
... it's been working for buttons, it should work for submit buttons

Wilco: I'm leaning towards what Giacomo is proposing, a new rule applicable to the value of the input button
... Maybe what we need a definition of text, that can be a text node or the value of an input element

Tom: you could just protect other potential uses of that definition you could say text node or input equivalent text node and then put a definition for that

giacomo-petri: what about non-standard inputs like input type file and date?

Wilco: Those are browser or OS widgets

giacomo-petri: But the label color is set by the author

Wilco: That is similar to what happens with the select and options

Jean-Yves: It's a step forward if we look into the value of input elements

Wilco: I would attempt to work on the definition first

Jean-Yves: If we can get a definition that would prevent us from writing a large number of rules

<giacomo-petri> axk giacomo-petri

giacomo-petri: the issue here is that the rule is duplicating other rules
... I created three rules to fully cover presentational roles conflict resoluation
... but Wilco identified that we have that covered already in other rules

Wilco: You split one of our rules in two rules, and if we go that way we will need to go through all the process of AG approval
... are there things in this rule that you think are not covered in the other rules?

giacomo-petri: there are many passing and failing examples, but I will need to review those rules to be sure

Jean-Yves: I've been wondering if we should have a rule to check if presentation role conflict is not triggered

Wilco: What woudl that look like?

Jean-Yves: It could apply to anything with a role where the conflict was not triggered

Wilco: That is essentially the element maked as decorative is not exposed

Jean-Yves: And several of other rules we already have that check the presentation conflict

Wilco: I'm not sure what that adds to what we already have

giacomo-petri: I need more time to compare my PR with the existing rules to find what the new rules can add to the existing ones

Wilco: if someone familiar to ACT-rules like you can overlook this, then the rules are not conveying their purposed correctly
... I'm not sure what we can do to improve on this
... I've had this issue explaining this rule to the AG also

giacomo-petri: I'll look into the rules and think about how can we improve it

Jean-Yves: We may come up with a compositive rule for presentational role conflict that combines all the rules that are looking into that

Wilco: I don't think that is what composite rules were intended for

Summary rule PR2202

<Jean-Yves> https://github.com/act-rules/act-rules.github.io/pull/2202

Wilco: Jean-Yves pointed that one example is an author error according to ARIA in HTML
... but I think we need this because it is part of the applicability and is not a WCAG violation

Jean-Yves: But we should at least include a note stating this is an author error and should not be done
... not report it as a WCAG failure but as an ARIA failure

Wilco: I will add a note stating is invalid markup

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/woudl/would/
Succeeded: s/familiat/familiar/
Default Present: CarlosD, kathy, Dan_Tripp, Jean-Yves, giacomo-petri, Wilco, thbrunet, Rachael
Present: CarlosD, kathy, Dan_Tripp, Jean-Yves, giacomo-petri, Wilco, thbrunet, Rachael
No ScribeNick specified.  Guessing ScribeNick: CarlosD
Inferring Scribes: CarlosD

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