See also: IRC log
<Wilco> https://github.com/w3c/wcag-act/pull/96/files?diff=split
Wilco: expanded on section
... comments on proposed text?
Romain: looks good to me
Shadi: looks good to me too
Kasper: definitely needed - especially need
for rules to be consistent
... could add more concrete example
... how does this look like on a rule for a specific technique or
specific success criteria
... there is a difference between failing a failure technique and a
success criteria
... what happens when one technique passes or fails - it doesn't
directly map to the success criteria
<MoeKraft> what's WebEx password? Thanks
Wilco: failure of a rule is a failure of the success criteria
Anne: what about a braod success criterion
like 2.4.1?
... would all these be in one rule?
Shadi: text reads like techniques and
success criteria are both requirements
... but actually only the success criteria are requirements
Wilco: some organizations require certain techniques
Shadi: but these would be like new success criteria
Anne: need to check in detail
Wilco: rules need to be self-contained
... if they have dependencies on other rules then it adds complexity
<Sujasree> +1 to wilco... for example, if we used a technique to meet a success criteria then we need to have both pass and fail test rules for the same
Anne: but then you have several test rules
for one success criterion?
... if one is manual then you cannot automate the process
Wilco: yes. tradeoff between making them small
Shadi: suggest you make the paragraph only
about "accessibility requirements"
... then add a note to say that in WCAG 2 success criteria define
accessibility requirements, not techniques
<Wilco> https://github.com/w3c/wcag-act/pull/94/files
<Wilco> It is important to keep track of what has changed in ACT rules, so that users of them can work out if changes in accessibility results are due to changes in the rules used in testing, rather than changes in the content itself. It is recommended that for huge changes, a new rule is created and the old rule is deprecated.
<Wilco> An example of when a new rule should be created would be when going from a rule that tests the use of a blink element, and changes it to a rule that looks for animated style changes. This potentially adds lots of new issues that were previously out of scope. But for that same rule, adding a step to check if the blink element is positioned off screen, should be done by updating the existing rule.
<Wilco> All changes to an ACT Rule that can change the outcome of a test MUST be recorded in a change log. The change log can either be part of the rule document itself, or be referenced from it. Each new release of an ACT Rule must be identifiable with either a date or a version number.
Romain: purely editorial - would remove
last paragraph to become first
... other comment is how to use the changelog
... think it was for users to see changes
... do we need a requirement, like permament links?
... for users to know which rule changed and to what version
Wilco: probably default W3C approach
... but not sure want to require it for every version
Romain: more about referencing - how can I refer to a particular version of a test rule?
Wilco: had that approach but was not liked
... decided to drop versioning
Romain: but how do we reference particular versions?
Wilco: use case?
Romain: want to compare an implementation
with the reference
... but if the rule changed in between then it will be difficult to tell
+1 to romain
<anne_thyme> +1 to romain and shadi
Shadi: also comparing tools would be
difficult
... need some sort of a handle, like a date or version number or such
Anne: was assuming date-space versioning, like standard W3C
Wilco: anyone disagree?
Alistair: don't you get that from GitHub anyway?
Wilco: yes. W3C uses this approach too. but should it be a requirement?
Alistair: not a huge deal
... doubt we would use the same versioning internally as W3C does
... would probably map to it
Wilco: possibly us too
Shadi: other example than "blink element"?
Wilco: will look for better example
<Wilco> https://wilcofiers.github.io/act-rules/rules/ACT-R1.html
Wilco: want to publish in August
... want to have accompanying example test rules
... is this a good candidate?
Anne: could we also have a less technical example?
<Wilco> https://auto-wcag.github.io/auto-wcag/pages/rules.html
Wilco: good idea, want more than one example
<Wilco> https://auto-wcag.github.io/auto-wcag/rules/SC3-1-1-html.html
Wilco: maybe a rule on language?
Anne: is less scary - just "BCP47"?
Wilco: can put that in a different list
<Zakim> shadi, you wanted to talk about credits
Sujasree: maybe pictorial approach like a
flow chart for the steps of a test rule?
... makes it easier to understand
... do we attach test cases to these test rules?
Wilco: yes, we should
... think part of the requirements
Sujasree: I don't see the corresponding section, which is why I asked
Wilco: there should be one!
Alistair: test rules have to be ironclad
... these seem to have issues
[Alistair lists several issues with aria test rule]
scribe: but also needs to look attractive
<Sujasree> I was talking about something like this - for pseudo code flow chart - http://www.owlnet.rice.edu/~ceng303/manuals/fortran/FOR3_3.html
Wilco: will look for other rules as well
<kasper_isager> Possible option: https://knsv.github.io/mermaid/
Shadi: like the idea of flow chart - is there a generator or a simple way to create them?
Sujasree: will look for it
Shadi: what about a credit section in the test rules template too?
Wilco: like that
Alistair: what if it is two people
Shadi: both listed as contributors?
Alistair: gets gray who did what
Wilco: maybe not that complicated