WF: #196?
Jey: working on it
WF: #180?
SAZ: started with Overview GitHub page but needs some further work
WF: when?
SAZ: will try tomorrow
WF: #174?
SAZ: didn't get to it
WF: easy one...
... #138 can be closed?
SteinErik: yes
<maryjom> https://github.com/w3c/wcag-act/pull/199
<Kasper> +1
<anne_thyme> +1
<cpandhi> +1
<maryjom> +1
<MoeKraft> +1
+1
<trevor> +1
<Skotkjerra> +1
<MoeKraft> https://github.com/w3c/wcag-act/pull/200
Anthony: don't understand "accessible uses"
SteinErik: think it is more accurate
Wilco: not sure it is correct
Anthony: maybe another word?
Anne: test accessibility requirement in website
Moe: what about "accessibility of web technology"
Anne: but not technology that we are testing but use of technology
Charu: agree what people are getting at
... maybe say "to test if web technology is accessible"?
<MoeKraft> Definition: accessibility supported supported by users' assistive technologies as well as the accessibility features in browsers and other user agents To qualify as an accessibility-supported use of a Web content technology (or feature of a technology), both 1 and 2 must be satisfied for a Web content technology (or feature):
SAZ: not testing the web technology, testing the web content
<MoeKraft> https://www.w3.org/TR/WCAG20/#accessibility-supporteddef
SteinErik: want to keep word "accessibility
requirements" because this is what we are testing to
... probably testing "web content" but that leaves out "technology"
Moe: we're talking about accessibility
support here
... the definition talks about "use of technology"
<Wilco> "ACT Rules are designed to test that the applications of web technologies is accessible."
Shadi: getting more complex?
Wilco: that was my fear
... Anthony can you take an action to rework your proposal
Anthony: will do
Wilco: think the suggestion here is to document whether a rule is a complete or partial test of a requirement?
Anne: think there are two points here
... first documenting the interpretation of the requirement
... secondly what you just said
... Difi has documentation for each Success Criterion from which they
develop their rules
Wilco: have done some of this documentation
in Auto-WCAG
... for example assumptions around links
... so I would agree but not sure we need a change
SteinErik: agree, not sure it needs a change in the format spec itself
Wilco: maybe we can be a little more explicit in section 3.5
<Wilco> If there are multiple plausible interpretations, the chosen implementation should be documented as an assumption.
Wilco: something like "if there are multiple plausible interpretations, the chosen one should be documented"
Shadi: makes sense, seems like a similar
approach to the Glossary
... to draw out common terms and interpretations
<Wilco> https://auto-wcag.github.io/auto-wcag/pages/structure/aggregation.html
Wilco: on the second point, are there any rules that cover entire Success Criteria?
Anne: possibly the keyboard trap rule group
Kasper: though that's an exception to the rule
Wilco: maybe via aggregation
Charu: agree that this is a source of
ambiguity
... think documenting the aggregation could help
Wilco: combination of individual results can
get fairly complicated
... for example, could pass "has transcript" but fail "descriptive
transcript"
... then there are other ways of aggregating
Charu: this video example is good
... can we describe that in the assumption?
Wilco: not sure if part of the assumption
... hesitant to re-introduce inter-rule dependency
... they should be stand-alone
... dependency will increase maintenance overhead
Shadi: what's the benefit of highlighting partial vs full coverage?
Wilco: tells you if you need additional testing
Anne: helps visualizing coverage
... to see how much of the requirements are addressed
SteinErik: also helps you understand how broadly a success criteria is covered by checks
Shadi: concerned we're adding logic back into the rules?
Anne: we already relate rules to success
criteria
... could do it the other way round too
Wilco: not wanting to couple rules
Anne: not suggesting coupling the rules, just the mapping
Wilco: does not tell you if fully addresses the requirement
Anne: no, would need this on a meta-level
Wilco: can we keep this out of the rule
format itself?
... could document the rare cases where rules cover entire success
criteria
Shadi: like the idea of indicating it in the aggregation file
Wilco: can definitely do that, but gets
complicated very quickly
... we have specifically designed the rules not to cover this
... not like techniques, rules do not confirm adherence to the spec
Charu: agree
... can indicate the rare cases
Wilco: propose we indicate where relevant, but keep it out of the format spec
<Kasper> +1
<Skotkjerra> +1
<cpandhi> +1
<trevor> +1
<maryjom> +1
+1
<AnthonyF> +1
<anne_thyme> +1
Shadi: understand from Alistair that Level Access is happy with the current approach of Assumptions and Expecations in the spec
SteinErik: we say one rule maps to one
accessibility requirement
... but what about rule groups?
... the group itself maps to individual requirements
... but the individual rules within that group could map to additional
requirements
Kasper: so aggregated results may map to
multiple criteria
... and consistency of mapping is kind of lost in that
... need to ensure that the group as whole should be consistent with the
requirement
Wilco: not sure I agree
... example is the video group we will be talking about in Auto-WCAG
... transcript is not enough
... have several test, for example separate track, etc for Level A
... but does not pass the transcript part
Anne: maybe rules in rule groups should not map to requirements at all, only the rule group
Wilco: certainly needs more explanation
... can I assign this to you?
Kasper: yes, sure