RE: Web site accessibility

Stephanie Hagopian wrote:

> I work for a University and we are trying to update all our web sites so
> that they have full accessibility.

An admirable goal, and one we encourage and support you in (actually, I
should say I, but this list is very supportive too).  Do the "policy makers"
and decision takers understand what they are saying when they make that
statement?  Is the goal one of convenience, marketing, or sincerity (or a
combination of all 3).  With no offence, making a statement is a good start,
but has a desired outcome been completely and thoroughly discussed, decided
upon and agreed to?  Have the appropriate people involved in the decision
making process been appraised of the full ramifications of setting out on
this task?  Are they prepared to give up "pet projects" or specific "views"
(or visions) of how it's *supposed* to be/look/act?  Have they determined a
"measurable" level of compliancy (be it Section 508, or W3C Priority 1,
Priority 2, or Priority 3)?  Have they thought about how they plan to
monitor and ensure compliancy now, and in the future?  These are tough
questions, and the answers aren't any easier.

> Does anyone know of any good
> libraries online that explicitly and clearly list what Javascript is
> fully compliant with accessibility web standards and what script is not
> suitable?

The W3C Web Content Accessibility Guide is a great starting place
(http://www.w3.org/TR/WCAG10/), or start with the Prioritized Checklist
(http://www.w3.org/TR/WCAG10/full-checklist.html)

One of the Priority One checkpoints is Number 6.3, which states:
"Ensure that pages are usable when scripts, applets, or other programmatic
objects are turned off or not supported. If this is not possible, provide
equivalent information on an alternative accessible page."

Now, depending on how you read and interpret that statement will help you to
determine whether the JavaScript you are using is "Accessible" or not.  If
you are using JS to create "eye-candy" effects such as "rollover" images or
writing to the document location bar, well, shouldn't be a real problem,
because if a user is using a browser which does not support JS, they won't
see the rollover or what have you, but they can still get to the heart of
the page; it's content or function.  On the other hand, if you are using JS
to provide what I call a "Mission Critical" function (say perhaps to write
out your navigation or provide a search functionality) then IMHO you are
crossing the line.  What happens when a browser that does not support JS
hits that page?  They cannot navigate or search?  That's a serious
Accessibility issue! But even then, all is not lost, because, depending on
what you are doing with the JS, you can also develop a fallback position
which degrades nicely; whether it's the "Return False;" declaration in your
event or the use of the <noscript> block to provide the alternate content.

Thus, it's not so much that there is a library of canned "approved" scripts
which one can download and use, but rather the philosophy behind the usage
of the script(s).  I would suggest that if it is simply for GUI tricks, have
a party.  But if it contributes any real functionality to the page or site,
then it MUST be a server side scripting language to ensure universal
accessibility.

Stephanie, as you move through this process, do not hesitate to turn to this
list with your questions or concerns... there are a number of talented,
concerned and informed people who will try their hardest to help you with
your questions.

Good Luck

JF

Received on Tuesday, 25 March 2003 10:40:44 UTC