E-mail List Archives

Search E-mail List Archives for

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

From: MULLIN, WENDY
Date: Thu, Aug 19 2010 2:06PM
Subject: Procurement language for web accessibility
No previous message | Next message →

Hi everyone -

I'm looking for suggestions for procurement language for web
accessibility and software products. Specifically, I'm looking for
language to put in a RFP (Request for Proposal) any outside website
development or software product which will have a web interface.

I remember reading in several places (but I can't remember where now)
that the language in an RFP should include that the product be
accessible and that a certain level of compliance should be specified
(such as 508 compliance).

I would appreciate any sample wording, links to examples, or other
thoughts or ideas.

Thanks.

Wendy

Wendy R. Mullin
Web Developer
University Technology Services
University of South Carolina
1244 Blossom Street, Columbia, South Carolina 29208
voice: 803-777-6785 | fax: 803-777-1900
email: = EMAIL ADDRESS REMOVED =

From: Bevi Chagnon | PubCom
Date: Thu, Aug 19 2010 7:45PM
Subject: Re: Procurement language for web accessibility
← Previous message | Next message →

For US Federal Government contracts, I build my contract language based on
the U.S. Access Board's ITC Standards and Guidelines, especially draft 2
that should be finalized later this year.
http://www.access-board.gov/sec508/refresh/draft-rule.htm

For non-government contracts, you can still cite the fed's ITC standards,
but also cite WCAG 2.0.

In the RFQ, you should put in an "incorporated by reference" clause that
cites the document online. This means that everything in the document is
automatically made a requirement for your contract.

In the final contract, or even in the RFQ, state the key parts of the
ITC/WCAG standards that you want to emphasize, including any
methods/techniques to meet your specific design requirements. Example:
In addition to all the guidelines in the ITC, we are especially concerned
with accessible tables and forms on the proposed website, which are
documented in the following sections of the ITC:
- Section 503.2
- Section 503.2.1
- Section 503.2.2

Also add any other features you want, beyond accessibility requirements.

Don't forget electronic deliverables of any documentation, such as user
manuals, guidebooks, etc. including Word documents and PDFs. They must meet
Chapter 5 guidelines in the ITC standards.

And add a section about how you'll test and assess the project. What will
make it "pass" and be accepted, how any failures will be remediated by the
contractor, contract modifications (more money, time), and which assistive
technologies will be used to test the website (JAWS, Windows Eyes, Acrobat
Read Out Loud, etc.)

Hopefully you've also included a SOW (statement of work) and functionality
document as part of the RFQ/contract, so these guidelines will complete the
paperwork.

To be fair to the contractor, you might want to require an accessibility
test at one or two points during the development phase, just to be able to
flag problems before the contractor spends a lot of resources going down the
wrong path.

Hope this helps.
- Bevi Chagnon

PS:
The new federal ITC standards specifically state that all federal agencies
are covered (some exceptions, see E102). It does not apply to state
agencies, private sector organizations, or recipients of federal money, like
your Univerisity (most likely).

But based on my professional experience, I think eventually all recipients
of federal money will need to meet ITC requirements for their websites and
electronic documents, just like they have had to provide handicapped access
to buildings, restrooms, public transportation, and other facilities under
the Architectural Barriers Act of 1968.

If that does happen, it will be a few years from now. But my theory is to
incorporate ITC standards now along with WCAG 2.0 and get the job done.

From a teaching viewpoint, the language and guidelines in the ITC are much
easier for my adult students (federal webmasters and publishers) to grasp
and put into practice than WCAG 2.0. It's something about how both
gudelines are written. Plus the ITC covers electronic documents (.doc, PDF,
etc.) and software interfaces, while WCAG only addresses websites.

If I had to choose just one, it would be ITC. It's a better document.

Sorry. This became a long PS!

: : : : : : : : : : : : : : : : : : :
: : : : : : : : : : : : :
Bevi Chagnon | PubCom | = EMAIL ADDRESS REMOVED = | 301-585-8805
Government publishing specialists, trainers, consultants | print, press,
web, Acrobat PDF & 508
Online at the blog: It's 2010. Where's your career heading?
www.pubcom.com/newsletter

From: Mills, Teresa
Date: Fri, Aug 20 2010 1:42PM
Subject: Re: Procurement language for web accessibility
← Previous message | Next message →

You might be interested in comment below.

From: Hoffman, Allen
Date: Fri, Aug 20 2010 1:48PM
Subject: Re: Procurement language for web accessibility
← Previous message | Next message →

Here is proposed language you may consider using:
You can consider replacing Section 508 with WCAG 2.0 here, and making
some adjustments of some of the other technical language. There is not
reason you can't apply Section 508 standards to such an acquisition,
especially if some of the funding was from a Federal source or grant.

Accessibility Requirements:

Section 508 of the Rehabilitation Act, as amended by the Workforce
Investment Act of 1998 (P.L. 105-220) requires that when Federal
agencies develop, procure, maintain, or use electronic and information
technology (EIT), they must ensure that it is accessible to people with
disabilities. Federal employees and members of the public who have
disabilities must have equal access to and use of information and data
that is comparable to that enjoyed by non-disabled Federal employees and
members of the public.

All EIT deliverables within this work statement shall comply with the
applicable technical and functional performance criteria of Section 508
unless exempt. Specifically, the following applicable EIT accessibility
standards have been identified:

Section 508 Applicable EIT Accessibility Standards

36 CFR 1194.21 Software Applications and Operating Systems, applies to
all EIT software applications and operating systems procured or
developed under this work statement including but not limited to GOTS
and COTS software. In addition, this standard is to be applied to
Web-based applications when needed to fulfill the functional performance
criteria. This standard also applies to some Web based applications as
described within 36 CFR 1194.22.

36 CFR 1194.22 Web-based Intranet and Internet Information and
Applications, applies to all Web-based deliverables, including
documentation and reports procured or developed under this work
statement. When any Web application uses a dynamic (non-static)
interface, embeds custom user control(s), embeds video or multimedia,
uses proprietary or technical approaches such as, but not limited to,
Flash or Asynchronous Javascript and XML (AJAX) then 1194.21 Software
standards also apply to fulfill functional performance criteria.

36 CFR 1194.31 Functional Performance Criteria, applies to all EIT
deliverables regardless of delivery method. All EIT deliverable shall
use technical standards, regardless of technology, to fulfill the
functional performance criteria.

(optional) 36 CFR 1194.41 Information Documentation and Support, applies
to all documents, reports, as well as help and support services. To
ensure that documents and reports fulfill the required 1194.31
Functional Performance Criteria, they shall comply with the technical
standard associated with Web-based Intranet and Internet Information and
Applications at a minimum. In addition, any help or support provided in
this work statement that offer telephone support, such as, but not
limited to, a help desk shall have the ability to transmit and receive
messages using TTY.

All tasks for testing of functional and/or technical accessibility
requirements must include specific testing for Section 508 compliance,
use accepted accessibility testing practices and tools, and clearly
document conformance with accessibility requirements for the products
tested.

From: Michael.Moore
Date: Mon, Aug 23 2010 7:33AM
Subject: Re: Procurement language for web accessibility
← Previous message | Next message →

Here is the url for the a link to the language being implemented at Texas HHS agencies.

<http://architecture.hhsc.state.tx.us/myweb/Accessibility/website/word/HHSUniformEIRAccessibilityClause.doc>;

Mike Moore

From: Mark Magennis
Date: Mon, Sep 06 2010 10:08AM
Subject: Re: Procurement language for web accessibility
← Previous message | No next message

Another example worth looking at is the cut&paste text on accessibility targets provided in the IT Procurement Toolkit published by the Centre for Excellence in Universal Design in Ireland.

The suggested text for web accessibility targets is on the page http://www.universaldesign.ie/useandapply/ict/itprocurementtoolkit/accessibilitytargets/webtechnologies .
Short URL: http://bit.ly/a5YFEV

Mark

On 19 Aug 2010, at 21:04, MULLIN, WENDY wrote:

> Hi everyone -
>
> I'm looking for suggestions for procurement language for web
> accessibility and software products. Specifically, I'm looking for
> language to put in a RFP (Request for Proposal) any outside website
> development or software product which will have a web interface.
>
> I remember reading in several places (but I can't remember where now)
> that the language in an RFP should include that the product be
> accessible and that a certain level of compliance should be specified
> (such as 508 compliance).
>
> I would appreciate any sample wording, links to examples, or other
> thoughts or ideas.
>
> Thanks.
>
> Wendy
>
> Wendy R. Mullin
> Web Developer
> University Technology Services
> University of South Carolina
> 1244 Blossom Street, Columbia, South Carolina 29208
> voice: 803-777-6785 | fax: 803-777-1900
> email: = EMAIL ADDRESS REMOVED =
>
>