W3C home > Mailing lists > Public > public-silver@w3.org > August 2018

RE: Costs of testing with Silver

From: Alastair Campbell <acampbell@nomensa.com>
Date: Thu, 30 Aug 2018 22:57:38 +0000
To: John Foliot <john.foliot@deque.com>
CC: "public-silver@w3.org" <public-silver@w3.org>
Message-ID: <AM5PR0902MB20026ED341A3BDEC460EDE83B9080@AM5PR0902MB2002.eurprd09.prod.outlook.com>
Hi John,

At this point of violent agreement it’s probably best to give everyone a break and say: Let’s discuss it when we see the prototypes.

And I like the pics, I hadn’t seen the braille “when lit” one! 😊

Cheers,

-Alastair

From: John Foliot <john.foliot@deque.com>
Sent: 30 August 2018 23:53
To: Alastair Campbell <acampbell@nomensa.com>
Cc: public-silver@w3.org
Subject: Re: Costs of testing with Silver

Alastair wrote:

I’m suggesting the structure starts with user-requirements, with general & per-technology criteria underneath that. Each criteria could be assigned a level, and certain criteria may not be technical requirements (i.e. not like the binary content requirements we have now).

Sure, but with that type of granularity, it will actually (probably?) add to the cost of testing, not reduce it, as now you will have different test-runs based on content and platforms. I'm not opposed to that in principle, but it does toss a spanner into the cost discussion...


My larger concern is that we seem to be talking about a Good, Better, Best scenario - but the flip side to that is, by my experience and observation, "good enough" is rarely either - it's neither good nor enough.

I do suspect however that what you are talking about is more like the current WCAG at the Principles and Guidelines level, and not the SC level. In that aspect, yes, I could envision individual SC continuing to be targeted to content or platform. My overarching concern however is that we don't start to perpetuate the idea that "70% Accessible is Good Enough(TM)", or that somehow "accessible" is measured as an aggregate score of how many check-boxes you've ticked off - we have far too many examples of that failing in the wild today.

[cid:image001.jpg@01D440BD.3BA6F0E0]
(Image: 70% accessible ramp - it goes to roughly 4 steps before the top of the stair-case)
[cid:image002.jpg@01D440BD.3BA6F0E0]
(Image: Check-box accessibility - Braille signage/labels on buttons in an elevator. The sign in braille reads "Door locked when lit")

[cid:image003.jpg@01D440BD.3BA6F0E0]
(Image: Check-box accessibility, part 2 - Braille labels behind glass in a vending machine)

...and yes, I have more... :)

JF


On Thu, Aug 30, 2018 at 4:44 PM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
Hi John,

> merging of those ideas is counter-productive (or at least confusing), as Wilco started this thread specifically about the CO$T of testing, and not of feasibility or testability.

There is overlap, in the non-text contrast SC the issue (that didn’t win the argument) was that it would take too long to test all the images, it wasn’t automatable. “Testability” has included whether it is possible to test in a reasonable time.

An example for implementation was accessible authentication, there were several methods [1] to avoid having to rely on passwords. However, there wasn’t a browser-native method so any organisation implementing it would have to do so independently, and currently that is relatively expensive.
(Since then webauth became a recommendation, we should revisit that.)


Re plain language:
> my concern then was around testability and scalability, which we could not get agreement on.

How is that different from cost? With infinite time and the creation of common dictionaries per topical domain you could test it, but I agreed that it was not practical in a WCAG 2.x context.


> we are here to create the right technical requirements and guidance to benefit people with disabilities.

Agreed, and we aren’t disagreeing very much. My point is we won’t have technical requirements to meet some of the user-requirements, so whatever conformance model we come up with will need to account for that.

I’m suggesting the structure starts with user-requirements, with general & per-technology criteria underneath that. Each criteria could be assigned a level, and certain criteria may not be technical requirements (i.e. not like the binary content requirements we have now).

Cheers,

-Alastair

1] https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/1037.html




--
John Foliot | Principal Accessibility Strategist

Deque Systems - Accessibility for Good

deque.com<http://deque.com/>

image001.jpg
(image/jpeg attachment: image001.jpg)

image002.jpg
(image/jpeg attachment: image002.jpg)

image003.jpg
(image/jpeg attachment: image003.jpg)

Received on Friday, 31 August 2018 03:34:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:23:55 UTC