WebAIM - Web Accessibility In Mind

E-mail List Archives

RE: VPAT E-learning

for

From: Robinson, Norman B - Washington, DC
Date: Feb 23, 2006 6:00AM

Andrew,

My perspective is that if someone began describing software on
the computer and attributes and user interaction, I would begin by
asking if this falls under .21 (Software). If it then was revealed it is
web content, then the specifics of .22 (web) apply and because they are
more specific they are the technical requirements for that content type,
and legally if you meet those requirements you are in compliance.

Certainly, I am advocating a stronger tie between software and
web standards if the Access Board ever revises the standards. I think
the web was so new their wasn't enough experience to provide a better
perspective and see that web content is no different from C++ content or
Java content or VisualBasic content or XML content; that is a language,
whether interpreted or not that can display or interact.

The reason I bother with explaining this is that the web browser
itself falls under .21 (as software) however the web content doesn't
directly, but with various perceptions and multiple user agents that
aren't web browsers, one could argue the point. And, if you take the
fish out of water it has trouble breathing; asking a vendor what
browser/user-agent was required (reminds me of compatible-AT link in a
VPAT) for their application kind of sets up the conversation for
testing, timeouts, and how Software standards might apply...

But, beyond friendly discussion of the issues, I'd say you are
correct. LEGALLY Section 508 is constrained by how it is written.
Complex web applications fall under .22 (web) and unless they use
plug-ins or some other non-HTML technology (such as Java) then that is
the only standard that you can legally apply.

AJAX is not an exception. It generally falls under web
applications (barring embedded Java, plug-ins, etc.). Viewed as an
application, I could see how it might fail to meet the Section 508
software technical standards. Just as web technologies such as AJAX
change how web content is presented, I think the Section 508 standards
will have to change.

Until then, I can make arguments that existing web content
hasn't been judged strictly enough. Would an AJAX dialog box mocked up
to look like a system dialog box be an "electronic form"? Perhaps. Alt
text for those "system widgets" would be required. More importantly,
vendors should look forward to section (l) (When pages utilize scripting
languages to display content, or to create interface elements, the
information provided by the script shall be identified with functional
text that can be read by assistive technology) being used as a bigger
stick. AJAX relies on scripting to display content. It better be
available. The preamble to 508 mentions "if a web page uses a script to
create a graphic map of menu choices when the user moves the pointer
over an icon, the web site designer may be required to incorporate
"redundant text links" that match the menu choices because functional
text for each menu choice cannot be rendered to the assistive
technology". One could debate over "graphic map" vs. "visual map" but
I'd not hesitate to say they are one in the same in this discussion. I
also expect if I took the hard-line on requiring readability without
style sheets many AJAX applications would have to be modified. Finally,
I expect a passive-aggressive stance on (p; timeouts) would make a legal
requirement for notification of timeouts an issue with some AJAX
applications (e.g., Oh, you want to log out the user? Why? No activity?
They didn't know the page updated? Well you have to notify them first).
The human side of the story is asking a vendor "Do you want to spend
your time explaining why Section 508 doesn't apply or make your
application work for my users so I can buy it?"

The biggest issue is the update of the user display. This is
covered by .21 (Software) section (c; well-defined on-screen indication
of current focus) and (d; info about user interface elements, including
identity, operation, and state). However, The Access Board (responsible
for the technical standards) did not adopt WCAG 1.0 Checkpoint 6.2;
"[e]nsure that equivalents for dynamic content are updated when the
dynamic content changes." I think if they did, AJAX would be covered.

I can tell you that if my agency is building an application, not
taking the user interface update into account isn't acceptable. It won't
pass my review - it is bad coding! I have no problem with stating an
application might be Section 508 compliant if it technically complies. I
also have no problem stating to a Vendor if their solution doesn't take
into account use by assistive technology, isn't accessible because they
didn't test for a that use-case, then it lacks quality and is bad for
our users. Next product please.

Failing that and having business justifications for purchase of
an AJAX type application (not developed but purchased COTS style) then I
guess users can refresh their web browsers and assistive technology to
get access. Is that legal? Probably. Could we do better? Definitely. Do
I expect some smart AJAX programmer can devise a way to refresh the web
browser such that screen readers automatically read because of changes?
Yes. Hope it happens soon so we can set that as a minimum requirement
for AJAX-style technology.

Regards,

Norman B. Robinson