[Athen] essential criteria across all products

[Mary Heid]

I’m also currently considering how to word our contract and RFP language.  I expect to keep it short, simple, and powerful and agree with Sean’s sentiment that the “essentials” are already defined in the standards and guidelines.

I plan something along the lines of, “Vendor certifies that all Information and Communication Technology products and services are 508 (with a link) and/or WCAG (with a link) compliant and conform to our University Accessibility Policy and Standards (with a link.)” I also expect some legalese about indemnity (which I imagine will often be stricken.)

That University Accessibility Policy and Standards document linked in the contract language is where we define our current conformance level as 2.0 AA, 508, PDF/UA, and the regulations of ADA, Sec 504, Sec 255, CVAA, ATAG, UAAG.  Those will change periodically and this way we don’t need to change our contract language as standards and guidelines change.

I vacillate between adding caveats for equally effective alternative access, undue burden and fundamental alteration to the contract or not, but Sean makes a good point that those are more appropriately included in the procurement process.

That said, I start a new thread about the concept of distilling WCAG and 508 by internal audience.

Mary Heid
Enrollment Services
System Administrator and Coordinator of Assistive Technology
University of Nevada, Reno
(775) 682-8038
http://www.unr.edu/general-information/accessibility

From: athen-list [mailto:athen-list-bounces at mailman13.u.washington.edu] On Behalf Of Sean Keegan
Sent: Thursday, April 20, 2017 9:26 AM
To: Access Technology Higher Education Network <athen-list at u.washington.edu>
Subject: Re: [Athen] essential criteria across all products


> Have you identified accessibility criteria that is essential across all products?

> Something like “accessible via keyboard alone” or “images have alt text”. I’m trying to find items in 508/WCAG AA

>  that are absolutely essential across the board. We’d like to mandate these criteria in RFP.


I understand why you are attempting to do this, but I urge caution. Both the refreshed 508 standards and WCAG 2.0, Level AA has done exactly what you ask in identifying accessibility criteria that is essential across information and communication technology products. These are technology standards and as a whole define the requirements that are essential. They are not intended to provide a menu where you choose something from column A, something from column B, etc.

Viewing this in a different light, this would be like having informations security standards, but then only choosing to select specific information security requirements to meet. Does this make your IT environment more or less secure? What would you define as essential for information security (e.g., products must protect against viruses, but spyware is okay?)?

I completely understand a desire to reword some of these accessibility criteria such that they make sense to someone who may not have a background or expertise in accessibility standards. And I fully comprehend a need to refine these accessibility criteria in such a way that make the most sense for different higher education audiences (e.g., faculty, administration, etc.) depending on their institutional roles and responsibilities. Crafting language and organizing information in such a manner that people can achieve accessibility expectations appropriate to their role makes complete sense.

However, for RFP situations, I think you are putting yourself at greater risk by not insisting that vendors meet established and recognized accessibility standards. WCAG 2.0, Level AA (or the refreshed 508 standard) defines the essential accessibility criteria and that should be the expectation as part of any RFP. By deciding what does or does not constitute "essential" results in creating yet another accessibility standard that is only relevant and specific to your institution only AND runs a greater risk of

Now, there may be situations in which there is no commercially available product that meets that standard or that in order to meet that accessibility standard the product would require a fundamental alteration. That is a legitimate argument and can be best addressed by defining a procurement/acquisition process in which such issues are addressed. There is a need to resolve the imbalance between an organization's functional business requirements, the products that exist currently in the marketplace, and accessibility. That needs to be addressed at a process level and not by creating a separate set of accessibility criteria.

Lastly, I want to mention that a presenter at CSUN (who is highly literate in both WCAG and 508) identified four "show-stoppers" as it related to accessibility such that if these are failures, then very few individuals with disabilities would be able to participate. They are not what most people first think (these are all WCAG 2.0 success criteria):
- 1.4.2: Audio Control on web page (must NOT allow automatic playing of sounds as this can over-ride a screen-reader)
- 2.1.2: No Keyboard Trap (a keyboard user can't interact)
- 2.2.2: Pause, Stop, Hide for moving, blinking, etc., content (this provides user control over content, for example if seizures are concern)
- 2.3.1: Three Flashes or Below Threshold  (to prevent seizures)

While the above may have broad impact on individuals with disabilities, does this mean that these are the essential criteria? What about captions? What about image descriptions? etc.

My point is that we already do have accessibility standard with criteria that has been established and we must be cautious if we attempt to distill such content down into something "easier." I understand why you may be pursuing this approach, but I urge caution, particularly as the original question indicated mandates related to RFP processes.


Take care,
Sean

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman12.u.washington.edu/pipermail/athen-list/attachments/20170420/cb070da6/attachment.html>