[Athen] Distilling WCAG Guidelines and 508 Criteria by Role

Mary Heid mheid at unr.edu
Thu Apr 20 11:23:36 PDT 2017

As our Information and Communication Technology (ICT) and Procurement policies are taking hold here at the University, I’m finding I need to develop a process to distribute the responsibility for accessibility assurance.

We have a small team (me and a graduate assistant) who “review software for accessibility.” Since we haven’t empowered anyone else to evaluate ICT for accessibility, we get requests to review all sorts of things including an enterprise document management system, a web-based survey someone has created to send to our residential students, an email blast to faculty in the form of a flyer with no alt text, to streaming our commencement ceremony. Obviously this is not sustainable.

I was just reading the WAI Easy Checks – A First Review of Web Accessibility<https://www.w3.org/WAI/eval/preliminary> page and am considering publishing some more targeted form of it for my internal University colleagues so they can run a preliminary check of web content and functionality or require the same of their prospective vendors. This would ideally leave the resources of my small team to concentrate on high impact products, training others to evaluate for their departments or divisions, and conducting random audits.

I’m open to others’ suggestions about how you have successfully distributed this responsibility for accessibility ‘compliance’ at the procurement stage.


Mary Heid
Enrollment Services
System Administrator and Coordinator of Assistive Technology
University of Nevada, Reno
(775) 682-8038

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,

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

More information about the athen-list mailing list