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


-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Andrew
Kirkpatrick
Sent: Wednesday, February 22, 2006 8:42 AM
To: WebAIM Discussion List
Subject: RE: [WebAIM] VPAT E-learning


Norman,
I'll agree that there is a high degree of overlap between 22 and 21, but
not that 22 is a subset, since there are things in 22 that are not in 21
(e.g. 22o [skip repetitive links] and 22b [synch multimedia
equivalents]).

What I'm concerned about is the desire to view interactive web
applications as needing to adhere to the 21 standards because there are
shortcomings in the 22 standards for these types of apps. I absolutely
agree that the sentiment is correct in that a complex web application
should be accessible beyond what is directly mandated in subpart 22, but
when considering 508 compliance it is important to adhere to the
categories that are provided for in the law even if you consider them
inadequate.

AWK



> -----Original Message-----
> From: <EMAIL REMOVED>
> [mailto: <EMAIL REMOVED> ] On Behalf Of
> Robinson, Norman B - Washington, DC
> Sent: Wednesday, February 22, 2006 8:23 AM
> To: WebAIM Discussion List
> Subject: RE: [WebAIM] VPAT E-learning
>
> Andrew,
>
> Conceptually 1194.22 (web-based intranet and internet)
> standards are a subset of 1194.21 (software and operating
> systems). The specific web standards were an attempt to be
> more specific in what technical standards were required to
> provide access. Note that for some content
> (plugins) the web content references back to the more
> 'generic' software standards
> (http://www.usps.com/cpim/ftp/hand/as508a/508a_c6.html#508hdr69).
> Legally, I think if you can prove you meet the 1194.22 for
> web content then you've met the more specific standards.
> There is discussion in the Section 508 preamble that goes
> into the rationale if anyone is
> interested: http://www.access-board.gov/sec508/preamble.htm.
>
> Regards,
>
>
> Norman B. Robinson
>
> -----Original Message-----
> From: <EMAIL REMOVED>
> [mailto: <EMAIL REMOVED> ] On Behalf Of
> Andrew Kirkpatrick
> Sent: Tuesday, February 21, 2006 3:20 PM
> To: WebAIM Discussion List
> Subject: RE: [WebAIM] VPAT E-learning
>
>
> > You would include provisions from 1194.21(a-l) only for "software"
> > that might include Java. Interactive elements would not require
> > 1194.21 provisions as these are addressed by provisions
> from 1194.22.
> > you also probably would not need
> > 1194.24 provisions as 1194.22(b) generally addresses multimedia
> > content.
>
> 22a and 22b together do address the need for captions, but
> audio descriptions are not required unless .24 standards are
> addressed.
>
> What is not clear is whether it is being argued that 1194.21
> applies to websites with interactivity because the 11194.22
> standards are insufficient to address all of the issues that
> these types of site have and that should be dealt with, or if
> that is what the standards indicate should be done.
>
> The .22 standards are titled "Web-based Intranet and Internet
> Information and Applications" which would seem to include
> interactive web sites, including those using javascript to
> create this interactivity. 1194.22(l) addresses this point
> in its reference to scripting.
>
> I'm not saying that meeting the requirements of 1194.22 fully
> addresses the needs of all users, but that isn't the point
> here. Since we are dealing with a law, we need to be clear
> on what the law actually says instead of what we think it
> should say.
>
> AWK
>
>
>
>
>
>
>