E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 8 (In chronological order)

From: Birkir R. Gunnarsson
Date: Sat, Feb 11 2012 4:36PM
Subject: Dealing with accessibility issues in web development service contracts
No previous message | Next message →

Yea wise people.

I was wondering if there is any guidance to be had on the following issue:
I am involved with an organization that outsourced web development for
its website to a third party.
The party uses the DevExpress datagrid to develop the website, and
there are significant tweaks and work-arounds necessary to ensure
proper accessibility for many aspects of the page.
The developers are pretty interested in making the tweaks, but they
charge for every additional hour of work to fix accessibility that was
implied in the original contract (I was not involved in the original
contract work though).
I've seen the same done elsewhere.
It seems that accessibility is solely the responsibility of the
website host, but for the web developer, it is simply a lot of extra
income, due to the additional hours needed.
This often puts the website way over budget and accessibility
obviously suffers as a result. Similarly the web developer contractors
are not particularly interested in inclusive design or development
from the ground up, as the extra work really just means more income
for them

In your experience, what is the share of additional expense between
someone who wants to create a website and those who do the programming
when it comes to accessibility.
Is it usually the sole responsibility of the hosting company, not the
developer, or is there any standard contract language or expectations
that help clarify this and split the cost/responsibility?
I am looking forward to attending the Access U, as I expect these
issues will be touched upon, but any perspective, especially from
those outside of the U.S. would be very interesting.
Thanks
-B

From: Elle
Date: Sun, Feb 12 2012 12:15AM
Subject: Re: Dealing with accessibility issues in web development service contracts
← Previous message | Next message →

Birkir:

As you can imagine, the answer to your question will differ according to
the organization, its structure, its commitment to accessibility, and the
strength of the procurement or vendor management process. If you're going
to CSUN / Access U, I'd like to sit down and chat with you about our
experiences at my company, as I think it would involve more than an email
to properly answer your question. And, of course, it will help you if you
hear more than just one perspective on this topic. I also encourage you to
seek out several others at CSUN who face this issue on a regular basis.



Cheers,
Elle



On Sat, Feb 11, 2012 at 6:35 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Yea wise people.
>
> I was wondering if there is any guidance to be had on the following issue:
> I am involved with an organization that outsourced web development for
> its website to a third party.
> The party uses the DevExpress datagrid to develop the website, and
> there are significant tweaks and work-arounds necessary to ensure
> proper accessibility for many aspects of the page.
> The developers are pretty interested in making the tweaks, but they
> charge for every additional hour of work to fix accessibility that was
> implied in the original contract (I was not involved in the original
> contract work though).
> I've seen the same done elsewhere.
> It seems that accessibility is solely the responsibility of the
> website host, but for the web developer, it is simply a lot of extra
> income, due to the additional hours needed.
> This often puts the website way over budget and accessibility
> obviously suffers as a result. Similarly the web developer contractors
> are not particularly interested in inclusive design or development
> from the ground up, as the extra work really just means more income
> for them
>
> In your experience, what is the share of additional expense between
> someone who wants to create a website and those who do the programming
> when it comes to accessibility.
> Is it usually the sole responsibility of the hosting company, not the
> developer, or is there any standard contract language or expectations
> that help clarify this and split the cost/responsibility?
> I am looking forward to attending the Access U, as I expect these
> issues will be touched upon, but any perspective, especially from
> those outside of the U.S. would be very interesting.
> Thanks
> -B
>

From: Ryan E. Benson
Date: Sun, Feb 12 2012 12:30AM
Subject: Re: Dealing with accessibility issues in web development service contracts
← Previous message | Next message →

Birkir,
Was accessibility explicitly stated in the contract? Was it stated
what it meant for the site to be accessible? Was it stated that the
contractor would submit a document detailing the accessibility of said
website? Was it stated that the organization will verify compliance
prior to payment?

--
Ryan E. Benson



On Sat, Feb 11, 2012 at 6:35 PM, Birkir R. Gunnarsson
< = EMAIL ADDRESS REMOVED = > wrote:
> Yea wise people.
>
> I was wondering if there is any guidance to be had on the following issue:
> I am involved with an organization that outsourced web development for
> its website to a third party.
> The party uses the DevExpress datagrid to develop the website, and
> there are significant tweaks and work-arounds necessary to ensure
> proper accessibility for many aspects of the page.
> The developers are pretty interested in making the tweaks, but they
> charge for every additional hour of work to fix accessibility that was
> implied in the original contract (I was not involved in the original
> contract work though).
> I've seen the same done elsewhere.
> It seems that accessibility is solely the responsibility of the
> website host, but for the web developer, it is simply a lot of extra
> income, due to the additional hours needed.
> This often puts the website way over budget and accessibility
> obviously suffers as a result. Similarly the web developer contractors
> are not particularly interested in inclusive design or development
> from the ground up, as the extra work really just means more income
> for them
>
> In your experience, what is the share of additional expense between
> someone who wants to create a website and those who do the programming
> when it comes to accessibility.
> Is it usually the sole responsibility of the hosting company, not the
> developer, or is there any standard contract language or expectations
> that help clarify this and split the cost/responsibility?
> I am looking forward to attending the Access U, as I expect these
> issues will be touched upon, but any perspective, especially from
> those outside of the U.S. would be very interesting.
> Thanks
> -B
>

From: Jared Smith
Date: Sun, Feb 12 2012 7:57AM
Subject: Re: Dealing with accessibility issues in web development service contracts
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Sun, Feb 12 2012 9:00AM
Subject: Re: Dealing with accessibility issues in web development service contracts
← Previous message | Next message →

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 ADDRESS 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
>

From: Elle Waters
Date: Sun, Feb 12 2012 10:30AM
Subject: Re: Dealing with accessibility issues in web development service contracts
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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
>>

From: Kline, Jeff
Date: Mon, Feb 13 2012 8:27AM
Subject: Re: Dealing with accessibility issues in web development service contracts
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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 ADDRESS 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
>>

From: Bourne, Sarah (ITD)
Date: Mon, Feb 13 2012 8:33AM
Subject: Re: Dealing with accessibility issues in web development service contracts
← Previous message | No next message

Birkir,

You might find our " IT Acquisition Accessibility Compliance Program" useful, or at least interesting! It includes sample documents and other information to ensure contracts sufficiently address accessibility requirements.

http://www.mass.gov/anf/research-and-tech/it-pols-stnds-and-guidance/tech-guidance/accessibility-guidance/it-acquisition-access-compliance-prog/

sb

Sarah E. Bourne
Director of Assistive Technology &
Mass.Gov Chief Technology Strategist
Information Technology Division
Commonwealth of Massachusetts
1 Ashburton Pl. rm 1601 Boston MA 02108
617-626-4502
= EMAIL ADDRESS REMOVED =
http://www.mass.gov/itd

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Sunday, February 12, 2012 11:01 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Dealing with accessibility issues in web development service contracts

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 ADDRESS 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
>