[Athen] essential criteria across all products

[Sean Keegan]

> 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/24fc5cc5/attachment.html>