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

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