<Wilco> https://pr-preview.s3.amazonaws.com/w3c/wcag-act/443/44250c7...025924a.html
As there are no objections, we will take this to the AGWG chairs
Wilco: How des an errata work?
Shadi: I will link to that. It is published in our site, once it is merged I can update it for our site.
<Wilco> https://github.com/w3c/wcag-act/issues
Wilco: We need to decide how to handle these open issues. Now we open an issue and add comments to it based on survey results, but it leaves them permanently opened.
... It makes it hard to see what is in progress and what it is not.
... Instead of us appending things to the issues, we could just close the issues when the survey is open and then when the survey is closed we open a new issue if there are new comments.
... IF we missed something from the first issue, it should come up in the survey again.
<Wilco> https://github.com/w3c/wcag-act/issues/428
Wilco: This example uses check boxes to determine what is and is not done, but you need write permissions to edit these. Not everybody has them. If you reply to the issue comment, the original one is not updated.
MAry Jom: As we have owners for each of the rules, perhaps they should check weekly before this meeting if there has been any actions there: mark the checks, edit or clean any comments...
Wilco: But ehn how would we know this is done? They may not get to close the issue
MaryJom: Maybe adding a tag would help.
Wilco: An adding a reply that the issue has been updated.
Trevor: Makes sense.
<Wilco> https://github.com/w3c/wcag-act/blob/master/wcag-ruleset-review-process.md
Wilco: We need to document this in our process (link above)
... What we say here is we would closed by the Task Force facilitators the issue indeed. This does not seem right, I think we should only label the issues indicating it has been updated and needs another revision.
Wilco: We have five responses.
Wilco: Comment by Sailesh on how to deal with requirements out of WCAG.
<Wilco> https://www.w3.org/TR/act-rules-format/#rules-without-accessibility-requirements
MaryJom: Is the rule clear that it is not dealing with a WCAG requirement?
Wilco: The rule says it is not required for conformance.
MaryJom: Maybe we want to separate them from the ones that deal with WCAG requirements. Maybe we may indicate that non-WCAG requirements are advisory.
Shadi: I prefer to spend time here in the TF on something we know is required by WCAG.
... People are looking for the conformance rules much more. These are what will make them join the group and implement the rules.
MaryJom: The community Group should not be involved in these advisory rules in my opinion.
Wilco: There are 3 non-WCAG required rules now.
... I think if we have the bandwidth we could work on them but not prioritize them.
Trevor: Agree.
Daniel: Agree.
<trevor> https://www.w3.org/2002/09/wbs/93339/RuleImageFilename/
Wilco: Three answers. I commented that we probably would want to make assumptions clearer.
... A question from Charu about the filename being descriptive.
... Generally this is a rule that will flag potential issues
Trevor: Are we testing if they are the same or if they are descriptive?
Wilco: It is applicable when they are the same. It checks that the accessible name is correct, but it limits to things with the same filename and accessible name
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/1246
Wilco: If there is an extension in the accessible name, is it always a failure?
<Wilco> https://act-rules.github.io/rules/9eb3f6#passed-example-2
MaryJom: The file name is rarely useful to provide an accessible name.
Trevor: I don't agree that extensions should automatically fail.
MaryJom: In most cases you will need to manually check if the file name describes the image.
... Does the rule state clearly that further testing is needed?
... Maybe something in the description will be helpful.
<Wilco> https://www.w3.org/2002/09/wbs/93339/RuleSVGName/results
No further comments on that one. But would need more reviews.
Updated page above with rule status of the discussed rules for publication.
Shadi: There were no objections to including the rules in the understanding documents, we need to figure out how, though. I think if we do pull requests or something that would be the way to go. We would create the pull requests with rules that we think relate to specific understanding documents.
... I will respond to that thread and ask Michael.
... Regardless of the mechanics, let's start with one rule and decide where these techniques should appear.
Wilco: I will take care of these descriptions.
<Wilco> https://www.w3.org/WAI/WCAG21/Understanding/no-timing.html
Wilco: In the understanding document there should be a rules section, same as there is now a techniques section, and probably it would need a desdcriptive paragraph or couple of sentences.
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 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/the AG/the AGWG chairs/ Succeeded: s/This example uses/Wilco: This example uses/ Succeeded: s/Updated rule status/Updated page above with rule status/ Default Present: Daniel, trevor, Wilco Present: Daniel trevor Wilco No ScribeNick specified. Guessing ScribeNick: dmontalvo Found Scribe: Daniel 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.)[End of scribe.perl diagnostic output]