WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: good examples of javascript "roll over" menus with an accessible alternative

for

From: Paul Bohman
Date: Jul 29, 2005 5:00PM

First of all, I'd like to say that I don't use flyout menus anywhere,
and have no plans of using them on any of my sites. My discussion of
their merits is more for the sake of discussion and abstract principles
than for a call to use them. It's a discussion of ideas and
possibilities. I tend to think that we ought not tell developers "thou
shalt not use technology X" but rather challenge them to make technology
X accessible. I may not like technology X for certain reasons, but I
would much rather try to get developers excited about the accessibility
possibilities of their technologies instead of telling them "we don't
like your technology so don't even try to make it accessible." That's
the perspective I'm taking here. So with that said, my comments are
inline below.

Christian Heilmann wrote:

> Objection your honour. What this reasoning forgets to take into
> account is that a web site is not an own application but already
> resides inside another application - the browser - which has flyout
> navigations. If a screen reader is used then it also resides inside
> yet another application. (This is also the big problem with
> accesskey attributes - too many keyboard shortcuts are already taken
> up by the other applications.)

> ... a web site is not an application, it is connected content.

That's true, but only if the website is a content site rather than a
web-based application. But what if it *is* an application that happens
to be programmed in HTML, JavaScript, and CSS, with PHP or JSP on the
back end? Then it's an application embedded within an application (the
browser). 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.

There are content sites and there are web-based applications ... and
there are hybrids. As the web evolves, we'll see a greater blurring of
lines between content, applications, and browsers. Even now, you can
build an HTML-based application that brings in HTML content from other
websites. In other words, you can build a "browser" within a browser.
There are all sorts of possibilities both in the present and in the future.


> The question should never be "how can we make this accessible", the
> question is "how do users benefit from this navigation".

Very true. We always need to look at the usability of accessibility
solutions. Always. Nevertheless, as we do this, we should be careful not
to stifle creativity. That's the concern I'm voicing.


--
Paul Bohman
Director of Training Products and Services
WebAIM (Web Accessibility in Mind)
www.webaim.org
Utah State University
www.usu.edu