E-mail List Archives
Re: Accessible Applications
From: Cliff Tyllick
Date: May 13, 2008 10:20AM
- Next message: bj: "Re: Accessible Applications"
- Previous message: Kara Zirkle: "Re: Accessible Applications"
- Next message in Thread: bj: "Re: Accessible Applications"
- Previous message in Thread: Kara Zirkle: "Re: Accessible Applications"
- View all messages in this Thread
Darian points us to http://www.state.gov/m/irm/impact/52675.htm, where the State Department states that it requires VPATs of its vendors. Of course, the State Department's requirements have no direct impact on vendors in their business relationship with Kara's employer, GMU.
I find it interesting that this page fails validation and violates all versions of WCAG in a number of ways (it lacks meaningful text in links, for one; its headings are not coded as such, for another). No doubt every government agency has a lot of work to do in making its Web site accessible, but State might wish to address this page quickly if it wants to show that it's serious about requiring accessibility.
>>> "Darian Glover" < <EMAIL REMOVED> > 5/13/2008 8:07 AM >>>
Karl,
I cannot cite every Department's and Agency's procurement rules within the
Federal Government, mostly because government procurement is such a mess.
Here is one Department that does require VPATs:
http://www.state.gov/m/irm/impact/52675.htm
Darian.
On 5/12/08, Karl Groves < <EMAIL REMOVED> > wrote:
>
> That's quite a list you have, Kara.
> One step that may help you in finding what you seek is to look for a VPAT
> for these products. Contrary to Darian's response, VPATs are not
> mandatory
> (what is mandatory is that the FAR Part 10 requires market research, for
> which VPATs help.).
>
> The other thing about VPATs is that, in my experience, they're often
> inaccurate. I don't want to say that vendors lie on their VPATs (though
> they could) but that sometimes it seems like the person filling them out
> doesn't seem to understand 508 or that the version of the application
> currently in release is not the same as the version discussed in the VPAT.
> There seems to be a lot of reasons why a VPAT could be inaccurate. The
> bottom line is, be skeptical. In cases where a VPAT was supplied by a 3rd
> party, accuracy seems to increase (because those 3rd parties don't want to
> be grilled about inaccuracies).
>
> A VPAT is NOT a legal document and does not, in and of itself, prevent or
> permit any acquisition.
>
> > Also, has anyone contacted vendors directly asking for changes to be
> > made in response to accessibility if contract language wasn't
> > originally
> > in the picture
>
> In practice: Your chances are relatively slim and directly proportional to
> your purchasing power. For example, let's say GMU is purchasing something
> from Microsoft. The chance of them remediating something for GMU is
> nonexistent compared to the chance they'd do it for a major government
> agency such as IRS or SSA and, unless it is in the original contract is
> already slim-to-none. A contract is a contract and must clearly define
> the
> work to be performed, including adherence to any standards for
> accessibility. It would be like trying to take a car back to the
> dealership because it came with the wrong engine when you didn't tell the
> dealer which engine you wanted in the first place. The best you can do is
> learn from mistakes and make sure they're not made again.
>
>
>
> Karl Groves
> AIM/YIM: karlcore
> Skype: eight.pistons
> www.WebAccessStrategies.com
>
>
> >
- Next message: bj: "Re: Accessible Applications"
- Previous message: Kara Zirkle: "Re: Accessible Applications"
- Next message in Thread: bj: "Re: Accessible Applications"
- Previous message in Thread: Kara Zirkle: "Re: Accessible Applications"
- View all messages in this Thread