wilco: this ticket is by Anne, separate requirements for rules and implementers. this is a requirement for rules and not for implementers so we should make that clear
... some things should be made informative (not removed).
... rule aggregation should describe how test results impact conformance to accessibility requirements. data format is minimal. only relevant piece is the definitions: identifier, test subject
there aren't real implementation requirements in the document
(previous was wilco)
wilco: aggregation section needs to be removed and merge under accessibility requirements
... be clear for every result that comes from a rule what it means for accessibility req. write up relationship of rule to req
... the how is up to implementers
anne: aggregation should be more restrictive to compare results across rule implementers. removing aggregation will make it hard to compare results
wilco: information in appendix
steinerik: move to informative?
anne: output format should show relationship
shadi: to wilco - why don't you want reqs for implementations
wilco: to stay within scope. w3c shouldn't put reqs on how to write acc tools. rules should just define a common language
shadi: scope is to harmonize how tools and implementations implement wcag, a common understanding. w3c does make recommendations but does not want to limit approaches of tools
... do we want how implementations of rules behave? quality reqs have been removed that force rule developers to harmonize
steinerik: agrees with shadi's points. is it just a format but also harmonization in ACT
shadi: a separate spec for implementers? would like to see an example
wilco: will work on one. question is do we think rules format should have reqs for implementers?
wilco says no, shadi says yes, steinerik undecided
maryjo: scope includes harmonization but isn't stated as normative and a req in spec
... if ACT rule passes or fails a SC, it should be harmonized
wilco to shadi: what would you add to the tests for harmonization?
shadi: w3c acceptance criteria for ACT rules idea: how many independent orgs have to agree on a rule, what is rate of false pos/negs, what is format of output, is output in machine-readable format
... certain commonality is expected.
... maybe put in a working group note...
... determine acceptance criteria for rules
wilco: i don't like 3 implentations for a rule. In informative section on harmonization - act rule becomes a "harmonized" rule if it passes the review process
shadi: rule acceptance has quality requirements. we can bypass implementations with test cases. if a rule has test cases that can demo as accurate, it is clear. Author of rules must include test cases and show accuracy
... for now, is ok with wilco's suggestion of a "harmonized" rule
... accuracy and acceptance will need to be specified as normative; details can be in a non-normative note
steinerik: sounds good. we are crossing rule format and rule writing/implementing. move implementing to informative section
anne: ACT output should be normative so results can be comparable.
wilco: propose leaving in appendix
anne: let's try it
wilco: will make updates
<Wilco> https://github.com/w3c/wcag-act/issues/275
wilco: earl test subject one pointer?
shadi: unlimited pointers but one test subject
wilco: test 3 images on page. test subject is page with multiple outcomes?
shadi: each image is an assertion
wilco: every assertion has a result
... 3 images example, what is the test subject and what is the pointer?
shadi: test subject is page. 3 pointers to images. element can be test subject if it is the only thing being tested but usually the page is tested
... pointer can be used in test subject to point to location
wilco: no changes needed
shadi: no issues
RESOLUTION: ACT TF did not identify any relevance to the security checks