Accessibility Conformance Testing Teleconference

21 Dec 2017


Wilco, Shadi, Anne, Kasper, Mads, Alistair


Next meetings



ACT TF and test cases format

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


<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

Issue 140: Allow for alternative structure in ATT (and related Issue 152) https://github.com/w3c/wcag-act/issues/140

<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?

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/12/28 11:03:55 $