Re: Keyboard Accessibility of Drop Down Menus

Dear Vivienne,

A side issue with pull-down menus is that they can be hard to use with Zoom technologies. With a high level zoom the user only sees a part of the menu, often only the first few letters of the link text. It is very easy for this type of user to tab or cursor down to below the bottom of the pull-down menu. To make this less likely the sub-menu must have a clear bottom border and adequate side space. If a zoom user strays beyond the menu focus area the whole sub-menu disappears and the use is left focused on some area of the underlying page.

With regard to technique you should use CSS not java in order to make it universally accessible. The pull-down sub-menu is hidden until the main menu item receives focus (:hover, :active and :focus pseudo-classes are required). Some designers try to hide the sub-menu by positioning it “off-screen” – this is not recommended as it can cause display glitches in some older browsers. Instead simply use css - display:none; to hide the sub-menu and display:block; to show the menu.

Regards
Richard

From: Vivienne CONWAY 
Sent: Wednesday, January 02, 2013 1:48 AM
To: Charles McCathie Nevile ; mailto:w3c-wai-ig@w3.org 
Subject: RE: Keyboard Accessibility of Drop Down Menus

Hi Chaals

Thanks so much for your response.  It makes perfect sense, and I really appreciate the assistance.

Regarding the 'confidential' thing and disclaimer at the bottom of my email - unfortunately it is standard 'university' operating procedure.  But, I do agree!



Regards

Vivienne L. Conway, B.IT(Hons), MACS CT, AALIA(cs)
PhD Candidate & Sessional Lecturer, Edith Cowan University, Perth, W.A.
Director, Web Key IT Pty Ltd.
v.conway@ecu.edu.au
v.conway@webkeyit.com
Mob: 0415 383 673

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.


--------------------------------------------------------------------------------
From: Charles McCathie Nevile [chaals@yandex-team.ru]
Sent: Wednesday, 2 January 2013 8:52 AM
To: w3c-wai-ig@w3.org list
Subject: Re: Keyboard Accessibility of Drop Down Menus


On Tue, 01 Jan 2013 23:49:13 +0100, Vivienne CONWAY <v.conway@ecu.edu.au> wrote:


  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.



cheers

Chaals


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com


--------------------------------------------------------------------------------
This e-mail is confidential. If you are not the intended recipient you must not disclose or use the information contained within. 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.

CRICOS IPC 00279B