Re: Keyboard Accessibility of Drop Down Menus

Hi Vivienne
The menu is probably activated with an onMouseOver event (and cancelled
with onMouseOut). Using onFocus and onBlur in conjunction with onMouseOver
and onMouseOut will provide equivalent keyboard functionality.

Kind regards
Harry



On 2 January 2013 02:48, Vivienne CONWAY <v.conway@ecu.edu.au> wrote:

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