WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Austin, Darrel
Date: Aug 9, 2005 11:09AM



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