<scribe> scribe: Wilco
carlos: nothing on final call
<CarlosD> wilco: the new process of reviewing rules has been approved and adopted
<CarlosD> ... we're going to move away from a separate website
<CarlosD> ... and rules will be published as proposed rules on the WAI website
<CarlosD> ... people interested to participate in the TF meetings (and with 4 weekly hours to work on this) contact Wilco or Shadi
<CarlosD> ... the TF will be going through the current list of rules and check for anything that would prevent them to be published as proposed rules
<CarlosD> ... given that we don't need to go through this agenda idtem
<CarlosD> ... because the TF will be doing this work
<CarlosD> ... but it might still be useful to have a regular agenda item where someone from the TF updates this group on the status of that work
<CarlosD> carlos: just for clarification, when there are changes requested the TF will either handle it themselves or contact the rule author directly
Carlos: Related to most rule
implementors
... Implementors fail to regularly update us on problems with
rules. Jean-Yves does this well.
... When an implementor finds an issue in their tool, how do
they feed this back to the community group?
Anne: They could just raise an
issue. We thought originally that people would submit extra
test cases.
... Were originally worried we'd get a ton of test cases, but
that is not happening.
Jean-Yves: Changing the rule is a
fairly heavy process, especially if the fix is not easy. Just
adding a new test cases isn't enough, you have to correct the
rule.
... What we do is to open an issue when we find something.
Sometimes it's a problem with our own implementation, but in
other cases the rule is wrong. We added 2 issues this
week.
... It's easier for us to file an issue than it is to change
the rule. We have our own copy of the rule to keep in
sync.
... We do have a lot of open issues, and don't have a clear
process to deal with them.
... The process is two parts; how do we report the problem,
maybe open an issue? The other part is how we make sure the
issue is handled.
Carlos: Those are two separate problems.
Anne: I myself felt hesitant, if I'm expected to handle the issue I opened.
Jean-Yves: May feel discouraging for people reporting if we don't handle issues. These are independent problems, but they are linked.
Anne: It is better if there are raised issues. Is it possible to create a view of issues raised for the rule?
Jean-Yves: yes, under Useful
links, but only if the rule ID is in the issue.
... It is part of issue grooming to add the rule ID to the
title. I used to do this, but don't have the time now.
Wilco: Maybe this group could shift it's focus on resolving open issues?
<shadi> https://w3c.github.io/wai-wcag-supporting-documents-redesign/2020-07-15-prototype-act.html
Shadi: Encouraging feedback is a
general issue across WAI. Maybe in the future we could think
about some link in the sidebar to find issues.
... The more visibility the rule will get, the more people
might provide feedback.
Carlos: So two problems, one is to get feedback. Need not to discourage feedback.
Emma: The How to contribute does
not have a link to Implement a rule. Maybe we need more
information on how to feed back information.
... Some of this needs to go into the documentation.
Carlos: Agree, but I do think
there is an opportunity to get feedback from non-implementors
too.
... We can update text in the issue template, to tell people to
include the rule ID in the title
... We have the useful link, it goes directly to edit file. We
may want to ask people to keep the rule ID there.
Yean-Yves: We may want to add a link to report an issue. We could maybe open an issue with the rule ID prefilled.
Wilco: There are things you can
do to encourage the right format on github issues.
... We could also look at having a regular reminder when tools
do a release to look through their changelog and report issues
related to rules.
Jean-Yves: probably don't want to spend too much time on the website if it disappears soon, but something to consider when designing the new site.
Carlos: Tracking versions seems complicated. We don't keep versions of the rules here.
Wilco: Would like a place to track our homework, and where it is apparent if we haven't.
Jean-Yves: Feels like this should
be an internal process. What we could get is tool version
information in the implementation report.
... When you submit a report with a new version, you could
maybe send an e-mail?
... It's hard for the CG to change the process of vendors.
Carlos: If we have version numbers, any time we detect an update we could send a reminder. If the issue is more serious we could detect changes in reports from a tool, but won't handle all test cases.
Anne: A related concern is that a report could be made on an old version of the rule, you'll get what seems to be a full implementation that wouldn't be a full implementation.
https://act-rules.github.io/rules/ff89c9#implementation-metrics
Jean-Yves: If a test case changes
it is reported as not complete.
... Maybe we need instructions in the How to contribute page
how to contribute an implementation. Have it mention that if
you find issue to open an issue.
Carlos: One thing to do is to improve documentation on the CG site.
Emma: There are quite a few TODOs still in the documentation.
Carlos: Most of the links marked as todo, they are related to creating issues / pull requests / reviewing pull requests.
Anne: I found the github
documentation needs information on what labels to use, and who
to write.
... As a new commenter, I couldn't work out which button to
push when.
Daniel: +1, some github documentation is useful, but we should create our own guidance on that.
<HelenB> +1 as had to have Wilco help me :)
Anne: It's not just too providers that should be guided through the process, but also manual testing methodologies. We want to provide an implementation, but don't know where to start.
https://act-rules.github.io/pages/implementations/wcag-em-tool/
Wilco: You can use the report tool for manual implementations.
Carlos: On handling feedback, have we considered some issue prioritisation?
Anne: Sounds like a good idea
Wilco: Chairs should do grooming, and use the CG calls to assign and track issue progress.
Carlos: Sounds good
Jean-Yves: Span with role=lnik is not in the accessibility. Wilco suggested using hidden-state false.
Aron: The first example of
included in the accessibility tree indicates that the span is
included in the accessibility tree.
... Also looked at HTML-AAM, the span does appear to be mapped,
which means it is included.
Jean-Yves: If there is a span with text, the text is in the accessibility tree, the span is not
Aron: Only elements with semantic roles are in the accessibility tree, but our examples confused me
Jean-Yves: those are wrong.
Aron: Also ARIA examples, if something is a text node it is included in the accessibility tree.
Anne: Don't understand hidden-state.
Jean-Yves: [reads
definition]
... https://act-rules.github.io/glossary/#hidden-state
Carlos: Sounds like we all agree with the fix.
Jean-Yves: I'll work on the issue
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: CarlosD, Wilco, anne_thyme, Jean-Yves, Daniel, HelenB, EmmaJ_PR Present: CarlosD, Wilco, anne_thyme, Jean-Yves, Daniel, HelenB, EmmaJ_PR, Aron Found Scribe: Wilco Inferring ScribeNick: Wilco 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]