E-mail List Archives

Search E-mail List Archives for

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

From: Austin, Darrel
Date: Sat, Aug 06 2005 12:00PM
Subject: (The return of...) Accessible popup menus
No previous message | Next message →

Coincidently, after last weeks debate on DHTML fly-out navigation, I'm now
at the point where I need to consider it for use on a couple of our sites.

I'm not a big fan of fly-out navigation. Not only because of accessibility,
but also usability. I find my main gripes are:

- they rarely indicate 'you are here' to the user
- they tend to cause the user to spend more time
mousing over each item to explore what's underneath
rather than allowing them to drill down into the site
in a specific path
- initial 'dive' into the site may be quicker, but
subsequent traversing of the site can get tedious
as they have to re-navigate the menu each and every
time they want to move somewhere else.

To be fair, there are a few advantages:
- a large, deep site with many unique customer-centric
areas can benefit by allowing different customers
quickly get to their specific area of the site
- web applications can benefit from this by clearing
up some real estate

In our case, we need a fly-out menu system for our CMS tool that we are
building. People will be jumping all over the place so a one-level menu
system will actually be useful for them. On our public site, we're
considering implementing a fly-out system as an option for the end user
(they could turn this option on if they prefer...otherwise, they'll get the
default hierarchical, nested-list menu)

So, I'm at the point where I need to actually find something that, as best
as it can, is both usable and accessible. Key features I am looking for are:

- unobtrusive and semantic markup (ie, menu can be
nested list with minimal-to-no actuall javascript
in the HTML)
- decent keyboard navigation
- 'timed' show/hide for menus, to allow a person
to mouse out of a top-level item, cross another item
and still get to the first fly-out menu that was triggered
(this is actually my biggest grip with most
fly-out navigation systems)

Any suggestions?

So far, I've looked at about a dozen options. I can group them into these
categories:

1) commercial scripts that look great, are often quite usable, but
completely inaccessible and hardly semantic
2) free scripts that are mostly written poorly, inaccessible, or lacking
some of the nicer usability features.
3) Project Seven's menu system and BrotherCake's menu system...the only two
that seem worth considering. Of the two, BrotherCake seems a bit less
obtrusive in terms of the HTML.

Does anyone have any other suggestions to add to category 3 that I should
take a look at? I can be a little more leniant on the accessibility issues
(as we're making this an option on the public site...not a requirement) so I
am considering a few runner ups such as the CSS based Suckerfish menus.

-Darrel

From: Austin, Darrel
Date: Sat, Aug 06 2005 6:00AM
Subject: RE: (The return of...) Accessible popup menus
← Previous message | Next message →

(APOLOGIES all for that last, incomplete message...I REALLY hate Outlook's
shift-return shortcut for sending a message ;o)

> > Sadly, there still seems to be no
> > "definitive" answer as to "how many?". Like many of the choices we
> > make, it all depends...

There is a definitive answer: 'it depends'

;o)

I think the issue of 'too many choices' while certainly an accessibility
issue, is more so a usability issue.

It becomes an issue of focus. When one has a standard flat menu with perhaps
one sub menu:

Item 1
subitem 1
subitem 2
subitem 3
Item 2
Item 3
Etc

They gain the usability of focus. One only has two sets of menus to focus
on. The parent, and the one child. When you introduce fly-outs, that focus
is blurred. The user may now be distracted by all the other menus they can
explore. Akin to those of us that are habitual channel surfers on digital
cable/sattelite. We can't make it through one show because we're so
distracted by the ability to scan the rest at the same time. (OK, maybe not
the best analogy...maybe someone can improve that ;o)

> > The other significant issues are that of mobility impairments and
> > alternative user agents.

> I move that many ordinary text links, at typical body "font-sizes"
> present the same problems.

True...but not to the same extent. A static list has one target. A fly out
has multiple...the parent, then the child, etc.

> My greatest aprehension is that as IE7 ramps up market share,
> it joins
> other modern browsers in supporting ":hover" by spec and that
> so-called "pure CSS menus" will spread like wildfire.

I fear that too. I've asked this simliar question elsewhere and a lot of the
responses are 'check out the suckerfish menu!' and that is a bit worrisome.

Granted, all sorts of bad fly-out navigation systems have already spread
like wildfire, so maybe it's a moot point.

-Darrel

From: John Foliot - WATS.ca
Date: Sun, Aug 07 2005 6:00AM
Subject: RE: (The return of...) Accessible popup menus
← Previous message | Next message →

Al Sparer wrote:
> Nothing is ever perfect in this field, but we
> tried to address a lot of good comments made by some of the folks
> here. I also want to apologize for my bull-charge into the list last
> week. No matter my reasons, there is never an excuse for that kind of
> entrance.

After publicly slapping down Al last week (and getting scolded myself by
the moderator), he and I continued to correspond privately. It was a
fruitful exchange.

Al, welcome to the list!

>
> While we consider our CUSS, markup, and scripting end of this equation
> as good or better than anything else, the methods discussed in the
> article would work for any well-coded menu system, so long as the
> system is straightforward and flexible enough to begin with.
>
> Hope this helps someone and do feel free to comment.
>

The one thing I wish to comment on the most is the issue of cognitive
load. While I do appreciate that certain times and instances would
warrant consideration of a flyout menu, developers *must* be reasonable
in the application of this type of technique. Using multiply nested
lists that "compact" via CUSS and/or JavaScript may visually help visual
users, however we must all understand that for some users, too many
choices is confusing at best, and may in fact cause "failure" in their
quest. The 31 separate choices in the Project Seven (PIE) website's
navigation flyout would be too many (IMHO) for many users. It took *me*
4 tries to find the "free" DEW extensions available for download, and I
consider myself a fairly web-savvy user.

How much is too much? Wish I had a definitive answer. But *I do* know
when there is too much... But it's an instinctive reasoning, rather than
hard science - just like knowing what is "appropriate" ALT text. My
acid test is this - can I remember all of the options available once
I've been exposed to them all? How many *can* I remember?

Some studies[1] have suggested that the "Magic Number" of 7 (+/- 2) is a
reasonable number to work with - but does that mean 7 lists of seven
options? Visually impaired users I know would argue that having an
initial 49 navigational choices would be too many - especially if they
were arriving at a site for the first time.

In a 1997 CHI (Computer Human Interface) paper [2], it was noted, "The
basic insight is that, in order to navigate through a world with minimal
prior knowledge of its layout, .... that they [developers - JF] shall
not overwhelm the user with information. In particular for view
navigation, Furnas showed that it is ideal to show only small views (a
relatively small number of choices) that the number of navigation steps
is not too large and that the route to any target must be discoverable."
A Microsoft study [1.2] demonstrated that accuracy diminished as more
"sub-levels" (hierarchy) were added (in other words one nested list
inside the master list is preferred over a list inside of a list inside
of a list).

However, George A. Miller (the original author of "The Magical Number
Seven") noted "The point seems to be that, as we add more variables...,
we increase the total capacity [of differentiation - JF], but we
decrease the accuracy for any particular variable.."[1.1]

Now I ain't no CHI expert - but clearly these guys have research backing
up my claim - too many initial choices hinders rather than helps. It
seems that you *can* have more than 7, but the more you add, the less
accurate the end user's results become; so at what point do we "turn the
corner"? Sadly, there still seems to be no "definitive" answer as to
"how many?". Like many of the choices we make, it all depends...

***

The other significant issues are that of mobility impairments and
alternative user agents. Tightly packed hyperlinked objects can cause
issues for users who lack fine motor coordination, either due to some
form of disability of simply because the user agent and/or impute tools
they are using cannot provide the required finesse.

So, if you *really* must employ flyout menus, do so with caution and
prudence - they cannot become the collapsing site map present on every
page, as this will simply defeat any positive effect you are striving
for. As well, I would caution any developer who is *mandated* to
achieve a certain level of compliance to any of the "standards" (be it
Section 508 or A, AA, AAA) that due to the cognitive load issue you
*may* not be in compliance - blanket claims of any of the prepackaged
(or even "roll-year-own") solutions not-withstanding:

WAG Priority 2 - 12.3 Divide large blocks of information into more
manageable groups where natural and appropriate.
WAG Priority 3 - 9.4 Create a logical tab order through links, form
controls, and objects.
WAG Priority 3 - 13.6 Group related links, identify the group (for user
agents), and, until user agents do so, provide a way to bypass the
group.

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


[1.1] The Magical Number Seven, Plus or Minus Two: Some Limits on Our
Capacity for Processing Information
(http://www.well.com/user/smalin/miller.html)
[1.2] Is the Magic Number 7 Relevant to Web Page Design
(http://research.microsoft.com/users/marycz/chi981.htm)
[2] Effective View-Navigation. Human Factors in Computing Systems CHI
'97 Conference Proceedings, New York, NY: ACM Press
(http://www.interaction-design.org/references/conferences/proceedings_of
_the_acm_chi_97_human_factors_in_computing_systems_conference.html -
requires subscription)


*

From: Al Sparber
Date: Fri, Aug 05 2005 12:00PM
Subject: Re: (The return of...) Accessible popup menus
← Previous message | Next message →

John Foliot - WATS.ca wrote:
> After publicly slapping down Al last week (and getting scolded
> myself
> by the moderator), he and I continued to correspond privately. It
> was a fruitful exchange.
>
> Al, welcome to the list!

Thank you, John :-)

> The one thing I wish to comment on the most is the issue of
> cognitive
> load. While I do appreciate that certain times and instances would
> warrant consideration of a flyout menu, developers *must* be
> reasonable in the application of this type of technique.

Agreed. Too much of anything is usually a bad thing.

> multiple nested lists that "compact" via CSS and/or JavaScript may
> visually help visual users, however we must all understand that for
> some users, too many choices is confusing at best, and may in fact
> cause "failure" in their quest. The 31 separate choices in the
> Project Seven (PIE) website's navigation flyout would be too many
> (IMHO) for many users. It took *me* 4 tries to find the "free" DEW
> extensions available for download, and I consider myself a fairly
> web-savvy user.

Well, our web site is not necessarily the poster child for this
discussion, the article's sample site actually is :-) - I think you
looked for our free extensions based on one of our private
correspondences. Dreamweaver users would tend to simply look for our
extensions. On our main site, we have an "Extensions" root menu item
with a two-item flyout. Clicking the root item, takes one here:
http://www.projectseven.com/extensions/

This page is an overview of extensions, in general, and contains
inline links to our 5 most popular extensions (2 of which are free),
as well as links to the list. I added an extra one, closer to the top,
last night, because I was concerned about your failure to find it :-)

The first flyout item is: "Extensions List", which leads to our list
of extensions:
http://www.projectseven.com/extensions/listing.htm

This page also contains inline (in the narrative) links to the overall
listing.

The second flyout item is a link to the default extensions page
overview.

Ongoing, let's not address our main web site, but do note that when we
undertake our next re-design, you might be getting a phone call :-)



> How much is too much? Wish I had a definitive answer. But *I do*
> know when there is too much... But it's an instinctive reasoning,
> rather than hard science - just like knowing what is "appropriate"
> ALT text. My acid test is this - can I remember all of the options
> available once I've been exposed to them all? How many *can* I
> remember?
>
> Some studies[1] have suggested that the "Magic Number" of 7 (+/- 2)
> is a reasonable number to work with - but does that mean 7 lists of
> seven options? Visually impaired users I know would argue that
> having an initial 49 navigational choices would be too many -
> especially if they were arriving at a site for the first time.

Here's where we get into nuances. The sample site is configured so
that only mouse users have the deeper menu choices. Assistive devices
and keyboard users only "see" the root links - never the flyouts. If
what you are saying is that there are people using a mouse whose
physical state precludes precise aiming, then that could be an issue.
How critical an issue? I don't know. We have timers running that allow
for diagonal paths across the menu. That's good. I'm not sure that a
person in that situation would not have trouble with ordinary links,
as well. I'm also not sure if people who do have pointing device
problems know to use the keyboard as a fallback. Without doing very
specific testing with my own code, I cannot tell you for sure - but
conversely, I don't think there is a clear case against it. Rather
than getting bogged down in a negative perspective, perhaps positive
solutions should be theorized. Root link elements can be given extra
padding to allow for a buffer, like this:

http://www.projectseven.com/tutorials/accessibility/pop_integrated/pmmsite/buffer1.htm




> In a 1997 CHI (Computer Human Interface) paper [2], it was noted,
> "The
> basic insight is that, in order to navigate through a world with
> minimal prior knowledge of its layout, .... that they [developers -
> JF] shall not overwhelm the user with information. In particular for
> view navigation, Furnas showed that it is ideal to show only small
> views (a relatively small number of choices) that the number of
> navigation steps is not too large and that the route to any target
> must be discoverable." A Microsoft study [1.2] demonstrated that
> accuracy diminished as more "sub-levels" (hierarchy) were added (in
> other words one nested list inside the master list is preferred over
> a list inside of a list inside of a list).

Good stuff. But I submit that it's specific to a test case that is not
apparent and does not present alternative possibilities. Empirical
research always includes multiple theoretical scenarios until it is
proved, beyond a doubt, that there exists a law. Moreover, it can be
said that since our example shows a "small view" unless and until a
pointer device "asks for more" that it fits this theoretical model. It
can also be said that offering deeper choices, with moderation,
enriches the user experience and allows people to reach their desired
destination with fewer "clicks". One also has to consider the nature
of the internet as a network of hypertext data, that the number of
choices scattered within a document's narrative must also be
considered in the same negative or positive ways.

> Now I ain't no CHI expert - but clearly these guys have research
> backing up my claim - too many initial choices hinders rather than
> helps. It seems that you *can* have more than 7, but the more you
> add, the less accurate the end user's results become; so at what
> point do we "turn the corner"? Sadly, there still seems to be no
> "definitive" answer as to "how many?". Like many of the choices we
> make, it all depends...

We have customers who understand these kinds of issues and endeavor to
integrate a PMM menu into as accessible a scenario as they can. We
also have customers who pack a menu with (literally) a hundred or more
links - essentially creating a persistent site map. Although I'd love
to show these people the way, we can't. We are our brothers'
advisors - not keepers. Overlinking a navbar does not require the
navbar to be of the popup/flyout persuasion. I've seen perfectly
static navigation bars pathetically abused from a number of different
perspectives.



> ***
>
> The other significant issues are that of mobility impairments and
> alternative user agents. Tightly packed hyperlinked objects can
> cause
> issues for users who lack fine motor coordination, either due to
> some
> form of disability of simply because the user agent and/or impute
> tools they are using cannot provide the required finesse.

I move that many ordinary text links, at typical body "font-sizes"
present the same problems. A specific set of links in a dedicated
navbar can contain mitigating style properties, while ordinary text
links or text links within the narrative cannot. Extra padding makes
bigger targets:
http://www.projectseven.com/tutorials/accessibility/pop_integrated/pmmsite/buffer1.htm

However, in some of these cases (I don't know how many), people with
mobility problems might also be adept at switching to the keyboard if
things become difficult. Not a solution, but a nuance.


> So, if you *really* must employ flyout menus, do so with caution and
> prudence - they cannot become the collapsing site map present on
> every
> page, as this will simply defeat any positive effect you are
> striving
> for.

Well said. I would also add that in addition to caution, one should
bring knowledge, understanding, and insight to bear.


> As well, I would caution any developer who is *mandated* to
> achieve a certain level of compliance to any of the "standards" (be
> it
> Section 508 or A, AA, AAA) that due to the cognitive load issue you
> *may* not be in compliance - blanket claims of any of the
> prepackaged
> (or even "roll-year-own") solutions not-withstanding:

I think you meant to say "might not", with which I agree. I have
gotten from our conversations that we need to qualify our
accessibility verbage to ensure that people understand that simply
passing muster with automated checkers is just the beginning of the
process, and that it's up to them to unserstand the finer points of
the guidelines in the context of their own goals. But I do rather
prefer to approach problems from a more positive orientation.


> WAG Priority 2 - 12.3 Divide large blocks of information into more
> manageable groups where natural and appropriate.

You know, some parents raise their kids with that kind of approach :-)
I would much rather have more clearly defined criteria :-)


> WAG Priority 3 - 13.6 Group related links, identify the group (for
> user agents), and, until user agents do so, provide a way to bypass
> the group.

Theoretically sound, but if the narrative section of a web page
contains 20 or more links, simply separated by a few words, that gets
around the ambiguity of them being a "group", or does it :-)

My greatest aprehension is that as IE7 ramps up market share, it joins
other modern browsers in supporting ":hover" by spec and that
so-called "pure CSS menus" will spread like wildfire. That type of
navigation will become a curse of unprecedented magnitude to usability
and accessibility evangelists because the "suckers" have no way to be
refined for use by even able-bodied people with a mouse :- ) Since
there is a slight overlap between the standards and accessibility
communities, I'm dying to see how that will play out.

Another thing that I have a problem with are menu systems that attempt
to behave like OS menus. It'll never happen unless those actual
controls are someday made available to browsers. If a menu system
requires that a user read an instructions page to learn - for that
matter, if an accessibility scenario requires the same - then that
would seem to create a real-world problem - one that looks great on
paper but fails miserably in the field.

--
Al Sparber - PVII
http://www.projectseven.com

From: Austin, Darrel
Date: Fri, Aug 05 2005 6:00AM
Subject: RE: (The return of...) Accessible popup menus
← Previous message | Next message →

> For Research and Reading:
>
> http://www.uie.com/articles/users_decide_first/
> http://psychology.wichita.edu/surl/usabilitynews/51/menu.htm

Yep. Both good reads. I tend to agree with them, too.

I really don't like fly-out menus. But, if I have to use them, I'm looking
for some viable options.

In addition to the two I mentioned, Ben's link led me to this example:

http://www.sarmal.com/lib/web/sarmal/script/sardalya/DropDownMenu_Test.html

Explanation here:

http://lists.evolt.org/archive/Week-of-Mon-20050711/173951.html

So that may be a contender as well.

-Darrel

From: Al Sparber
Date: Tue, Aug 09 2005 11:08AM
Subject: Re: (The return of...) Accessible popup menus
← Previous message | Next message →

From: "Austin, Darrel" < = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, August 04, 2005 5:26 PM
Subject: [WebAIM] (The return of...) Accessible popup menus


> Coincidently, after last weeks debate on DHTML fly-out navigation,
> I'm now
> at the point where I need to consider it for use on a couple of our
> sites.
>
> I'm not a big fan of fly-out navigation. Not only because of
> accessibility,
> but also usability. I find my main gripes are:

Hi Darrel,

I want to take this opportunity to link to an article we wrote that
discusses one possible way to integrate a popup/flyout menu system
into an accessible site. Nothing is ever perfect in this field, but we
tried to address a lot of good comments made by some of the folks
here. I also want to apologize for my bull-charge into the list last
week. No matter my reasons, there is never an excuse for that kind of
entrance. That said, I hope that anyone here who is interested in
trying to integrate a popup menu into an accessible site would take a
few moments and read the article, as well as browsing its companion
example site.

http://www.projectseven.com/tutorials/accessibility/pop_integrated/

While we consider our CSS, markup, and scripting end of this equation
as good or better than anything else, the methods discussed in the
article would work for any well-coded menu system, so long as the
system is straightforward and flexible enough to begin with.

Hope this helps someone and do feel free to comment.

Al Sparber
PVII
http://www.projectseven.com

"Designing with CSS is sometimes like barreling down a crumbling
mountain road at 90 miles per hour secure in the knowledge that
repairs are scheduled for next Tuesday".

From: John Foliot - WATS.ca
Date: Tue, Aug 09 2005 11:09AM
Subject: RE: (The return of...) Accessible popup menus
← Previous message | Next message →

Austin, Darrel wrote:
>
> In our case, we need a fly-out menu system for our CMS tool that we
> are building. People will be jumping all over the place so a
> one-level menu system will actually be useful for them. On our public
> site, we're considering implementing a fly-out system as an option
> for the end user (they could turn this option on if they
> prefer...otherwise, they'll get the default hierarchical, nested-list
> menu)

For Research and Reading:

http://www.uie.com/articles/users_decide_first/
http://psychology.wichita.edu/surl/usabilitynews/51/menu.htm

Later...

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

From: Glenda Watson Hyatt
Date: Tue, Aug 09 2005 11:09AM
Subject: RE: (The return of...) Accessible popup menus
← Previous message | Next message →

Darrel wrote:

I really don't like fly-out menus. But, if I have to use them, I'm looking
for some viable options.

In addition to the two I mentioned, Ben's link led me to this example:

http://www.sarmal.com/lib/web/sarmal/script/sardalya/DropDownMenu_Test.html

Glenda adds:

I just tried this one very quickly, so it's quite possible I missed
something, but for those using the keyboard it seems necessary to tab
through everything. That was one thing I liked about brothercake's, I think
it was. I could use the arrow keys to jump sub menus. That is simply my
input from an end-user's perspective. I realize there are back-end
considerations too, which I don't pretend to fully understand yet.

For what it's worth,
Glenda
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.0/63 - Release Date: 8/3/2005

From: Austin, Darrel
Date: Tue, Aug 09 2005 11:09AM
Subject: RE: (The return of...) Accessible popup menus
← Previous message | Next message →

> > Sadly, there still seems to be no
> > "definitive" answer as to "how many?". Like many of the choices we
> > make, it all depends...

There is a definitive answer: 'it depends'

;o)

I think the issue of 'too many choices' while certainly an accessibility
issue, is more so a usability issue.

It becomes an issue of focus. When one has a standard flat menu with perhaps
one sub menu:

Item 1
subitem 1
subitem 2
subitem 3
Item 1
Item 1
While one can argue that fly-out navigation condenses the scope of options
nicely, the actual behavior seems to negate that one benefit.

There's no doubt

> We have customers who understand these kinds of issues and
> endeavor to
> integrate a PMM menu into as accessible a scenario as they can. We
> also have customers who pack a menu with (literally) a
> hundred or more
> links - essentially creating a persistent site map. Although I'd love
> to show these people the way, we can't. We are our brothers'
> advisors - not keepers. Overlinking a navbar does not require the
> navbar to be of the popup/flyout persuasion. I've seen perfectly
> static navigation bars pathetically abused from a number of different
> perspectives.
>
>
>
> > ***
> >
> > The other significant issues are that of mobility impairments and
> > alternative user agents. Tightly packed hyperlinked objects can
> > cause
> > issues for users who lack fine motor coordination, either due to
> > some
> > form of disability of simply because the user agent and/or impute
> > tools they are using cannot provide the required finesse.
>
> I move that many ordinary text links, at typical body "font-sizes"
> present the same problems. A specific set of links in a dedicated
> navbar can contain mitigating style properties, while ordinary text
> links or text links within the narrative cannot. Extra padding makes
> bigger targets:
> http://www.projectseven.com/tutorials/accessibility/pop_integr
> ated/pmmsite/buffer1.htm
>
> However, in some of these cases (I don't know how many), people with
> mobility problems might also be adept at switching to the keyboard if
> things become difficult. Not a solution, but a nuance.
>
>
> > So, if you *really* must employ flyout menus, do so with caution and
> > prudence - they cannot become the collapsing site map present on
> > every
> > page, as this will simply defeat any positive effect you are
> > striving
> > for.
>
> Well said. I would also add that in addition to caution, one should
> bring knowledge, understanding, and insight to bear.
>
>
> > As well, I would caution any developer who is *mandated* to
> > achieve a certain level of compliance to any of the "standards" (be
> > it
> > Section 508 or A, AA, AAA) that due to the cognitive load issue you
> > *may* not be in compliance - blanket claims of any of the
> > prepackaged
> > (or even "roll-year-own") solutions not-withstanding:
>
> I think you meant to say "might not", with which I agree. I have
> gotten from our conversations that we need to qualify our
> accessibility verbage to ensure that people understand that simply
> passing muster with automated checkers is just the beginning of the
> process, and that it's up to them to unserstand the finer points of
> the guidelines in the context of their own goals. But I do rather
> prefer to approach problems from a more positive orientation.
>
>
> > WAG Priority 2 - 12.3 Divide large blocks of information into more
> > manageable groups where natural and appropriate.
>
> You know, some parents raise their kids with that kind of
> approach :-)
> I would much rather have more clearly defined criteria :-)
>
>
> > WAG Priority 3 - 13.6 Group related links, identify the group (for
> > user agents), and, until user agents do so, provide a way to bypass
> > the group.
>
> Theoretically sound, but if the narrative section of a web page
> contains 20 or more links, simply separated by a few words, that gets
> around the ambiguity of them being a "group", or does it :-)
>
> My greatest aprehension is that as IE7 ramps up market share,
> it joins
> other modern browsers in supporting ":hover" by spec and that
> so-called "pure CSS menus" will spread like wildfire. That type of
> navigation will become a curse of unprecedented magnitude to
> usability
> and accessibility evangelists because the "suckers" have no way to be
> refined for use by even able-bodied people with a mouse :- ) Since
> there is a slight overlap between the standards and accessibility
> communities, I'm dying to see how that will play out.
>
> Another thing that I have a problem with are menu systems
> that attempt
> to behave like OS menus. It'll never happen unless those actual
> controls are someday made available to browsers. If a menu system
> requires that a user read an instructions page to learn - for that
> matter, if an accessibility scenario requires the same - then that
> would seem to create a real-world problem - one that looks great on
> paper but fails miserably in the field.
>
> --
> Al Sparber - PVII
> http://www.projectseven.com
>
>
>
>
>
>
>
>

From: ben morrison
Date: Tue, Aug 09 2005 11:09AM
Subject: Re: (The return of...) Accessible popup menus
← Previous message | No next message

On 8/4/05, Austin, Darrel < = EMAIL ADDRESS REMOVED = > wrote:
> Coincidently, after last weeks debate on DHTML fly-out navigation, I'm now
> at the point where I need to consider it for use on a couple of our sites.

Im in a rush but this recent thread (CSS drop down menus) on evolt
maybe of help to you:

http://lists.evolt.org/archive/Week-of-Mon-20050704/thread.html#173902

the thread runs into next week (last post)

http://lists.evolt.org/archive/Week-of-Mon-20050711/173951.html

ben