Re: Action: Change Proposal: 3.8. 2.8 Rules Test for Failures

Hi Alistair,

Can you put your proposal in Github, so we can work on it there?
https://github.com/w3c/wcag-act/issues/15

Wilco



On Mon, Nov 21, 2016 at 12:52 PM, Wilco Fiers <wilco.fiers@deque.com> wrote:

> Hi all,
> Apologies, I didn't forward the below mail conversation to the group.
> Please do read.
>
> I'd like to heard other people's take on my altered proposal. I think the
> example could probably be better, like Alistair said. I do think there's
> value in describing that we generally are doing non-conformance testing
> rather then conformance testing, so that we can write tests that aren't
> required to cover the entirety of an accessibility requirement.
>
> W
>
>
> ---------- Forwarded message ----------
> From: Alistair Garrison <alistair.garrison@ssbbartgroup.com>
> Date: Mon, Nov 21, 2016 at 12:19 PM
> Subject: Re: Action: Change Proposal: 3.8. 2.8 Rules Test for Failures
> To: Wilco Fiers <wilco.fiers@deque.com>
>
>
> Hi Wilco,
>
>
>
> Hope all is well with you.
>
>
>
> Your email was not copied to the list, so I have replied to only you.
>
>
>
> I don’t like the second sentence.  For me, it confuses rather than
> clarifies.
>
>
>
> “Images must have an alternative text” is not a clear fail reason, more a
> requirement – a fail reason would be “One or more images does not have a
> text alternative”.  Secondly, we will be able to test “One or more images
> does not have a descriptive text alternative” – it just might have to be a
> manual test.
>
>
>
> I actually don’t think we need to say what we won’t be doing.  Hope this
> helps.
>
>
>
> All the best
>
>
>
> Alistair
>
>
>
> ---
>
>
>
> Alistair Garrison
>
> Senior Accessibility Engineer
>
> SSB Bart Group
>
>
>
> *From: *Wilco Fiers <wilco.fiers@deque.com>
> *Date: *Monday, 21 November 2016 at 10:37
> *To: *Alistair Garrison <alistair.garrison@ssbbartgroup.com>
>
> *Subject: *Re: Action: Change Proposal: 3.8. 2.8 Rules Test for Failures
>
>
>
> Hi Alistair,
>
>
>
> Thanks, that clears it up for me. But how about we contrast the example
> you gave with a brief description of what we won't be doing? Something like:
>
>
>
> The ACT Framework will focus on defining rules that enable clear reasons
> for non-compliance to be given to the user. Breaking accessibility
> requirements down into rules lets us get meaningful results from testing
> parts of an accessibility requirement, where it may not be possible or
> practical to have rules that cover the full accessibility requirement. e.g.
> “images must have an alternative text”, but not "the text alternative must
> be descriptive".  Where possible, ACT Rules should map to [WCAG 2.0 Failure
> Techniques](https://www.w3.org/TR/WCAG20-TECHS/failures.html).
>
>
>
> WDYT?
>
>
>
> Wilco
>
>
>
> On Mon, Nov 21, 2016 at 10:37 AM, Alistair Garrison <
> alistair.garrison@ssbbartgroup.com> wrote:
>
> Hi Wilco,
>
>
>
> “displayed content in a page flashes more than three times per second” was
> an example of a clear reason why something failed – but, maybe it was not
> clear enough J
>
>
>
> Another example might be “The head node does not have a title node as a
> child”.
>
>
>
> Noting, that I prefer to talk about DOM nodes, rather than tags or
> elements – when writing tests to be run against the live DOM.
>
>
>
> The structure I use to write tests is:
>
>
>
> [One or more x nodes | The *x* node], excluding *y* nodes, available in
> the DOM, [has | does not have] *z*.
>
>
>
> Part 2 [“excluding y nodes”], and Part 3 [“available in the DOM”] are
> optional depending on context.  Part 1 and Part 4 represent choices.
>
>
>
> This is the format I have settled into after many years of writing and
> re-writing tests.
>
>
>
> We might think about adopting a standard way of writing tests, so we can
> easily compare them – noting that such a simple notation forces tests to be
> broken down.
>
>
>
> All the best
>
>
>
> Alistair
>
>
>
> ---
>
>
>
> Alistair Garrison
>
> Senior Accessibility Engineer
>
> SSB Bart Group
>
>
>
> *From: *Wilco Fiers <wilco.fiers@deque.com>
> *Date: *Saturday, 19 November 2016 at 10:33
> *To: *Alistair Garrison <alistair.garrison@ssbbartgroup.com>
> *Cc: *Accessibility Conformance Testing <public-wcag-act@w3.org>
> *Subject: *Re: Action: Change Proposal: 3.8. 2.8 Rules Test for Failures
>
>
>
> Hi Alistair,
>
> I'm not sure what the three flashes example is supposed to express here.
> Can you clarify?
>
>
>
> W
>
>
>
>
>
> On Wed, Nov 16, 2016 at 5:29 PM, Alistair Garrison <
> alistair.garrison@ssbbartgroup.com> wrote:
>
> Dear All,
>
>
>
> I have an action item to clarify the meaning of “negative” in the
> following section:
>
>
>
> 3.8. 2.8 Rules Test for Failures
>
>
>
> The ACT Framework results in negative feature tests, meaning that ACT
> Rules test for violations instead of compliance. ACT Rules should map to
> [WCAG 2.0 Failure Techniques](https://www.w3.org
> /TR/WCAG20-TECHS/failures.html) where possible to avoid duplication of
> work. In some cases absence of violations may be proof of compliance, if
> rules are available to test all possible violations.
>
>
>
> I would suggest the following re-write:
>
>
>
> 3.8. 2.8 Rules provide clear reasons for non-compliance
>
>
>
> The ACT Framework will focus on defining rules that enable clear reasons
> for non-compliance to be given to the user e.g. “displayed content in a
> page flashes more than three times per second”.  Where possible, ACT Rules
> should map to [WCAG 2.0 Failure Techniques](https://www.w3.org
> /TR/WCAG20-TECHS/failures.html).
>
>
>
> Interested to hear thoughts / comments.
>
>
>
> Very best regards
>
>
>
> Alistair
>
>
>
> ---
>
>
>
> Alistair Garrison
>
> Senior Accessibility Engineer
>
> SSB Bart Group
>
>
>
>
>
> --
>
> *Wilco Fiers* - Senior Accessibility Engineer
>
>
>
>
>
>
> --
>
> *Wilco Fiers* - Senior Accessibility Engineer
>
>
>
>
>
> --
> *Wilco Fiers* - Senior Accessibility Engineer
>
>


-- 
*Wilco Fiers*
Senior Accessibility Engineer - Co-facilitator WCAG-ACT - Chair Auto-WCAG