NO MEETING NEXT WEEK
NEXT MEETING 4 JANUARY 2018
WF: some back and forth on the mailing list
... goes back a while, so some recap
... back in March or April we discussed a format to describe tast cases
... did not find anyone to lead the work, so I took it on
... developed a proposal, though not really part of our Work Statement
... it seems to be growing, and to do this work properly it will take
additional time
... since it is not part of our Work Statement and could hold up other
priorities we have, proposing to take this discussion outside the group
... does not mean we will not do it, but just proposing to take it
outside this group
<Wilco> Shadi: We could put this work into a separate track in ACT TF, in a CG such as Auto-WCAG, or a new group
<Wilco> ... If we put it in a TF it could be a working group note. In a CG it could be open to anyone, but we couldn't do a note
Alistair: how far away are we from what we
wanted?
... seem we are close
... do we really need a new group?
... seems like we could get there without a new group
... think implementation validation is part of the scope
... this would help implementation validation
... getting the impression it is being pushed out of the interest of
this group
Mads: have been following the thread with
interest
... seem to agree with Alistair
... think we may be very close here
... EARL seems like a good fit
... but have not studied it in detail
Wilco: don't think we are all that close
... think we will find edge cases and scenarios that will be more
complex
... potential cases we are not looking at in this format
... if we get serious about it, which I think we should, then it will
require some work
... wasn't aware that we could have separate tracks within TF
... interested in that option
<Wilco> https://w3c.github.io/wcag-act-rules/rule-tests/ACT-R2-tests.html
Wilco: example test cases we currently have
did not receive negative comments
... expressing them in machine-readable format seems to be a difficult
task
... current format seems to address our needs
Alistair: can have HTML fragments into the test case descriptions
Mads: test subject embedded into the page could lead to unintended consequences
Wilco: you need to implement the test cases
Kasper: data attributes could affect output
of an implementation
... could pre-process this page and turn it into your test suite
Alistair: where are you holding the HTML fragments?
Wilco: think in a Yaml file
https://www.w3.org/WAI/ER/tests/usingTCDL
<agarrison> Connection dropped... back in a mo...
<Wilco> https://github.com/w3c/wcag-act-rules/blob/master/_rule-tests/ACT-R2-tests.html
Shadi: there could be previous work to build
on
... wonder if we should break out a sub-group to explore this
... maybe just a matter of JSON serialization of TCDL and EARL
Wilco: don't feel I'm the right person to lead that work
Shadi: I could in January
Alistair: heard discussion on shadow-DOM,
not sure we need that
... only applies when you are doing functional testing
<Kasper> +1
<agarrison> +1
<anne_thyme> +1
<Wilco> +1
Wilco: hearing proposal to have a subgroup with separate call, led by shadi
<Wilco> https://github.com/w3c/wcag-act/issues/152
Wilco: homework was to read this proposal
... any comments on it?
... how small to make the rules
... if too small, you have to repeat things throughout
... if too large, they get complex
Mads: yes, we've been asking this as well, how granular
Wilco: think cannot be predetermined, and we
should not try
... can design things differently
... comment on R3: could change scenrio or change it to a rule group
... so Rules Format provides what we need
Mads: this is why we think "expectations"
would help
... they would automatically force you to think in rule groups
Wilco: depends on the requirement, for
example requirements for video could have multiple outputs
... in conclusion this rule is probably too big
Kasper: good point, agree
Mads: so for scenario 4 example would be "sound is not muted"
Wilco: correct
... "muted", "paused", and "stopped" could be single rule
Wilco: but "duration" seems to be a separate issue
Kasper: rule-by-rule basis
Wilco: it seems so
... we'll probably learn as we write more rules
Alistair: happy with this
Wilco: want to bring up issue of applicability again
Kasper: would probably still want to categorize rules
Wilco: want to maximize use of the rules
... for example, mark parts that could be automated
Anne: isn't that what semi-automated tests would do?
Alistair: used to be supporter of selectors
... but meanwhile recognize does not always work
... may need other means of describing
Wilco: also how I understand Siteimprove proposal
Alistair: could be non-trivial to define specific descriptors
Wilco: also what worries me
Kasper: formal definitions, like role of an image
Wilco: back to former topic, can you describe applicability?
Anne: could use test cases to describe coverage?
Alistair: goes back to discussion on
techniques
... if you know what techniques were used for implementation, then you
can constrain
... otherwise need to test for everything
Wilco: question for homework, how can we
create rules that are technology-agnostic?
... like generic techniques
... how would these look like?