W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2013

Re: Keyboard Accessibility of Drop Down Menus

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Wed, 02 Jan 2013 00:52:05 +0100
To: "w3c-wai-ig@w3.org list" <w3c-wai-ig@w3.org>
Message-ID: <op.wp9a83a6y3oazb@v10-167-103.yandex.net>
On Tue, 01 Jan 2013 23:49:13 +0100, Vivienne CONWAY <v.conway@ecu.edu.au>  

> Hi all
>I've been looking through the IG archives and haven't seen an answer to  
> this question, however if I've missed it please excuse my ignorance.
>The question arose recently about whether a drop down menu that  
> activates upon mouseover is accessible and should fail 2.1.1 Keyboard  
> Accessibility.

It seems the question is back-to-front. If the functionality is not also  
available from the keyboard (and that depends on the particular  
implementation - plus how you decide what systems are in scope for your  
claim anyway), then it fails. But the fact that you *can* do something  
with a given behaviour isn't, in itself, a reason to fail anything.

> In practicality, the use can navigate to the tab and press 'enter' and  
> go to that page and read what is available and usually see the same  
> information they could >get from the drop down menu.  However it could  
> be argued that as they have to perform this extra step and then  
> backtrack if the required information was not in >that tag - that it is  
> not providing the same functionality and therefore fail G202.

(To be pedantic, G202 is a technique to pass the requirements 2.1.1 and  
2.1.3, not a requirement in itself). I generally consider that having a  
less efficient, but "reasonably practical" method, is good enough to pass  
a level A requirement. I note that this is something I have made up for  
myself based on interpreting the goals of level A (actually, as originally  
developed for WCAG 1.0 and subsequently adopted) rather than something  
that I can support through the text as written.

So I believe that having the link atthe head of the menu be accessible,  
and being able to follow it and get to a page that has all the options of  
the submenu clearly displayed and accessible, passes 2.1.1 - although it  
is a long way from best practice.

For 2.1.3 the requirement is level AAA - for that I consider that you have  
to do a good job, at a high level of efficiency. And I would argue that  
requiring an extra link to be followed essentially breahces the "no  
specific timing" requirement because it is dependent on following the link  
at a specific time when you are connected. That's the pedantic legalistic  
argument I would use to fail a site - backed up by the fact that I don't  
think such a poor technique meets the general quality requirement I  
consider is implicit in level-AAA.

> If you consider that this is a fail, would it then pass if an  
> 'onkeypress' or similar were added as a redundant control.

Implementations that work with a keyboard don't fail (by logic ;) ). But  
onKeyPress generally seems to appear in implementations that actually fail  
for many platforms, solving things only for the most common setups. Using  
Javascript to control interaction, especially keyboard interaction, is  
generally a bad idea for accessibility. Many people who implement this  
assumes that the user intereracts with a particular OS-level keyboard in a  
particular way. It is a bad assumption that leads to problems.

There are various ways to build drop-down menus that work with keyboards -  
I'll leave it to people more expert than I in the details to opine about  
specific approaches that are better or worse, and what problems each  
solves and exposes (touch screens? non-standard keyboards? conflicting  
with assistive technology?).

>> This email is confidential and intended only for the use of the  
>> individual or entity named above. If you are >not the intended  
>> recipient, you are notified that any dissemination, distribution or  
>> copying of this email is >strictly prohibited. If you have received  
>> this email in error, please notify me immediately by return email >or  
>> telephone and destroy the original message.

If this mail is confidential, there is a problem. If it isn't, there is a  
problem saying it is.
>> This e-mail is confidential. If you are not the intended recipient you  
>> must not disclose or use the information contained within.

Really? On what basis do you make that claim?

> If you have received it in error please return it to the sender via  
> reply e-mail and delete any record of it from your system. The  
> information contained within is not >the opinion of Edith Cowan  
> University in general and the University accepts no liability for the  
> accuracy of the information provided.



Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com
Received on Tuesday, 1 January 2013 23:52:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:47 UTC