WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Dealing with accessibility issues in web development service contracts

for

From: Kline, Jeff
Date: Feb 13, 2012 8:27AM

Birkir:

It also very important to include accessibility language (such as meeting an selected accessibility standard...WCAG, 508, etc.) in contract solicitations. Inserting accessibility language into a contract once the supplier has been selected is too late, in that the capabilities of the supplier's accessibility skills / experience will not be known.

When accessibility language / criteria is included in the solicitation, supplier responses can be compared, giving you (the customer) the opportunity to discuss the responses with the suppliers and obtain additional information about their accessibility abilities....test methods, developer skills, VPAT information, etc. This information then be factored in to the "award" decision, and standard accessibility language integrated into the contract subject to the same terms as other aspects of the contract...warranties and representations, corrective actions, etc.

In the situation you described, I suggest caution in allowing the supplier to commence this work until you and your organization are confident that they can actually do it. If they have no prior experience, you could see a lot of problems. I also suggest that you include very specific language in the contract addendum, or whatever instrument you use for such things.


Jeff Kline
Statewide EIR Accessibility Coordinator
Texas Department of Information Resources
Phone 512.463.3248

Strategicaccessibility.com




-----Original Message-----
From: Elle Waters [mailto: <EMAIL REMOVED> ]
Sent: Sunday, February 12, 2012 11:34 AM
To: WebAIM Discussion List
Cc: WebAIM Discussion List
Subject: Re: [WebAIM] Dealing with accessibility issues in web development service contracts

Birkir:

I will bring some samples of contract language that may prove useful.


Thanks,
Elle



On Feb 12, 2012, at 11:00 AM, "Birkir R. Gunnarsson" < <EMAIL REMOVED> > wrote:

> Hi everyone
>
> Thanks for your responses.
> Elle, I would be excited to sit down with you and others at Access U
> to discuss the matter.
> The contract was very lacking in specifications of accessibility and
> how it would be tested, there was merely a very general statement that
> the site should be accessible without any specifications as to what
> exactly that entailed. Iceland is simply so new to this that I am the
> only authority on the matter (and I have lots to learn myself).
> Any samples of contract language, what would be satisfactory testing
> etc, would definitely be much appreciated and, yes, I realize more and
> more that this is perhaps better handled in dialog than through email.
> Per my experience, so far, I'd probably assume WCAG 2.0 AA, with a few
> exceptions (I like the recent WebAIM blog on WCAG 2.0 considerations),
> I would probably have to allow for a few WCAG evaluator errors, as we
> know that WCAG 2.0 compliance by itself is not entirely indicative of
> usability, and there are, perhaps, a few problems in automated
> checking.
> I'd also want to go through the 2 or 3 most commonly performed tasks
> or processes on that particular website with a screen magnifier and
> two screen readers (NVDA, most recent, and second to most recent sr,
> probably Jaws), and demand necessary fixes to problems discovered in
> these processes be implemented as part of the service contract.
> Are requirements along these lines something frequently put into
> development contracts?
> You often get organizations that are, on the surface, very committed
> to accessibility, but lack detailed directions of what is meant by
> that.
> Are there any samples of actual development contract statements out
> there regarding the definition of accessibility, or anything people
> would be able and willing to share as blueprint?
> Cheers
> -B
>
> On 2/12/12, Jared Smith < <EMAIL REMOVED> > wrote:
>> Birkir-
>>
>> Trying to force accessibility into a complex project after it has
>> been developed can be very difficult and, as you note, expensive. We
>> have worked with a few clients who decided that it would be more
>> cost-effective to simply re-build the site with accessibility
>> requirements (and a new design, other web standards, best practices,
>> etc.), rather than continue the often never-ending battle of
>> implementing accessibility hacks and fixes into a site that does not
>> support them and that is administered by third party vendors who
>> don't care about or understand accessibility.
>>
>> In one case a client was quoted a 7 digit number to implement
>> accessibility alone (which, by the way, was absurdly over-priced).
>> The price to rebuild the entire site with a knowledgeable vendor and
>> also include accessibility was only a bit more. It was an obvious
>> decision to start over.
>>
>> Most sites only last a few years. If you're considering a significant
>> update or rebuild in the future, you may be better off waiting. If
>> not, the cost efficiency of your site updates will be proportional to
>> the accessibility knowledge of your vendor, so you might start with
>> educating them rather than asking them to implement accessibility
>> items they likely will not understand (but are happy to charge an
>> hourly rate to attempt to implement).
>>
>> Jared Smith
>> WebAIM.org
>>