E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 17 (In chronological order)

From: Jennifer Sutton
Date: Thu, Jul 28 2005 1:47PM
Subject: good examples of javascript "roll over" menus with an accessible alternative
No previous message | Next message →

Hello:

I'm working with a client who has committed to designing with CSS. This
has been a real struggle for them, so I'm trying to speed them along with
some examples that won't require them to sacrifice "look and feel," at
least as much as possible.

They want to have those javascript menus that show choices when the user
rolls over the main choice with a mouse.

Does anyone have good visually appealing examples that render in an
alternative fashion when javascript is turned off, when the keyboard is
used, and/or when a screen reader is used?

I was looking at what Google offers when searching on keywords such as
"accessible javascript menus," but the resulting articles didn't seem to be
terribly current.

Thanks for any links to sites or articles.Apologies, in advance, for
potential cross-posting

Best,
Jennifer

From: Don Hinshaw
Date: Thu, Jul 28 2005 1:57PM
Subject: Re: good examples of javascript "roll over" menus with an accessible alternative
← Previous message | Next message →

> They want to have those javascript menus that show choices when the
> user rolls over the main choice with a mouse.
>
> Does anyone have good visually appealing examples that render in an
> alternative fashion when javascript is turned off, when the keyboard
> is used, and/or when a screen reader is used?
>
Hi Jennifer,
I have used these menus from Project Seven:
http://www.projectseven.com/products/menusystems/pmm/index.htm
They are not free, but they are easy to implement, offer tech support,
and seem to meet all the criteria you cited above. I'm sure on this
topic you will get a gazillion different responses! Good luck.

Don

--
Don Hinshaw
Hinshaw Design Group
http://www.hinshawdesign.com

From: Glenda Watson Hyatt
Date: Thu, Jul 28 2005 2:03PM
Subject: RE: good examples of javascript "roll over" menus with an accessible alternative
← Previous message | Next message →

Why not simply use lists with css? My next time block of "free" time I'm
going to attempt this approach on my own site.

Cheers,
Glenda

Glenda Watson Hyatt, Principal
Soaring Eagle Communications
Accessible websites. Accessible content. Accessible solutions.
www.webaccessibility.biz

From: Christian Heilmann
Date: Thu, Jul 28 2005 2:09PM
Subject: Re: good examples of javascript "roll over" menus with an accessible alternative
← Previous message | Next message →

> I'm working with a client who has committed to designing with CSS. This
> has been a real struggle for them, so I'm trying to speed them along with
> some examples that won't require them to sacrifice "look and feel," at
> least as much as possible.
>
> They want to have those javascript menus that show choices when the user
> rolls over the main choice with a mouse.
>
> Does anyone have good visually appealing examples that render in an
> alternative fashion when javascript is turned off, when the keyboard is
> used, and/or when a screen reader is used?
>
> I was looking at what Google offers when searching on keywords such as
> "accessible javascript menus," but the resulting articles didn't seem to be
> terribly current.
>
> Thanks for any links to sites or articles.Apologies, in advance, for
> potential cross-posting

Check my YADM: http://www.onlinetools.org/tools/yadm/reldropdown.html

They are styled lists with CSS and JS is only used for the behaviour.
You can even define a style for non JavaScript and one for JavaScript
browsers. All menus work onclick and onmouseover, which also means
they are keyboard friendly.

The demo page is not the nicest, but back then all I wanted to offer
is the script. The CSS is your job.



--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/

From: Christian Heilmann
Date: Thu, Jul 28 2005 2:10PM
Subject: Re: good examples of javascript "roll over" menus with an accessible alternative
← Previous message | Next message →

> Why not simply use lists with css? My next time block of "free" time I'm
> going to attempt this approach on my own site.

CSS has no keyboard enabled state, unless you count focus which only
works in Opera AFAIR.

From: Jim Thatcher
Date: Thu, Jul 28 2005 3:28PM
Subject: RE: good examples of javascript "roll over" menus with anaccessible alternative
← Previous message | Next message →

Don Wrote:
> I have used these menus from Project Seven:
> http://www.projectseven.com/products/menusystems/pmm/index.htm

Probably I am missing something on these menus, but the fact that you can
get to all menu items with the keyboard may make them technically
accessible, but not practically accessible. I believe that the only way to
have JavaScript roll menus accessible is to have the main menu item active
so that the page it opens has all the submenu links immediate in the
navigation area of the page - like at http://nsf.gov. Actually the NSF menu
system is not the same kind of rollover menus we're talking about(anymore)
but the idea is the same. There's a screen shot of what they used to be at
http://jimthatcher.com/webcoursea.htm, figure 10.4.

Christian added:
> Check my YADM: http://www.onlinetools.org/tools/yadm/reldropdown.html

These have the same problem except on my machine I don't even see the
submenu items when using the keyboard.

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Christian Heilmann
Date: Thu, Jul 28 2005 3:41PM
Subject: Re: good examples of javascript "roll over" menus with anaccessible alternative
← Previous message | Next message →

> Christian added:
> > Check my YADM: http://www.onlinetools.org/tools/yadm/reldropdown.html
>
> These have the same problem except on my machine I don't even see the
> submenu items when using the keyboard.

True, however, if you add focus and blur you open a whole new can of
worms with browsers.
The very idea of dynamic dropdowns - hiding unneeded navigation whilst
providig it - is just not accessible, as hiding it does not make it
go away.

I listed most of the issues these navigations have here:
http://www.icant.co.uk/forreview/dynamicelements/

A really unobtrusive version of these dropdowns would load in the sub
levels onmouseover vi a AJAX, that way only providing the nice to
have links to those who have JS enabled and use a mouse. On the other
hand I am sure that you can simulate onmouseover with assistive
technology, too.

Therefore the only _real_ solution is to offer a basic navigation,
that only provides you with the main links and the current sub
section, and a "enhanced navigation" that the visitor can turn on if
she wants to.


--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/

From: Austin, Darrel
Date: Thu, Jul 28 2005 3:59PM
Subject: RE: good examples of javascript "roll over" menus with a naccessible alternative
← Previous message | Next message →

> Probably I am missing something on these menus, but the fact
> that you can get to all menu items with the keyboard may make
> them technically accessible, but not practically accessible.
> I believe that the only way to have JavaScript roll menus
> accessible is to have the main menu item active so that the
> page it opens has all the submenu links immediate in the
> navigation area of the page

This is an EXCELLENT point that is often overlooked.

All to often you see people 'of course our site is accessible...it adheres
to section 508' failing to realize that that is simply a technological
standard...not an actual test of the accessibility of your site by actual
people.

-Darrel

From: Don Hinshaw
Date: Thu, Jul 28 2005 6:33PM
Subject: Re: good examples of javascript "roll over" menus with anaccessible alternative
← Previous message | Next message →

Jim Thatcher wrote:

>Don Wrote:
>
>
>>I have used these menus from Project Seven:
>>http://www.projectseven.com/products/menusystems/pmm/index.htm
>>
>>
>
>Probably I am missing something on these menus, but the fact that you can
>get to all menu items with the keyboard may make them technically
>accessible, but not practically accessible. I believe that the only way to
>have JavaScript roll menus accessible is to have the main menu item active
>so that the page it opens has all the submenu links immediate in the
>navigation area of the page - like at http://nsf.gov. Actually the NSF menu
>system is not the same kind of rollover menus we're talking about(anymore)
>but the idea is the same. There's a screen shot of what they used to be at
>http://jimthatcher.com/webcoursea.htm, figure 10.4.
>
>
>
Hi Jim,
I'd like to understand your point a little better...are you saying that
it is a matter of degrees of accessibiity? In other words you feel the
menus are accessible, just not very accessible? What about them is not
accessible?
So you are saying that once I get to page 'A' all of the previously
hidden subpage choices should be clearly visible on that page, right?
What about the rest of the hidden menus for the other sections...aren't
they equally inaccessible at that point?
Or is the idea that once on page 'A' a user won't have to tab through or
listen to all the menu choices for all the pages to get to the
sub-choices for page 'A'?

Thanks,
Don

--
Don Hinshaw
Hinshaw Design Group
http://www.hinshawdesign.com

From: Bill Adams
Date: Fri, Jul 29 2005 11:17AM
Subject: RE: good examples of javascript "roll over" menus with an accessible alternative
← Previous message | Next message →

Hello everyone,

I usually just read the list, but this one really caught my eye as I've
been looking for such a thing too.

What is everyone's opinion on the Ultimate Drop Down Menu by Brothercake
(http://www.udm4.com/)?

This has been the only one I've found to be free and the creator says it
is accessible.

Thanks
Bill

From: Jennifer Sutton
Date: Fri, Jul 29 2005 12:26PM
Subject: RE: good examples of javascript "roll over" menus with an accessible alternative
← Previous message | Next message →

Hello:

I look forward to any other comments on this thread. I was also wondering
about the product Bill Adams mentioned so I, too, will welcome observations
about it.

I wanted to thank everyone for their thorough, detailed, and most helpful
responses to my question under this and other threads (including popups and
variations of that). I wish that the issue weren't so tricky to resolve,
but at least I'm confirmed in my sense that there is no "magic" solution.

I appreciate everyone's generously sharing their experiences and experiments.

Best,
Jennifer

From: John Foliot - WATS.ca
Date: Fri, Jul 29 2005 1:20PM
Subject: RE: good examples of javascript "roll over" menus with an accessible alternative
← Previous message | Next message →

Bill Adams wrote:
> Hello everyone,
>
> I usually just read the list, but this one really caught my eye as
> I've been looking for such a thing too.
>
> What is everyone's opinion on the Ultimate Drop Down Menu by
> Brothercake (http://www.udm4.com/)?
>
> This has been the only one I've found to be free and the creator says
> it is accessible.
>
> Thanks
> Bill


Hi Bill,

You sure that this isn't just a continuation of the "other" thread that
produced all the vitriol earlier?

Yes, Brothercake's "flyout" or dropdown menu is generally accessible
from a *technical* perspective. However it still can induce "issues"
with some user-groups, and opinion is split on it's level of
accessibility. Like many of the judgement calls we are forced to make
in the name of accessibility, some think it is, some think otherwise.
My personal opinion is that of the later group. As much of this I just
wrote in response to the other thread, if you read my previous posting
this morning it will be old news:

1) Number of links in the nested list: Having a nested list with 44
different list items links is going to be an issue for many users -
flyout (compacted) menus or not. It's information overload (too many
initial choices) that can affect users with cognative impairments, and
is covered by WCAG Guideline Priority 2 - 12.3 "Divide large blocks of
information into more manageable groups where natural and appropriate".
If you think about it, using compacted (flyout) menus such as
Brothercake's
acknolwedge this very point - this is why you are compacting the list in
the first place, no? Perhaps a better method is to re-think the
navigation process into better "streams", rather than seek to provide
*all* the links every time on every page.

2) Order of placement in your source code: What if this codeblock
(complete with all 44 links) is placed at the "top" of your source code
- minus a "skip nav" link or equivelant?... Is it still "accessible"?
Many (most) would argue no, and it certainly would not pass muster under
Section 508. Screen Readers (for example) would have to sit and listen
to those 44 links every single time. And what if the code block is at
the "end" of the source code? Again, without a "skip-to" link, the page
must be "read" to the end before we reach the nav block. This is an
accessibility issue! (and BTW, fails WAI AAA Status (WCAG Priority 2 -
9.5 "Provide keyboard shortcuts to important links (including those in
client-side image maps), form controls, and groups of form controls.") -
plus without the proscribed "Skip Nav" link you fail Section 508
(

From: Paul Bohman
Date: Fri, Jul 29 2005 2:07PM
Subject: Re: good examples of javascript "roll over" menus with an accessible alternative
← Previous message | Next message →

This is a long message, but hopefully it contains some ideas to make
people think about the issue of flyout menus:

The flyout menus by Brothercake are perhaps the best attempt that I've
seen to address a wide variety of accessibility problems that plague
most other attempts. I have not tested them extensively, but viewed them
in Windows versions of Firefox, IE 6.0, Netscape 8.0 and Opera 8.0. I
have not listened to them with a screen reader.

One of the most impressive features of these menus is that they work
just like operating system menus. Glenda asked about the possibility of
navigating flyout menus with the arrow keys. You *can* navigate these
with the arrow keys: forward, backwards, up down. They work. Well, they
don't work so well in Opera, but let me come back to that point a little
later.

If we look at this as a challenge of trying to create flyout menus that
are accessible and which act like operating system menus (which we
assume are accessible), these menus seem to have succeeded.

There are still a few issues left to consider:
1. Are flyout menus accessible on an abstract level (as opposed to in
technical terms in HTML-specific environments)?
2. What about browsers that don't support this method?
3. People aren't used to having HTML menu systems that work like
operating system menus.

1. So let's talk about the first issue: are flyout menus accessible on
an abstract level?

John Foliot alluded to this question when he complained of the problem
with many links and submenus. The fact that users can use the arrow keys
to move through these menus means that the "too many submenus" concern
is not as critical as it would be if the arrow keys did not perform this
function. Speaking abstractly, if operating system flyout menus are
accessible, these menus are accessible.

That doesn't totally answer the question though. The fact that
Brothercake's menus are dense is really irrelevant. You can make menus
sparse or dense. There are obviously some concerns about dense menus, in
terms of usability, comprehension, navigation, and so on, but if we say
that his flyout menu system is bad because people might add too many
links, that's like saying HTML is inaccessible because you can create
confusing web pages. Of course you can use technologies like HTML or his
flyout menus (which use HTML, CSS, and JavaScript) to create confusing
content. You can also create usable and accessible content with HTML,
and my guess is that you can create usable and accessible content with
his menus... as long as we all agree that flyout menus *can* be
accessible in an abstract sense. Are the flyout menu systems in MS Word
accessible? (I'm referring to the main menus such as File, Edit, Tools,
etc.) If you don't think those menus are accessible, then you won't
think that *any* flyout menu system is accessible, no matter what. I
tend to think that those menu systems qualify as being accessible. They
are accessible by keyboard, by screen reader, by sight, and they seem to
work quite well. I haven't heard too many people with disabilities
complaining about those menu systems lately. Of course, I have seen
software with confusing menu systems, or too many submenus, or confusing
labels. Sure, these problems exist, and they do reduce accessibility,
but it's not really the fault of the "flyout menu" technology per se.

Should we dismiss attempts to replicate a convention (flyout menus) that
is generally believed to be accessible in an operating system
environment? In other words, if people don't complain about the
accessibility of operating system menus (which definitely have flyout
components and submenus), why should we complain about implementing them
in HTML (provided that they are accessible)?

Think about that one for a moment. I think you'll either have to say
"operating system flyout menus are not accessible" or "HTML flyout menus
could be made to be accessible if done right."


2. Browser support issues

The menus don't work in every browser. They work well in quite a few
modern browsers, but not in all of them. They certainly don't "work" in
older browsers that lack support for CSS, though the links and the
hierarchical structure are completely available in these older browsers
(and are therefore "accessible" in that sense), even if they are not so
fancy or attractive.

We could just say "well, they don't work in every browser, therefore, we
should not use them and should stop trying to use anything like that."
That's not very productive in my opinion. Let people experiment. HTML
and browsers are not perfectly robust. There's a lot that needs to
happen before we can reach the same level of accessibility for
interactive features which is not available in operating systems (though
I would add that operating system accessibility is still far from perfect).

With old technologies, we have to let them go at some point. We have to
be considerate of all users, but we can't access most websites on the
old Mosaic browser, or Netscape 1.0 anymore. That's progress, not a
problem, in my opinion.


3. Users don't know how to work the menus (i.e. they may not expect
tabbing to work and almost certainly won't know to use the arrow keys.

This is a real issue, but I use the same logic as in my response to the
previous concern. People don't know about it because they've been using
websites that were incapable of giving them that functionality. If we
invent a system/technology/method that works, shouldn't we promote it
rather than squashing it?

Having said this, it's a chicken and egg dilemma. People won't know to
expect the menus to work "correctly" until they experience sites that
use them "correctly." It is hard to justify implementing them on a site
until people know how to use them. At some point we have to draw the
line and start using new technologies and ideas. The conversion to CSS
websites has been slow, but it's coming around. Maybe the same will
happen with this type of menu... and maybe it won't.

All I'm saying is that we need to think forward and not just backward
when talking about accessibility.


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

From: Christian Heilmann
Date: Fri, Jul 29 2005 2:53PM
Subject: Re: good examples of javascript "roll over" menus with an accessible alternative
← Previous message | Next message →

> Are the flyout menu systems in MS Word
> accessible? (I'm referring to the main menus such as File, Edit, Tools,
> etc.) If you don't think those menus are accessible, then you won't
> think that *any* flyout menu system is accessible, no matter what. I
> tend to think that those menu systems qualify as being accessible. They
> are accessible by keyboard, by screen reader, by sight, and they seem to
> work quite well. I haven't heard too many people with disabilities
> complaining about those menu systems lately. Of course, I have seen
> software with confusing menu systems, or too many submenus, or confusing
> labels. Sure, these problems exist, and they do reduce accessibility,
> but it's not really the fault of the "flyout menu" technology per se.
>
> Should we dismiss attempts to replicate a convention (flyout menus) that
> is generally believed to be accessible in an operating system
> environment? In other words, if people don't complain about the
> accessibility of operating system menus (which definitely have flyout
> components and submenus), why should we complain about implementing them
> in HTML (provided that they are accessible)?
>
> Think about that one for a moment. I think you'll either have to say
> "operating system flyout menus are not accessible" or "HTML flyout menus
> could be made to be accessible if done right."

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.)

So to compare Word and HTML we'd have to talk about VB enabled Word
documents with dropdown navigation to jump to the different pages. And
even in Word this is normally done by a generated TOC of links.

This also affects the visitor. Why should the document be navigated
like the options of the application it is opened in?

Maybe it is time to ask the users. On all the sites I maintained and
tested with real users I have yet to find a user that claimed that a
shortcut to any of the pages in the sitemap without leaving this page
would be great. Instead of navigating through three levels of
navigation they either used the sitemap or the search instead.

Am I not right to assume that visitors normally come to a site with a
certain goal in mind. "I want to buy some CDs" is more likely a driver
than "I want to see how deep this site is and what they offer me, and
I don't want a reload in between".
As stated before in this thread, if you want to offer that, why not do
so as an "enhanced navigation" feature. Let marketing go wild and call
it "KwikNav" or something like that.
Amazon.com for example finally realised that too many tabs are not a
good plan, and now have a dynamic popup navigation listing all sub
sections. Sadly enough it seems to be enabled by default.

Navigation is a tool, much like anything else, it should help the
visitor find her way through the things we offer. A lot of the
reasoning I read here is about defending popup navigation as it is a
pseudo standard. It is in application development, but a web site is
not an application, it is connected content. The question should never
be "how can we make this accessible", the question is "how do users
benefit from this navigation". It would be great to have a comparison
of different navigation systems with a wide range of users of
different abilities. My personal assumption is that if the site
indicates to be huge, most will use the search and just not bother
with the navigation system.

From: Austin, Darrel
Date: Fri, Jul 29 2005 5:00PM
Subject: RE: good examples of javascript "roll over" menus with a n accessible alternative
← Previous message | Next message →

> Off Topic possibly but -
> should/shouldn't "skip-to" links be visible to all?)

First, I just want to say that that was an excellent post, John. It summed
up the issues with fly-out menus in general quite well.

As to the specific comment above, I thought I'd expand on my comment before
on suggesting making interface widgets like this an user-option.

There is no argument that skip links are useful. There are valid arguments
on both sides as to whether or not they should be visible:

Arguments for VISIBLE:

- helps to indicate to those that can see just fine, but prefer to use
the keyboard that they can skip directly to the content area

Arguments for NOT VISIBLE:

- takes up screen real estate
- may confuse people that don't know what it's for

As such, I took the easy (cowards?) way out on our site design* this past
year:

http://www.courts.state.mn.us/accessibility/

I made it an option for the end-user. The links are always there, but only
visible if you want them visible. Same goes for the on-screen font resizer,
which falls into the same category as above (there are perfectly valid
argument for both having it and not having it on the site).

And, again, this all goes for this debate on fly-out navigation as well.

We've been fine without fly-out navigation on our site for a while, but a
lot of folks...namely internal employees, really would like to see it, so
I'm not thinking that I'm definitely going to make this an option if people
want it via the same method as the other items.

I'm curious as to what others think about this. Am I overthinking the issue?
Has anyone seen simliar or better implementation elsewhere?

-Darrel

* = yes, I know there are still a lot of other accessibility issues with
this site. General feedback is certainly welcome, but just FYI, we're doing
version '2.0' by end of year with a much more overhauled site in terms of
addressing accessibility issue.

From: Paul Bohman
Date: Fri, Jul 29 2005 5:00PM
Subject: Re: good examples of javascript "roll over" menus with an accessible alternative
← Previous message | Next message →

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

From: Christian Heilmann
Date: Fri, Jul 29 2005 5:25PM
Subject: Re: good examples of javascript "roll over" menus with a n accessible alternative
← Previous message | No next message

> > Off Topic possibly but -
> > should/shouldn't "skip-to" links be visible to all?)
> As to the specific comment above, I thought I'd expand on my comment before
> on suggesting making interface widgets like this an user-option.
> There is no argument that skip links are useful. There are valid arguments
> on both sides as to whether or not they should be visible:
> Arguments for VISIBLE:
>
> - helps to indicate to those that can see just fine, but prefer to use
> the keyboard that they can skip directly to the content area

Furthermore they show a lot easier that you _do_ care about
accessibility - which is a self policing that a lot of scared "can we
be sued" clients have righ now - than any WCAG badge ever can.

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.

> Arguments for NOT VISIBLE:
>
> - takes up screen real estate
> - may confuse people that don't know what it's for

Again, the latter can actually be used as an argument in favour, as it
can help those also find out about the other opportunities accessible
web design gives the abled user (larger click area through labels for
example)

> As such, I took the easy (cowards?) way out on our site design* this past
> year:
>
> http://www.courts.state.mn.us/accessibility/
>
> I made it an option for the end-user. The links are always there, but only
> visible if you want them visible. Same goes for the on-screen font resizer,
> which falls into the same category as above (there are perfectly valid
> argument for both having it and not having it on the site).
>
> And, again, this all goes for this debate on fly-out navigation as well.
>
> We've been fine without fly-out navigation on our site for a while, but a
> lot of folks...namely internal employees, really would like to see it, so
> I'm not thinking that I'm definitely going to make this an option if people
> want it via the same method as the other items.
> I'm curious as to what others think about this. Am I overthinking the issue?
> Has anyone seen simliar or better implementation elsewhere?

Making something that might not work for everybody optional and
enabling the user to turn it off and on is never a bad idea IMHO.
Every good application has it, or would you like to have every toolbar
in Word visible? :-)

One danger is overdoing the amount of options to turn things on and
off though. A good solution would be a general "customise this site"
page.

When I was young and innocent I went completely overboard with this idea:
http://www.icant.co.uk/ltlg/

--
Chris Heilmann
Blog: http://www.wait-till-i.com
Writing: http://icant.co.uk/
Binaries: http://www.onlinetools.org/