RE: WCAG and "undue hardship"

aloha, greg!

the purpose in promulgating the guidelines is not to provide guidance to 
regulatory bodies, but to define and explain, to the greatest extent 
possible, to the widest possible audience, the concepts of accessible 
design and to provide guidance for web content creators so that they are 
able to provide accessible content, in the absence of tools that 
automagically produce accessible markup wherever it is possible to do so...

what use (for good or ill) third parties make of the WAI suite of 
guidelines is beyond the WAI's purview, and out of its control...  what is 
in the WAI's control is:

- ensuring that the information contained in WCAG is as accurate and 
up-to-date as possible
- ensuring that the document can be used by the widest possible variety of 
audiences for the widest possible variety of uses
- ensuring that, when content is created in accordance to WCAG, it serves 
its purpose, by being as accessible to the widest possible audience as possible

yes, regulatory bodies will look to the WAI guidelines for (for lack of a 
better term) guidance in drawing up regulations and purchasing 
requirements, but that is not the function of the WAI guidelines...  the 
function of the WAI guidelines is to ensure that persons with disabilities 
enjoy equal read/write access to the web

wherein lies the undue hardship?  not on the developers who should have 
adhered to standards, but on the end user who can't use the 
software...  ignorance is never an excuse, but wanton disregard, once 
inaccessibility has been identified, is inexcusable...

so, your developers have a simple choice: 1) scrap it and start over, 
adhering to industry standards for the platforms for which the product is 
being developed, 2) retrofit the product (which inevitably leads to 
half-assed access), or 3) continue on with the current development cycle 
and face a class action suit by those who cannot participate in distance 
learning because the software is inaccessible....

all JavaScript has a function -- if you can explain the functionality of 
the JavaScript, what is preventing you from adding functional equivalents 
for the functions the JavaScript is being used to provide?

and don't downplay the intersection of usability, interoperability, 
internationalization, and accessibility -- while the laws of some countries 
may state that equal access must be provided for persons with disabilities, 
market forces demand that equal access must be provided for persons not 
using a desktop computer, a monitor, and a mouse to access the web...  the 
solutions advanced for accessibility can equally be advanced for 
interoperability and -- especially -- internationalization...  wouldn't 
potential clients be better off, then, with an interoperable product that 
works equally well for those using adaptive technology, those using mobile 
devices, and those for whom the distance in distance learning isn't merely 
geographical or cultural, but technological as well?

when i worked as webmaster and technical director of online courses for a 
small college in new jersey, the college's administration and board of 
trustees were overjoyed to discover that, due to the interoperability of 
the pages that i had created for them, they had suddenly received a great 
many inquiries and registrants for their online courses from places as 
distant as the United Arab Emirates, mainland China, southeast Asia, and 
several African nations -- places where access to the internet, let alone 
the latest and greatest in hardware and software, is either extremely hard 
to secure, or which can only be achieved using javascript-incapable 
technology...

so, draw your own conclusions about the weight of the burden faced by your 
programmers -- but keep in mind the undue, and unnecessary, burdens you are 
placing upon thousands of users...

which is more of an "undue hardship" -- fixing the programmatic problems or 
having no autonomous access to online courseware?

gregory.

Received on Tuesday, 30 May 2000 23:13:38 UTC