See also: IRC log
Wilco - question from Roman on labeling for input data and whether or not it needs to be there
Wilco - how strictly do we want to stick with Earl
Wilco - if we are then we should base everything on Earl
Shadi - Earl is incomplete, we did not have enough implementations. There is no requirement to do this. Suggestion is to stick with Earl unless there is a reason to deviate
Wilco - one of the reasons could be that we need different terminology
Shadi - web content and test subjects are terms are in Earl
Shadi - what do you mean by web content
Wilco - really about what is the thing that we are testing and what name we give to that
Shadi - Earl is like object oriented programming
Wilco - question for Allistair is that web content clear enough term
Alistair - usually say something under test
Wilco - go with test subjects as a term
Wilco - no objections so will make the change
Wilco - second comment from Mary Jo - use the term in Earl
Wilco - any other comments?
Wilco - no, so we will merge this in
Wilco - no comments on this
Moe - there were 6 responses in the survey
<MoeKraft> https://www.w3.org/2002/09/wbs/93339/ACTTF8Feb2017/results#xQ5
<MoeKraft> Accessibility experts often disagree on how accessibility requirements should be tested. These disagreements on how a requirement should be tested, lead to conflicting results of accessibility tests. This is true for both manual accessibility tests as well as for accessibility testing done through automated test tools (ATTs).
AG: by reference alone, test includes
everything you are testing for
... no need to repeat in the supported bit
... seems repetitive
WF: optional?
AG: useless
WF: suggest to keep for now until we figure
out accessibility support
... if it turns out repetitive, then we can keep it
AG: accessibility support woven in could be
useful
... worried about maintance of accessibility support
WF: idea is that rules won't have to change
... but tools may change which rules are running
... depending on environment of the testing
SAZ: doesn't evaluator need to know what is accessibility supported or not?
AG: best is owner to define that
SAZ: WCAG recognizes accessibility support
WF: need to move on
KW: compatibility testing as black-box
testing
... testing for requirements is more white-box
... really two different ways of testing
... WCAG 2 requirements are testable
... but support changes in ATs and browsers
WF: agree that accessibility support may not apply to majority of tests
<MoeKraft> I have to drop. Have a good week.
WF: and the approach suggested by AG makes
sense to some extent
... but also other approaches being used
... where people look at what is supported or not
... want to find a way to support the second, if possible
KW: maintaining that is very difficult
... changes very frequently
WF: we don't have to maintain anything
... just making the accessibility support assumptions explicit
... then evaluators can select matching rules
SAZ: do we have an auto-wcag rule as an example?
KW: not against this idea but concern is
that how the code fits in the entire page can also be an issue
... cannot always be definitive
MJM: in some languages AT implementations are far behind
WF: but that is exactly the reason for this approach
MJM: how can evaluators keep up with all this?
WF: they don't have to
... just making "relied upon" more explicit
... if AT does not support this feature, then they know they can exclude
the rule
KW: add editor note to explain concerns and considerations?
WF: absolutely, good idea
<Kathy> +1
+1
<maryjom> +1
<agarrison> +1 for editors note
Alan: +1
WF: need additional meetings to catch up on
schedule
... meeting *in addition* on Thursday 16 and Thursday 23
... keeping Wednesday 22 as well
... all same time