RE: Let's add an approved date field to Failures and Techniques

Ø  we could just generalize and say if there is no programmatic determinable alternative then it fails (and then link to the how to docs to reference possible techniques)

The two challenges with this approach in my opinion is that it sounds like we are just re-stating the success criteria.  Also, when we write tests for the failures the test becomes very general and may be so broad that people consider many non-accessibility supported ways pass the test.  With images – at least in the past there were very specific ways that worked and other ways that did not work to programmatically provide a text alternative.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)

Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>

From: Adam Solomon [mailto:adam.solomon2@gmail.com]
Sent: Tuesday, May 03, 2016 4:37 AM
To: Alastair Campbell
Cc: IG - WAI Interest Group List list; GLWAI Guidelines WG org
Subject: Re: Let's add an approved date field to Failures and Techniques

if we generalize the test procedures for failures we would avoid this pitfall
for instance for alternative text for images, instead of saying or alt or aria-label or ...
we could just generalize and say if there is no programmatic determinable alternative then it fails (and then link to the how to docs to reference possible techniques)
enumerating all the possible techniques in the failure test was the main problem with failures

On Tue, May 3, 2016 at 11:27 AM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
Joshue O Connor wrote:
> Yes.  As failures are hard to mint, and David is calling out a need for more,  my 'warning' suggestion is maybe a way of meeting the need without doing normative or quasi normative work.

Surely the reason that failures are so hard to mint is the “multiple ways to pass” approach that WCAG took?
(And I’m obviously saying this with plenty of hindsight! I didn’t think of this at the time.)

If there are 3 techniques to pass an SC, the absence of one of those techniques cannot be a failure.
If a failure must always be a failure, there cannot be another way to pass.

The more technologies (e.g. ARIA) there are available, the more ways there are to pass, the harder it is to create new failures.

I like the idea of warnings, or at least some way to say ‘this is a common way to fail’ without it being absolutist.

It could also provide more context about the technology, e.g. ‘if ARIA is part of your Accessibility Supported list, then if is a failure not to use landmarks for 1.3.1’.

Cheers,

-Alastair