- From: Taliesin Smith <talilief@gmail.com>
- Date: Tue, 31 May 2016 20:12:35 -0230
- 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>
- Message-ID: <CABu36yGCvLraVnBHGdMkC1YyKgpF1aBnbp_JKpe=ttp+hh+xxQ@mail.gmail.com>
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