WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: avoiding tabbing through drop downs

for

From: Geof Collis
Date: Mar 5, 2010 9:00PM

Do you want it on your desk by the morning?

At 09:35 PM 3/5/2010, you wrote:
>Good evening Geof,
>
>My question to you is, can you please explain how you solve the
>problem of displaying sub-menus on the sites that you develop, or in
>the open source tools to which you are a contributor? Can you
>please explain the pros and cons of the approach you take as they
>relate to universal design and accessibility? In your response can
>you please explain how you solve the problem of assistive technology
>and keyboard only users needing to navigate through multiple
>sub-menus full of links on the main page, and any subsequent pages,
>of these sites and tools?
>
>Thanks,
>Everett Zufelt
>http://zufelt.ca
>
>Follow me on Twitter
>http://twitter.com/ezufelt
>
>View my LinkedIn Profile
>http://www.linkedin.com/in/ezufelt
>
>
>
>On 2010-03-05, at 9:26 PM, Geof Collis wrote:
>
> > Then put the ramp at the front of the building so we all have equal
> > access, Debbie has the right idea.
> >
> > You say its just one click but if you have 20 sub menus then that is
> > 20 clicks, not 1.
> >
> >
> > cheers
> >
> > Geof
> > At 09:13 PM 3/5/2010, you wrote:
> >> On Fri, Mar 5, 2010 at 4:22 PM, Geof Collis < <EMAIL REMOVED> > wrote:
> >>> Are you saying that only people who use a mouse can access the whole
> >>> list while screen readers and keyboard users have to take extra
> >>> measures to access the same list/pages?
> >>
> >> If by "extra measures" you mean clicking a link, then yes. The
> >> content, links, and overall functionality aren't any different - they
> >> are just presented in slightly different places.
> >>
> >> This is just one of several possible approaches (which have been
> >> hashed about on this list several times). This approach does take one
> >> additional step, but my experience has shown that this extra step is
> >> often much less burdensome than the alternatives - either forcing the
> >> user to listen to *every* navigation item (and probably without any
> >> structure or semantics as to the hierarchy) or coming up with some
> >> distinct mechanism of providing keyboard navigation through the menu
> >> (which keys open the menu, which expand and collapse menus, etc. -
> >> there's no standard for these things).
> >>
> >> Plus it provides additional functionality for those without javascript
> >> or ARIA-supported technologies, search engines, or those who just
> >> happen to click the main menu item perhaps without noticing the
> >> drop-down menu.
> >>
> >> If ARIA can be adequately used to provide navigation through such a
> >> menu, this would be a wonderful way to enhance a standard, accessible
> >> navigation, but I wouldn't yet recommend having ARIA support be a
> >> requirement for something as critical as a main navigation.
> >>
> >>> It's like telling a wheelchair user that the building is accessible,
> >>> they just have to come in through the back door.
> >>
> >> No, it's like providing a ramp, an escalator, and an elevator. The
> >> user can use the means of getting there that works best for them. Not
> >> providing a fallback would be like forcing a wheelchair user to use
> >> the escalator. The key is to get to the users to the same place - they
> >> just can choose to get there slightly differently. I personally tend
> >> to click main menu items when I see drop-down menus as I prefer
> >> navigating static content over playing the "mouse through the menu
> >> maze" game.
> >>
> >> Jared
> >>