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

Re: Costs of testing with Silver

From: John Foliot <john.foliot@deque.com>
Date: Thu, 30 Aug 2018 12:20:57 -0500
Message-ID: <CAKdCpxx1xgj9JG6z3vHUaDaoxj6p9m5o0Y-7MyNzN7xzYjh-=A@mail.gmail.com>
To: Alastair Campbell <acampbell@nomensa.com>
Cc: "Hall, Charles (DET-MRM)" <Charles.Hall@mrm-mccann.com>, "public-silver@w3.org" <public-silver@w3.org>
So this is where I was lazily using ‘cost’ as an outcome of something that
is not feasible or testable.

OK, now I understand. Might I suggest that in *this* conversation, a
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.


For a specific example, you might recall the discussion about non-text
contrast, where the difficulty (and presumably cost) was cited as a reason
not to include that SC.

Sorry Alastair, I don't recall that. Further, we *do* have a new SC
regarding non-text contrast, so I am unclear what you are suggesting here.
I know you and I had a disagreement (ongoing I might add) about whether or
not native focus indication on a modified background color should or would
be in scope, and I believe you may have cited cost of remediation as a
reason for accepting dotted back lines on a black background in Firefox as
"acceptable" or excluded from that SC (even though I still disagree...)


There were multiple COGA SC where the difficulty (and therefore cost) of
testing were factors, such as plain language. IIRC, we both raised that.

Actually, my concern then was around testability and scalability, which we
could not get agreement on. Many of the COGA folk were concerned that
"reading level" was not the right test, yet as I recall, no other testable
method was brought forward. I do not however remember "cost" being part of
that discussion.

Again, while we need to be mindful of cost, that cannot nor should not be a
barrier to advancement in and of itself. As I previously stated, everything
has a cost, and we (at least *I*) are not here for legislation or corporate
policy reasons - we are here to create the right technical requirements and
guidance to benefit people with disabilities.

Retro-fitting a building built in the 18th century to include providing a
lift for people in wheel chairs has a cost. Should physical build
requirements then not include 18th century buildings as requiring
accommodation to those people? And if the job is to create architectural
standards to ensure those lifts are built, we again need to be mindful of
cost, but not necessarily governed or directed by cost, is all I am saying.

JF


On Thu, Aug 30, 2018 at 12:01 PM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi John,
>
>
>
> JF wrote:
>
> > Like others, I've been lurking on this conversation. At this time, I
> have to side primarily with Charles Hall and David Sloan.
>
>
>
> I’m not particularly disagreeing in terms of goals, just trying to pin
> down the how.
>
>
>
> We might have to tease out differences between cost, feasibility &
> testability. For me ‘cost’ is an umbrella for those. Something that is less
> feasible is more costly etc.
>
>
>
> > While the Bronze, Silver and Gold levels has some merit and worthy of
> consideration, it has not been adopted as "the way forward" has it?
>
> Not specifically, but given the requirements for more flexibility and
> measurable & task-based assessment, that’s a mechanism to use during the
> prototyping.
>
>
> > I am unsure where Alastair is coming up with this assertion. As
> experienced professionals in this field, again, we understand that there
> are costs involved, but cost was never a formal consideration during any of
> our work (that I recall).
>
>
>
> So this is where I was lazily using ‘cost’ as an outcome of something that
> is not feasible or testable. For a specific example, you might recall the
> discussion about non-text contrast, where the difficulty (and presumably
> cost) was cited as a reason not to include that SC.
>
>
>
> There were multiple COGA SC where the difficulty (and therefore cost) of
> testing were factors, such as plain language. IIRC, we both raised that.
>
>
>
> Accessible authentication didn’t get in due to concerns about feasibility.
> There already were expensive options for supporting it, but that wasn’t
> enough, there had to be reasonable solutions that work across any website.
> Hence that was a “cost” consideration.
>
>
>
>
>
> > one of my other concerns:  that certain disabilities will remain "left
> out", not due to our ability to address their needs, but to do so has a
> "cost" that some organizations will consider onerous.
>
>
>
> Did you see where I suggested we do include all the requirements? That’s a
> structural change from WCAG 2.x in order to make sure no disabilities are
> left out.
>
>
>
> There will be gaps at the technique/criteria level where there are not
> feasible ways for every website to meet the user-requirements, at least
> initially. That structure would highlights the gaps, and initially they
> could include advice & guidance rather than formal tests for conformance.
>
>
>
> Cheers,
>
>
>
> -Alastair
>



-- 
*John Foliot* | Principal Accessibility Strategist

Deque Systems - Accessibility for Good

deque.com
Received on Thursday, 30 August 2018 17:21:21 UTC

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