Re: Costs of testing with Silver

Wilco writes:

> You argue that it's economically viable for web developers to do a free
WCAG 2 audit for every $5k website, as a standard practice.

Not at all. I have not said that, and I do not know where you are pulling
those numbers from.

I'm arguing that if the developers use the requirements and techniques
articulated in WCAG, they won't be having to go looking for problems, they
will instead be confirming that no problems exist. An audit comes at the
end: shift left, and have the developers do the right thing in the first
place, thus your "audit" is nothing more than your already existing QA task
- it's one and the same, not separate.

Additionally, I am suggesting that any web dev shop that sells
"accessibility" as an additional line-item cost on their invoice is already
a shop thinking about accessibility wrongly. When I order a meal in a
restaurant, I don't pay for the food, and then pay the energy cost to cook
that food separately. Web dev shops care about accessibility, or they
don't. The "cost" of doing accessibility is a red herring in that context:
the real cost is in learning how to do things correctly, not in running an
audit at some fixed point in time - a point we've also been making in the
mainstream for ages now.

Your argument is similar to saying that mechanics will change your brakes
for $30, but if you want them to also do a safety check to make sure those
brakes work, it's an additional $100. If a web dev shop wants to price
their services that way, all the power to them. But to say that their
pricing model should influence levels of conformance within WCAG is the
tail wagging the dog: it perpetuates the wrong idea that accessibility is a
separate, additional feature, a line item that can be added or removed to
adjust the bottom line.

Finally, you argue that it's cost that is stopping smaller shops from doing
accessible web development - which I would also question. Do you have any
proof, besides an anecdotal observation that 10 years ago when we moved
from WCAG 1.0 to WCAG 2.0 that smaller shops in the Netherlands stopped
caring or checking for accessibility conformance? And what is more
important? An accessible site today, or a piece of paper dated 12 months
ago that said that you found my site to be accessible back then?

Again, I don't want to ignore cost, but I do want to keep it in
perspective, and in the perspective of a standards org that writes
standards, specifically a standard that ensures access to as many PwD as we
can achieve, and not the accounting office of small businesses that turns
over every penny. I am sympathetic to cost, but only to a point - I am more
concerned that we don't leave users behind because it "costs the dev team
too much" to do.

I'm more focused on the priority of constituents: Users over Authors,
Authors over Implementers, and Implementers over Code Purity. All I am
saying is when we have a discussion on cost, I believe it is important we
keep that principle in mind as well.

JF

On Fri, Sep 7, 2018 at 4:55 AM, Wilco Fiers <wilco.fiers@deque.com> wrote:

> Hey all,
> @Mike Crabb: I think this is very interesting stuff. I am aware that work
> is already happening that could be used to solve the problem I've outlined.
> Having different requirements based on the type and complexity of the
> content you are testing makes total sense to me. I am looking forward to
> seeing those modals, and I think it's very much worth the effort to try and
> work out how we can have testing with Silver to average out around 5% of
> the total website budget.
>
> @John F. I ask that you keep an open mind to this idea of adjusting
> requirements based on the complexity and type of content. As Mike
> suggested, work is already happening on this. Lets at least try to solve
> the issue, instead of rejecting it out of principle.
>
> You argue that it's economically viable for web developers to do a free
> WCAG 2 audit for every $5k website, as a standard practice. Not just "easy
> check" style testing, but a full WCAG 2 audit. Can you show me any
> organisations that do this today?
>
> Wilco
>
> On Fri, Sep 7, 2018 at 5:26 AM Victoria Clark <
> fromtheturtlesback@gmail.com> wrote:
>
>> Hello all,
>>
>> This is the first time I've responded to a thread but, boy, was this a
>> whopper of a discussion! I like the idea of a tiered system of conformance,
>> as this hierarchy is something I have seen used across multiple
>> organizations. I'm used to a hierarchy based on level of access: blockers
>> (one or more PwD would be blocked from digital content), poor ease of use
>> (not blocked, but it is difficult, takes longer, and/or is confusing), and
>> enhancements/usability. I like the added layer of including certain
>> functions being required of a user agent vs. the development.
>>
>> On Thu, Sep 6, 2018 at 1:03 PM Alastair Campbell <acampbell@nomensa.com>
>> wrote:
>>
>>> Hi Everyone,
>>>
>>>
>>>
>>> I think we would struggle to put together a document that provides well
>>> defined levels for types of organisation, or even size of project. Many
>>> project are updates to an existing web-estate, so lots of small project
>>> could then avoid requirements.
>>>
>>>
>>>
>>> I’ll try and be solution focused, and suggest that:
>>>
>>>
>>>
>>>    - We lead with the user-requirements as ‘guidelines’ (as I suggested
>>>    previously), with general and per-technology specific criteria underneath
>>>    that guideline.
>>>
>>>    - Each guideline could have levels, like A/AA/AAA, except that it
>>>    cuts the criteria into levels instead of the guideline. E.g. WCAG 1.3.1 for
>>>    HTML could be split into:
>>>       - *Guideline*: The design is represented with appropriate
>>>       structure and metadata.
>>>       - *HTML Gold*: Every element uses the right tag/attributes, and
>>>       are appropriately nested (manual test).
>>>       - *HTML Silver*: Headings and lists are used and correctly
>>>       nested, labels and for/ID relationships are valid.
>>>       - *HTML Tool Bronze*: The CMS provides a headings feature for
>>>       content authors, and warns about full lines of bold text.
>>>       - *HTML bronze*: Headings and lists are used (with some
>>>       pre-defined auto-wcag style tests)
>>>       (A quick, off-the-top-of-my-head example.)
>>>
>>>       - The requirement is not split between levels, but the amount of
>>>    effort needed to achieve it might be.
>>>
>>>    - Some requirements are weighted more towards user-agents and
>>>    authoring tools. If Wix/Squarespace/Wordpress et al provided options for
>>>    (more) accessible output, smaller organisations would have less testing to
>>>    do.
>>>
>>>    - One for John: At bronze the requirement for focus styles could be
>>>    placed on the user-agent, but for silver/gold the requirement could be for
>>>    the site.
>>>
>>>    - There could be a ‘slice’ of the criteria that are aimed at sites
>>>    using a good tool provider, reducing the testing ‘surface area’.
>>>    NB: The tool provider would need to say that they fulfil the other
>>>    requirements, so it becomes a marketing & procurement issue rather than a
>>>    site development issue.
>>>
>>>    - I take John’s point that we have little or no leverage with the
>>>    user-agents, but if we lead with the user-requirement, and provide
>>>    ‘techniques’/  methods across websites/UA/authoring tools, it will make it
>>>    much clearer where the effort needs to be applied!
>>>
>>>    - If we go down the route of levels for organisation capability,
>>>    then it should be tied to other activities they are doing. For example,
>>>    usability testing could be a valid method if the organisation already runs
>>>    such testing in general, and that puts them above the small scale. This
>>>    supports my recurring point that some things should be process-based rather
>>>    than content based.
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> -Alastair
>>>
>>>
>>>
>>
>
> --
> *Wilco Fiers*
> Senior Accessibility Engineer - Co-facilitator WCAG-ACT - Chair Auto-WCAG
>



-- 
*John Foliot* | Principal Accessibility Strategist

Deque Systems - Accessibility for Good

deque.com