W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2016

Re: accessible drop-down menus

From: Taliesin Smith <talilief@gmail.com>
Date: Tue, 31 May 2016 20:12:35 -0230
Message-ID: <CABu36yGCvLraVnBHGdMkC1YyKgpF1aBnbp_JKpe=ttp+hh+xxQ@mail.gmail.com>
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: Roger Hudson <rhudson@usability.com.au>, Bryan Garaventa <bryan.garaventa@whatsock.com>, WAI Interest Group <w3c-wai-ig@w3.org>
Thanks Bryan for the links to the ARIA articles!

Taliesin

On Sun, May 29, 2016 at 2:07 AM, Bryan Garaventa <
bryan.garaventa@ssbbartgroup.com> wrote:

> “With your menu, would it cause any problems if rather than switching
> between tabindex=-1 and tabindex=0 for the main navigation items (depending
> on which has focus), they all just use the tabindex=0 attribute so that the
> user can tab directly from one main nav item to the next?”
>
>
>
> Unfortunately this is one of those things that seems to be a logical
> problem for some, where the logical fix then causes problems for others.
>
>
>
> So in the case of tabbing, the feedback received using ARIA Menubar and
> Menu roles by non-sighted screen reader users is that with every tab press
> it sounds like the user is tabbing to a different menu, making it
> impossible for the blind user to differentiate one menu construct versus
> several in the same area, which leads to confusion and user error.
>
>
>
> This is the primary reason why these roles, such as ‘menubar’, ‘menu’,
> ‘tablist’, ‘radiogroup’, ‘listbox’, ‘tree’, and others are meant to have
> one tab stop, because they map to the same control types on the platform OS
> that provide the same keyboard paradigm for their users, meaning that
> something that sounds like a Menu needs to act exactly like a Menu,
> otherwise it causes confusion when it doesn’t.
>
>
>
> Also, when everybody programs these controls to behave differently, there
> is no way for any end user on the web to understand how these controls are
> supposed to act on any webpage, because nothing is consistent.
>
>
>
> Consistently followed and reliably programmed role and keyboard design
> patterns would go a long way towards helping others to better understand
> these controls and how to use them.
>
>
>
> Recently we published a couple of articles regarding ARIA Tabs that
> illustrate why these distinctions are important.
>
> E.G
>
> Danger! Testing Accessibility with real people — Medium
>
>
> https://medium.com/@LeonieWatson/danger-testing-accessibility-with-real-people-4515f72db648#.k0ng5llrc
>
> From HTML to ARIA Tabs, A Travelog | HackPoets
>
>
> https://hackpoets.wordpress.com/2016/05/10/from-html-to-aria-tabs-a-travelog/
>
>
>
> Hopefully this helps to explain the logic a bit.
>
>
>
> All the best,
>
> Bryan
>
>
>
>
>
>
>
> Bryan Garaventa
>
> Accessibility Fellow
>
> SSB BART Group, Inc.
>
> bryan.garaventa@ssbbartgroup.com
>
> 415.624.2709 (o)
>
> www.SSBBartGroup.com
>
>
>
> *From:* Roger Hudson [mailto:rhudson@usability.com.au]
> *Sent:* Saturday, May 28, 2016 2:25 PM
> *To:* 'Bryan Garaventa' <bryan.garaventa@whatsock.com>; 'WAI Interest
> Group' <w3c-wai-ig@w3.org>
> *Subject:* RE: accessible drop-down menus
>
>
>
> Thanks Bryan,
>
>
>
> This example is very nice and seems keyboard and screen reader accessible
> to me. It is similar (but not the same) as the Canadian Gov Web
> Experience Toolkit Working Examples Menu (
> https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html)
>
>
>
> It appears your menu follows the DHTML guidelines which suggest that only
> the first (or just one) of the main navigation items should be accessible
> with the tab key, with the others accessed via the arrow keys (i.e. more
> follows the standard paradigm used with computer applications such as
> Window Explorer). However, from my testing with keyboard users (with and
> without a screen reader) I find that a significant proportion expect to be
> able to tab to all the main navigation items in a web page, and become a
> little disorientated when this doesn’t happen. And in some cases, either
> they don’t think to use the arrow keys or don’t know they can be used for
> this purpose.
>
>
>
> With your menu, would it cause any problems if rather than switching
> between tabindex=-1 and tabindex=0 for the main navigation items (depending
> on which has focus), they all just use the tabindex=0 attribute so that the
> user can tab directly from one main nav item to the next?
>
>
>
> Thanks,
>
>
>
> Roger
>
>
>
> *From:* Bryan Garaventa [mailto:bryan.garaventa@whatsock.com
> <bryan.garaventa@whatsock.com>]
> *Sent:* Sunday, 29 May 2016 3:27 AM
> *To:* 'Roger Hudson'; 'WAI Interest Group'
> *Subject:* RE: accessible drop-down menus
>
>
>
> The following does this.
>
> https://github.com/accdc/aria-menubar
>
> All the best,
>
> Bryan
>
>
>
> *From:* Roger Hudson [mailto:rhudson@usability.com.au
> <rhudson@usability.com.au>]
> *Sent:* Friday, May 27, 2016 11:45 PM
> *To:* 'WAI Interest Group' <w3c-wai-ig@w3.org>
> *Subject:* accessible drop-down menus
>
>
>
> Hi
>
> I am looking for examples of main site navigation systems where a main
> (top) navigation item in the menu is able to link to a landing (section)
> page, and open a drop-down menu with sub-menu choices. Can anyone suggest
> examples that are both intuitive to use with the keyboard and accessible
> with a screen reader.
>
>
>
> Thanks,
>
> Roger
>
>
>
> *Roger Hudson*
>
> Web Usability
>
> Mobile: 0405 320 014
>
> Phone: 02 9568 1535
>
> Web: www.usability.com.au
>
> Blog: www.dingoaccess.com
>
> Twitter: http://twitter.com/rogerhudson
>
> Email: rhudson@usability.com.au
>
>
>
>
>
Received on Tuesday, 31 May 2016 22:43:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 31 May 2016 22:43:06 UTC