[Athen] Distilling WCAG Guidelines and 508 Criteria by Role

[Zirkle, Kara]

I've found it very receptive of individuals when accessibility is broken
down by role and responsibility.  That way its easily seen how everyone
plays a part in it and how it could easily fall apart if not everyone is on
board.  Its puzzle pieces that you're putting together hoping not to lose
one along the way.

As for the procedures around procurement, this is a huge struggle due to
all of the various ways to purchase.  The roles and responsibilities can be
broken down even further within this area.

Are you an individual who submits items to procurement, do you know to ask
the vendor up front for a VPAT?

Are you a P-Card user, do you know the responsibilities you have allowing
use of that card and is accessibility a part of that training?

Do you have contract language, a set of questions for RFPs, etc. Are you
working with legal counsel and procurement offices to get these things
standardized?

If you're a reviewer of purchase requests, do you have your own internal
procedure written out?  Is there a risk or priority matrix?  It is helpful
to create this when having various and sometimes overwhelming requests come
in.  That way you can run it through your rubric to determine the risk and
priority and determine whether it gets pushed to the front or the back of
the review line. Reality is we can't do it all, we will never catch
everything and we can simply do the best we can with the resource we have.
So training, education and standard procedures are your best tools to use.

Would be happy to chat in more detail, since accessibility procurement is
about 75% of what I do.

Regards,

Kara

Kara Zirkle
Accessible Technology Specialist
Information Technology Services
Hoyt Hall, 312V
Oxford, OH 45056
Phone: 513-529-9006
Email: zirklek at miamioh.edu
Twitter: @AccessMU

On Thu, Apr 20, 2017 at 2:23 PM, Mary Heid <mheid at unr.edu> wrote:


> 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.

>

>

>

> Thanks!

>

>

>

> 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

>

>

>

> _______________________________________________

> athen-list mailing list

> athen-list at mailman13.u.washington.edu

> http://mailman13.u.washington.edu/mailman/listinfo/athen-list

>

>

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