-
Notifications
You must be signed in to change notification settings - Fork 70
Minutes 2021 09 09
Present: Carlos, Wilco, John, Jean-Yves, Aron, Daniel, Shadi
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
agendum 2 -- Assigned issues: https://github.com/act-rules/act-rules.github.io/issues?page=1&q=is%3Aissue+is%3Aopen -- taken up [from Wilco_]
<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
<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