WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: (The return of...) Accessible popup menus

for

From: Al Sparber
Date: Aug 5, 2005 12:00PM

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