WebAIM - Web Accessibility In Mind

E-mail List Archives

Web Content vs Web Application (was RE: good examples of javascript "roll over" menus with an accessible alternative)

for

From: John Foliot - WATS.ca
Date: Jul 30, 2005 8:27AM


Christian Heilmann wrote:
>
> Let us not forget though that skip links are a worst case scenario. If
> your navigation is not the first thing the visitor gets on every page
> of the site, but at the end of the document - which is easily possible
> with CSS then there is no need for skip links. They are only needed
> to, well, skip repeating elements.

Uhm... Carefull here. If you have a document with your nav block coded
at the end (and positioned with CSS), then you should very seriously
have a link that "skips to" your navigation.... Otherwise all user
agents that deal with your content in a linear fashion will require
users to read each page in it's entirity before getting to the
navigation - an equally vexing and inaccessible scenario.

Regardless of where you actully insert your nav block code, developers
should provide a means to quickly access it, or bypass it. This is
consistant with WCAG Priorities:
P2 - 12.3 Divide large blocks of information into more
manageable groups where natural and appropriate.
P2 - 13.4 Use navigation mechanisms in a consistent manner.
P3 - 13.6 Group related links, identify the group (for user
agents), and, until user agents do so, provide a way to bypass the
group.


Meanwhile, elsewhere in this thread, Paul Bohman wrote:
>
> Even beyond this, not all web-based content is accessed
> through the standard browser either. Think of media players. Think of
> Java applets with embedded web content. Think of Microsoft .net
> applications.

Paul, think of the following WCAG Priorities <grin>:

P2 - 11.1 Use W3C technologies when they are available and appropriate
for a task and use the latest versions when supported.
P2 - 8.1 Make programmatic elements such as scripts and applets
directly accessible or compatible with assistive technologies [Priority
1 if functionality is important and not presented elsewhere, otherwise
Priority 2.]
P2 - 9.2 Ensure that any element that has its own interface can be
operated in a device-independent manner.


Paul, I too get excited about the possiblities of what the web can
offer, but at the same time I temper it with the realities of what the
web *should* offer. To my mind, when we discuss web accessibility, we
are talking primarily about access to information - and ensuring that
all citizens have equal access to that information. We also have a
level of interactivity provided via form inputs and controls, and the
ability to have "two-way" communication between user and content
creator/owner. But it also reaches a point when what is being dreampt
up is no longer web content, but rather related technologies being
leveraged into a new format. In other words, we've all seen the wacky
dreams of cars that could swim, or cars that could fly, but ultimately
we've left those tasks to boats and planes... Both tranportation
vehicles but neither cars...

That there is a need for a global commitment to ensuring that all
technologies remain accessible to all users (the ideal), there is also a
need to be realistic when we talk about "web content". There reaches a
point when we must all concur that it is no longer web content, but
rather a tool delivered via the linked network (the internet). The
question then becomes, should these tools be covered by the Web Content
Guidelines (standards) we generally assign to web pages? I would
suggest no...

Three years ago, I met with a Government Department who had spent 18
months converting a C+ application that had been installed on agents
systems into a "web-based" application that provided exactly the same
functionality - with the intent of deploying it via their intranet. But
to do that, they broke about 10 "rules" as far as WCAG is concerned -
including exclusive reliance on JavaScript, removing all navigational
chrome from their pop-up window/application, removal of all navigational
controls, etc. etc. The sad thing is, the original C+ application
worked just fine, but somewhere deep within the catacombs of our
government, somebody figured that converting it to "the web" was modern
and forward thinking, and so a budget was created, contractors were
employed and development began. The end result was horrible, at least
from an accessibility perspective.

I believe that the W3C has also reached a similar position. That is why
they have also created the User Agent Accessibility Guidelines. These
are separate and distinct accessibility rules (OK, guidelines) which
address the issues that may arise when developing your media players,
.NET applications and java applets / embedded content. I question out
loud - how many of the list readers have reviewed this document?
(Checklist:
http://www.w3.org/TR/2002/REC-UAAG10-20021217/uaag10-chktable)

Since this thread is obstensibly about "Fly-out" menus, I wondered about
whether the UAAG applied to this "functionality". Within the checklist
are these items:

Priority 1:
1.1 - 1. Ensure that the user can operate, through keyboard input alone,
any user agent functionality available through the user interface.

1.2 - 1. Allow the user to activate, through keyboard input alone, all
input device event handlers that are explicitly associated with the
element designated by the content focus.
- 2. In order to satisfy provision one of this checkpoint, the user
must be able to activate as a group all event handlers of the same input
device event type. For example, if there are 10 handlers associated with
the onmousedown event type, the user must be able to activate the entire
group of 10 through keyboard input alone, and must not be required to
activate each handler separately.

6.7 - 1. Implement APIs for the keyboard as follows:
* Follow operating environment conventions.
* If no conventions exist, implement publicly documented
APIs.

Priority 2:
7.3 - 1. Follow operating environment conventions that benefit
accessibility. In particular, follow conventions that benefit
accessibility for user interface design, keyboard configuration, product
installation, and documentation.

8.2 - 1. Use and conform to either:

* W3C Recommendations when they are available and appropriate for a
task, or
* non-W3C specifications that enable the creation of content that
conforms at level A or better to the Web Content Accessibility
Guidelines 1.0

9.9 - 1. Allow the user to navigate efficiently to and among important
structural elements in rendered content.
- 2. As part of satisfying provision one of this checkpoint, allow
forward and backward sequential navigation.

There is lots to think about here... Perhaps more than an email posting
can cover reasonably. But I encourage everyone to think about these
points too... For within them lies, if not the answer, at least the
path. Paul (and others), I'm not against *anything* - I just want to
ensure that whatever we do, we include everyone - 'cause isn't that what
it's all about?

Cheers!

JF
--
John Foliot <EMAIL REMOVED>
Web Accessibility Specialist / Co-founder of WATS.ca
Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053