WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: mouseover/hover and keyboard accessible expandablemenu?

for

From: Nancy Johnson
Date: Nov 6, 2009 10:40AM

This is a very interesting perspective

"3. Hide the sub-menu items from screen reader and keyboard access and
make the main menu item a standard link to a page which provides
redundant access to each of the sub-menu items. I can find no problems
with such an approach. The only drawback with such an approach is that
it is one extra step - hardly as problematic as either of the other
options, in my opinion."


I have a brand new site, our job is to put a CMS system behind it.
We got photoshop comps and html static pages from the design
development company.

My first assignment was to make an assessment based on the html that I
received

When it came to 508, I found some jquery elements were not keyboard
accessible including the drop down elements in the global navigation,
but I thought that if the navigation in the landing pages were 100%
accessible then that is OK, which I documented.

The client now wants the left-hand to expand by hover and in the
expansion not only have a link but a description of the link.

I can only put in writing my 508 findings and the client has to decide
hence my query.

This brings up another issue. Unfortunately to most developers 508 in
an intellectual issue, and if a page passes any of the 508 validators,
then the page is accessible, but many of these validators do not check
for AJAX, jquery and other functionality that is commonly used, other
than manually checking pages, are there any validators addressing
these issues.

How to tell a client in fact that this passes the validator but is not
usable or accessible to those with major mobility and visual issues?

Nancy

On Fri, Nov 6, 2009 at 11:50 AM, Jared Smith < <EMAIL REMOVED> > wrote:
> On Fri, Nov 6, 2009 at 9:21 AM, Karl Groves
> < <EMAIL REMOVED> > wrote:
>
>> I do not agree with this statement. While I would agree that the root
>> menu item should be a real link to an actual destination, I hardly regard
>> it as accessible or usable to not provide programmatic access and visual
>> focus to sub-menu options.
>
> There are really only three approaches to such menu accessibility:
>
> 1. Force the user to listen to and navigate through all menu items.
> This is not efficient. It is certainly not the same experience sighted
> and mouse users have. The hierarchy of such menus is hard to convey to
> someone listening to them. It's overwhelming and confusing. Hardly
> accessible.
>
> 2. Program the menu to be technically keyboard/screen reader
> accessible. The problem with this approach is that there is no
> standard way of doing so. Do you open the menu with space or enter? Do
> the arrow keys expand/collapse the menu? Up and down or left and
> right? How are you to know if you can't see it? And again, hierarchy
> and semantics are nearly impossible to convey with such menus. Without
> standard controls, trying to make complex menus accessible is not
> likely to result in a good experience. It may be technically
> accessible, but effectively a usability nightmare.
>
> 3. Hide the sub-menu items from screen reader and keyboard access and
> make the main menu item a standard link to a page which provides
> redundant access to each of the sub-menu items. I can find no problems
> with such an approach. The only drawback with such an approach is that
> it is one extra step - hardly as problematic as either of the other
> options, in my opinion.
>
> The key here is getting users to the content in an efficient and
> effective way. We shouldn't try to force the same menu experience on
> them no more than we drag wheelchairs up the stairs in order to give
> them the same experience of getting to the second floor.
>
> Jared Smith
> WebAIM
>