E-mail List Archives

Search E-mail List Archives for

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

From: Peter Shikli
Date: Wed, Jan 23 2019 9:05PM
Subject: RFP Boilerplate for Accessibility
No previous message | Next message →

Coming our way was yet another case of an agency paying for a website
that turned out to be inaccessible.  The audit and remediation business
is good, but I have to empathize with the procurement folks catching
management wrath.

Like many RFPs, theirs left it to the vendor to claim that they were
accessible, and nothing more.  Since interpretation of standards like
WCAG can be subjective, particularly for procurement folks untrained in
the subject, and the vendor can always later claim an accessibility
complaint was caused by staff content -- or that the website was
accessible when they delivered but no longer.  Lots of easy wiggle room.

I googled around looking for website procurement instructions to avoid
this all too common outcome, something accessibility professionals
helped write, something that could be added to RFP boilerplate.  I found
nothing.  Has anyone ever heard of something like that?

Cheers,
Peter Shikli
Access2online
A Division of Bizware Online Applications, Inc.
29030 SW Town Center Loop East
Suite 202-187
Wilsonville, OR 97070
503-570-6831 - = EMAIL ADDRESS REMOVED =
Cell: 949-677-3705
FAX: 503-582-8337
www.access2online.com
Prison inmates helping websites become accessible

From: L Snider
Date: Wed, Jan 23 2019 9:24PM
Subject: Re: RFP Boilerplate for Accessibility
← Previous message | Next message →

Hi Peter,
For Mandate 376 in Europe they put together this tool for government
procurement:
http://mandate376.standards.eu/procurement-stages/writing-a-call-for-tenders/wizard/technical-requirements/

There are others I have found, but don't have them on my backup computer.

Cheers

Lisa

On Wed, Jan 23, 2019 at 10:15 PM Peter Shikli < = EMAIL ADDRESS REMOVED = > wrote:

> Coming our way was yet another case of an agency paying for a website
> that turned out to be inaccessible. The audit and remediation business
> is good, but I have to empathize with the procurement folks catching
> management wrath.
>
> Like many RFPs, theirs left it to the vendor to claim that they were
> accessible, and nothing more. Since interpretation of standards like
> WCAG can be subjective, particularly for procurement folks untrained in
> the subject, and the vendor can always later claim an accessibility
> complaint was caused by staff content -- or that the website was
> accessible when they delivered but no longer. Lots of easy wiggle room.
>
> I googled around looking for website procurement instructions to avoid
> this all too common outcome, something accessibility professionals
> helped write, something that could be added to RFP boilerplate. I found
> nothing. Has anyone ever heard of something like that?
>
> Cheers,
> Peter Shikli
> Access2online
> A Division of Bizware Online Applications, Inc.
> 29030 SW Town Center Loop East
> Suite 202-187
> Wilsonville, OR 97070
> 503-570-6831 - = EMAIL ADDRESS REMOVED =
> Cell: 949-677-3705
> FAX: 503-582-8337
> www.access2online.com
> Prison inmates helping websites become accessible
>
> > > > >

From: Ryan E. Benson
Date: Wed, Jan 23 2019 9:30PM
Subject: Re: RFP Boilerplate for Accessibility
← Previous message | Next message →

I have experience with the other side of the isle. Unless the COR calls my
team in to help with the selection process, most of the people are left in
the dark. From the perspective of replying to an RFP, generally speaking
you should outline what you can do and what you can't. When I see vendor
proposals, I have seen people who essentially can't spell 508 (or
accessibility), to providing 15 pages of fluff, to their approach to making
something accessible is to run some automated software, to know the basics,
to actually go beyond the letter of the law.

Honestly if I saw the same company state the exact same thing for two
different RFPs, I'd flag it as a caution to the internal review.

Ryan E. Benson


On Wed, Jan 23, 2019, 23:15 Peter Shikli < = EMAIL ADDRESS REMOVED = wrote:

> Coming our way was yet another case of an agency paying for a website
> that turned out to be inaccessible. The audit and remediation business
> is good, but I have to empathize with the procurement folks catching
> management wrath.
>
> Like many RFPs, theirs left it to the vendor to claim that they were
> accessible, and nothing more. Since interpretation of standards like
> WCAG can be subjective, particularly for procurement folks untrained in
> the subject, and the vendor can always later claim an accessibility
> complaint was caused by staff content -- or that the website was
> accessible when they delivered but no longer. Lots of easy wiggle room.
>
> I googled around looking for website procurement instructions to avoid
> this all too common outcome, something accessibility professionals
> helped write, something that could be added to RFP boilerplate. I found
> nothing. Has anyone ever heard of something like that?
>
> Cheers,
> Peter Shikli
> Access2online
> A Division of Bizware Online Applications, Inc.
> 29030 SW Town Center Loop East
> Suite 202-187
> Wilsonville, OR 97070
> 503-570-6831 - = EMAIL ADDRESS REMOVED =
> Cell: 949-677-3705
> FAX: 503-582-8337
> www.access2online.com
> Prison inmates helping websites become accessible
>
> > > > >

From: Peter Shikli
Date: Mon, Jan 28 2019 8:37AM
Subject: Re: RFP Boilerplate for Accessibility
← Previous message | Next message →

As much as I did get some useful tips when I posted my previous request
for boilerplate to paste into RFPs to insure the delivery of accessible
websites and online applications, most of the responses were about the
VPATs and other technical criteria to audit the RFP's deliverable.  The
problem is that few agencies have procurement staff who have the
experience to make the relevant judgement calls.

What I was looking for was to parallel what they do for security when
there's a website RFP, that is, to define the security audit that must
be passed as part of acceptance testing.  The buyer can use an outside
service or their own IT group for the security audit if they have the
experience and availability.  Not finding that boilerplate for
accessibility anywhere, we've put a first draft at
www.access2online.com/support/accessiblerfps.html

I would like to invite the accessibility community to comment on that
boilerplate to make it as logical, accurate, and useful as possible. 
Then I plan to present that to the procurement community through our
client for their feedback.

My goal is to post a reusable boilerplate everyone is free to paste from
that page into their RFPs, something polished and practical to increase
the odds that websites and online applications are purchased with
accessibility in mind as the WebAIM logo says.

Cheers,
Peter Shikli
Access2online
A Division of Bizware Online Applications, Inc.
29030 SW Town Center Loop East
Suite 202-187
Wilsonville, OR 97070
503-570-6831 - = EMAIL ADDRESS REMOVED =
Cell: 949-677-3705
FAX: 503-582-8337
www.access2online.com
Prison inmates helping websites become accessible

From: Jiatyan Chen
Date: Mon, Jan 28 2019 9:09AM
Subject: Re: RFP Boilerplate for Accessibility
← Previous message | Next message →

Hi Peter,

Great start. My suggestions:

Remove 2y experience requirement for the auditor.

Limit the scope to the applicable functions of the app (rather than the entire app).

The audit has to be done BEFORE the contract award.

--
Jiatyan Chen

From: glen walker
Date: Mon, Jan 28 2019 10:41AM
Subject: Re: RFP Boilerplate for Accessibility
← Previous message | Next message →

>
> Remove 2y experience requirement for the auditor.
>

I'm curious why you would want to remove that requirement? Does that mean
you'd be comfortable with an auditor that's only worked in the area for a
few months?

Or should the "requirement" be changed to a "recommendation"? So maybe
changing "auditors with at least 2 years experience" to "prefer auditors
with at least 2 years experience".

Limit the scope to the applicable functions of the app (rather than the
> entire app).
>

Not sure I follow that. The entire app needs to be accessible.

The audit has to be done BEFORE the contract award.
>

How would that work? I thought the language in the RFP was to decide who
to award the contract to. Once the contract is awarded, then the
application is built, then it's tested. How could you audit something that
hasn't been written yet?

I like the language that the auditor can be involved in the whole
development process, especially the design end before any code is written,
but those skills might be beyond some auditor's skillsets. That is, some
auditors might be proficient in finding problems in existing apps but might
not be experienced in helping with design.

Glen

From: Ryan E. Benson
Date: Tue, Jan 29 2019 6:28AM
Subject: Re: RFP Boilerplate for Accessibility
← Previous message | Next message →

HHS has two sets on language that goes into acquisitions, which are found
at
https://www.hhs.gov/grants/contracts/contract-policies-regulations/hhsar/part-339-acquisition-information-technology/index.html#339.203-70.
The GSA, VA, and other agencies have language too, I believe.

The problem with your language is everything is applicable to the ADA AND
508, so tying those together may have issues for some applications. The US
federal government only has to meet WCAG 2.0 at this time, though 2.1 is
encouraged.

Finally, it is encouraged to put the applicable standards into acquisitions
(https://www.section508.gov/buy), and this language does not have a place
for that.
--
Ryan E. Benson


On Mon, Jan 28, 2019 at 10:47 AM Peter Shikli < = EMAIL ADDRESS REMOVED = > wrote:

> As much as I did get some useful tips when I posted my previous request
> for boilerplate to paste into RFPs to insure the delivery of accessible
> websites and online applications, most of the responses were about the
> VPATs and other technical criteria to audit the RFP's deliverable. The
> problem is that few agencies have procurement staff who have the
> experience to make the relevant judgement calls.
>
> What I was looking for was to parallel what they do for security when
> there's a website RFP, that is, to define the security audit that must
> be passed as part of acceptance testing. The buyer can use an outside
> service or their own IT group for the security audit if they have the
> experience and availability. Not finding that boilerplate for
> accessibility anywhere, we've put a first draft at
> www.access2online.com/support/accessiblerfps.html
>
> I would like to invite the accessibility community to comment on that
> boilerplate to make it as logical, accurate, and useful as possible.
> Then I plan to present that to the procurement community through our
> client for their feedback.
>
> My goal is to post a reusable boilerplate everyone is free to paste from
> that page into their RFPs, something polished and practical to increase
> the odds that websites and online applications are purchased with
> accessibility in mind as the WebAIM logo says.
>
> Cheers,
> Peter Shikli
> Access2online
> A Division of Bizware Online Applications, Inc.
> 29030 SW Town Center Loop East
> Suite 202-187
> Wilsonville, OR 97070
> 503-570-6831 - = EMAIL ADDRESS REMOVED =
> Cell: 949-677-3705
> FAX: 503-582-8337
> www.access2online.com
> Prison inmates helping websites become accessible
>
> > > > >

From: Ryan E. Benson
Date: Tue, Jan 29 2019 6:36AM
Subject: Re: RFP Boilerplate for Accessibility
← Previous message | Next message →

>How would that work? I thought the language in the RFP was to decide who
to award the contract to. Once the contract is awarded, then the
application is built, then it's tested. How could you audit something that
hasn't been written yet?

Not sure what approach they were taking, though if they mean before award,
make respondents speak about their accessibility knowledge or demonstrate
it as part of their submission package. If they meant before award, as in
before getting paid, have somebody check the deliverable for accessibility.
HHS' language closes with

(d) Respondents to this solicitation must identify any exception to Section
508 requirements. If a offeror claims its supplies or services meet
applicable Section 508 accessibility standards, and it is later determined
by the Government, i.e., after award of a contract or order, that supplies
or services delivered do not conform to the described accessibility
standards, remediation of the supplies or services to the level of
conformance specified in the contract will be the responsibility of the
Contractor at its expense.

--
Ryan E. Benson


On Mon, Jan 28, 2019 at 12:41 PM glen walker < = EMAIL ADDRESS REMOVED = > wrote:

> >
> > Remove 2y experience requirement for the auditor.
> >
>
> I'm curious why you would want to remove that requirement? Does that mean
> you'd be comfortable with an auditor that's only worked in the area for a
> few months?
>
> Or should the "requirement" be changed to a "recommendation"? So maybe
> changing "auditors with at least 2 years experience" to "prefer auditors
> with at least 2 years experience".
>
> Limit the scope to the applicable functions of the app (rather than the
> > entire app).
> >
>
> Not sure I follow that. The entire app needs to be accessible.
>
> The audit has to be done BEFORE the contract award.
> >
>
> How would that work? I thought the language in the RFP was to decide who
> to award the contract to. Once the contract is awarded, then the
> application is built, then it's tested. How could you audit something that
> hasn't been written yet?
>
> I like the language that the auditor can be involved in the whole
> development process, especially the design end before any code is written,
> but those skills might be beyond some auditor's skillsets. That is, some
> auditors might be proficient in finding problems in existing apps but might
> not be experienced in helping with design.
>
> Glen
> > > > >

From: Jiatyan Chen
Date: Tue, Jan 29 2019 10:59AM
Subject: Re: RFP Boilerplate for Accessibility
← Previous message | No next message

Glen,

I apologise for only thinking about my use cases -- we mostly buy off-the-shelf products. Perhaps the language of the boilerplate needs to specify that it is RFP for new software development.

> On 28 Jan 2019, at 09:41, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Remove 2y experience requirement for the auditor.
>
> I'm curious why you would want to remove that requirement? Does that mean
> you'd be comfortable with an auditor that's only worked in the area for a
> few months?

I choose to trust a professional certification. What does an additional 2y get me? Why create a barrier to entry for newly certified professional? Does it count if they just sit on their certificate for 2y? I don't have good reason not to trust them, and thus can't make a 2y experience a requirement.

>> Limit the scope to the applicable functions of the app (rather than the entire app).
>>
> Not sure I follow that. The entire app needs to be accessible.

Products like SalesForce or PeopleSoft or WordPress comes with lots of parts and plug-ins, lots of which we do NOT use. There is no purpose in scoping the entire product when we only need 10%.

> The audit has to be done BEFORE the contract award.

Ok, so thinking only about software development work, the language to integrate accessibility validation into the design & development process looks idealist for a development contract. The suggested structure is too rigid for the template to gain wide adoption. I anticipate several problems during execution.
(1) It might be a lot of pro-bono work up-front for the auditor. Are we sure we can find auditors who can serve as a help desk for free? And why would the Agency pay for the auditor?
(2) The language seems inflexible regarding the time and appointment of an auditor. The auditor might not be identifiable by the start of the contract. What if the auditor changes?
(3) Why force the vendor to work with the Agency's auditor if they have perfectly good ones themselves. As long as the vendor can proof that they have a reasonable process and good practices in place, the audit can be separate from the development. It might also be perfectly fine for the vendor to provide proof of acceptance testing.

Lastly, as an agency, I would want some contractual language about post-delivery work to ensure compliance.

--
Jiatyan Chen