Minutes 2021 09 09 - act-rules/act-rules.github.io GitHub Wiki

Present: Carlos, Wilco, John, Jean-Yves, Aron, Daniel, Shadi

agendum 1 -- Update from the ACT Task Force -- taken up [from Wilco_]

Wilco: TF is back to surveying rules. They have approve 2 rules, there are a couple more

... Good thing to happen

... Anything else?

... I am hoping to get the redeisgn work approved next week so that we can publish our new design

... This includes the new implementation tables that have been in the CG website

... There is a bunch more automation that needs to happen before we can publish straight away to the WAI website, hoping to have it done by the end of the year

... Objective is to not have to maintain two websites

... Writing rules in the CG and publishing in the WAI website

<Wilco_> https://github.com/act-rules/act-rules.github.io/issues/assigned/WilcoFiers

Wilco: 11 open issues assigned to me, I am not sure htere has been progress, I have been on vacation

Aron: I am happy to take the first issue you have assigned, maybe proposal on aria-required context rule may solve it

Wilco: I will focus more on these when the merge happens

<Wilco_> https://github.com/act-rules/act-rules.github.io/issues/assigned/ajanec01

Aron: Waiting for follow-up from Susan

<Wilco_> https://github.com/act-rules/act-rules.github.io/issues/assigned/carlosapaduarte

Carlos: 1502 and 1446 I got to them, also 1446. They have prs that are waiting for review, 1665 and 1661

... Jean-Yves already reviewed them trying to resolve those comments

... 1445 I reverted all the changes based on feedback from you Wico, and also JEan-Yves agreed

... You suggested moving these notes to the ACT-Rules input aspects document. So I created another PR to upate the document

<Wilco_> https://github.com/w3c/wcag-act/pull/520

Wilco: I will bring that to the group

... Thanks Shadi for getting the contribution passed on to AGWG, now I am a AGWG member

Jean-Yves: Same we created an exception for language, we can create an exception for CSS style

Jean-Yves: I could take it over

<Wilco_> https://github.com/act-rules/act-rules.github.io/issues/assigned/Jym77

Jean-Yves: Not much to update

Topic: Call for Review

<Wilco_> https://github.com/act-rules/act-rules.github.io/pull/1694

Wilco: One thing to look at, I added a funding section to the acknowledgements where we are able to put the project that funded the rule. Right now it is only WAI-Tools

<Wilco_> https://github.com/act-rules/act-rules.github.io/pull/1675

agendum 3 -- "Image button" (59796f) does not consider default names https://github.com/act-rules/act-rules.github.io/issues/1457 -- taken up [from Wilco_]

Jean-Yves: in HTML image buttons have a default accessible name. We may want to rewrite the rule so that the name is different than the default name. In button have accessible name we have passed examples that are good because of their default name.

... I am uncomfortable saying in one rule that defaultname is good and in another that default name is bad

... It seems to me there were a decision to accept the default name, happy to come back to it at any tie anyway

Wilco: I approved because I think submit is not a good name, whereas reset or submit might be good names

Jean-Yves: Then we may need to make it explicit

Carlos: Agree.

agendum 4 -- Add menuitem and button to form-control-acc-name? [e086e5] https://github.com/act-rules/act-rules.github.io/issues/1374 -- taken up [from Wilco_]

Wilco: We have a form control accessible name, and a menu item, and a button, and a link accessible name rule

... Distinction is n ot clear, is that a problem?

... They are separated because they map to different SCs

Jean-Yves: I am not happy with this separation, leaning to have a general rule and keeping the individual rules around [16:28] <Wilco_> https://www.w3.org/TR/wai-aria-1.2/#widget_roles

Wilco: I don't know if it is actually true. Looking at the widgets, at least in ARIA, gridcells does not require an accessible name

... We have excluded options because it sometimes is not a use interface component

... Does WCAG say that tabpanel requires and accessible name?

... this is a bit messy

Carlos: For all these rules the expectation is the same.

... It would be strange to have the same expectation twice for the same element

Wilco: One way we could do it is to have all widgets except from some list s of exceptions

... I am still not sure how we will handle links and image buttons, which apply to more than one SC

Aron: It would be good to have some reason put into these rules. I am thinking of an element with the role of option as a widget

Wilco: I think that the rules format will not allow to include links and image buttons in that rule, but we could handle that by excluding them

... First, Do we want to merge these rules together?

0

Aron: Would we have to come up with our own list of widgets that require an accessible name?

Wilco: The oppsote probably

Aron: We should justify one way or the other

+1

+1

<john_h> 0

<Wilco_> https://www.w3.org/TR/act-rules-format/#accessibility-requirements-mapping

Wilco: This is leaning towards a yes, what would we do with scenarios where elements fail more than one SC?

... Rules format section 4.4

... That feels to me lik it would not allow image buttons on such a rule

Jean-Yves: I would not have a problem with a global rule for links and image buttons and then individual. If it can simplify the ruleset it is worth the effort.

... When we fail 4.1.2 the rule would need to fail, there might be other SCs that the rule fails but we are not necessarily listing all the SCs that a specific use case fails

... A button without an accessible name is failing 4.1.2, but maybe it also fails kyboard navigation, but we do not necessarily list that on a rule testing accessible names

... I read that section that we may need to list the requirements we are sure the rules are failing

Wilco: We put this in because we want to avoid the scenarios where some orgs failed buttons only under 4.1.2 and not in other SCs

Jean-Yves: That is way a general rule on images buttons will be useful

Aron: This particualr example is scoped to image button, which will be part of the rule we would design, as it is a user interface component

Carlos: I think it will be strange having two rules testing the same thing, I would prefer the generic rule to happen at a tool level instead of at a rule level

Wilco: For image buttons it would not be, but for links you would have a generic widgets havean accessible name for 4.1.2 and then the other on 3.1.1

Aron: Part of it would be related, but there would be something extra for each rule

Carlos: Now the expectations are always the same

Wilco: I am not too bother. I have a slight preference for granularity tough

... Not opposed if someone want to take this up

... Any objections?

Wilco: We can leave this open with a comment on the direction we are taking

Carlos: The comment on this issue seem to point to the other direction. The feeling that I get from it is we want to even split these further

... I don't have any objections, just pointing this out, agree with your proposal

Wilco updates issue with proposal

agendum 5 -- Zoomed text node: Is the third assumption actually reasonable? https://github.com/act-rules/act-rules.github.io/issues/1318 -- taken up [from Wilco_]

Wilco: Is the third assumption actually reasonable?

<Wilco_> https://act-rules.github.io/rules/59br37

Wilco: Kasper mentions mobile in his comment

... I don't know if this is a question that belongs to this group.

... Only as to whether we are consistent with what we have done in respect to WCAG

John: Here we test on a case-by-case basis

Wilco: At some point you need to stop, for example it is not reasonable ot expect 200% on a watch

... I feel when 1.4.4 was written, they looked from a reasonable resolution and started from there

Carlos: I don't we can do much better than this. Can we add something to the assumption that this resolution might not be a good fit for non-desktop devices?

Jean-Yves: We cold raise the issue to WCAG and ask them what they mean

... Maybe we are failing WCAG but passing the rule, so I am leaning toward Carlos proposal that it may be correct for desktop but not necessary so for mobile

... So that when the rule is passed we still ask for further testing

Wilco: Seems like a good solution

... I do think this is one that needs to go to AG

... Who could open an issue for this? I propose referencing this one and closing it

Daniel: I can take this up, may need to follow-up with you on the phrasing of this

⚠️ **GitHub.com Fallback** ⚠️