- From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
- Date: Sat, 4 Jun 2016 08:12:26 +0000
- To: "Gordon L. Potter" <gordon.l.potter@gmail.com>, Mark Sadecki <mark.sadecki@gmail.com>
- CC: David MacDonald <david100@sympatico.ca>, Taliesin Smith <talilief@gmail.com>, Roger Hudson <rhudson@usability.com.au>, "Bryan Garaventa" <bryan.garaventa@whatsock.com>, WAI Interest Group <w3c-wai-ig@w3.org>
- Message-ID: <SN1PR0301MB1981B92332019276803228BF985A0@SN1PR0301MB1981.namprd03.prod.outlook.>
Hi, The Menubar module within the js folder is meant to be scalable, so technically anybody can put whatever markup they wish within the A tags and it will still work accessibly. So it would be unreliable to put code to add aria-hidden for the menuIcon spans within the same module, because there is no guarantee that the developer would include the same span for this purpose. Still though, if somebody wanted to do this within this example, it could easily be added at the end of the setup.js file within the $(function(){ statement, like so: $('ul[role="menubar"] a > span.menuIcon').attr('aria-hidden', 'true'); As a reminder though, it is dangerous to use aria-hidden, so please verify any use of this with Visual ARIA to ensure that what is hidden is actually meant to be hidden. http://whatsock.com/training/matrices/visual-aria.htm The tabindex attribute is never going away, though it is a bad practice to use any numerical value greater than 0 as part of it’s use. All the best, Bryan Bryan Garaventa Accessibility Fellow SSB BART Group, Inc. bryan.garaventa@ssbbartgroup.com 415.624.2709 (o) www.SSBBartGroup.com From: Gordon L. Potter [mailto:gordon.l.potter@gmail.com] Sent: Friday, June 03, 2016 9:34 AM To: Mark Sadecki <mark.sadecki@gmail.com> Cc: David MacDonald <david100@sympatico.ca>; Taliesin Smith <talilief@gmail.com>; Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>; Roger Hudson <rhudson@usability.com.au>; Bryan Garaventa <bryan.garaventa@whatsock.com>; WAI Interest Group <w3c-wai-ig@w3.org> Subject: Re: accessible drop-down menus Thanks everyone for sharing. I wonder about one thing with the first example. <span class="menuIcon"></span> That's something people shouldn't have to read. Can you add <span class="menuIcon" aria-hidden="true"></span> I noticed icons do that. Could you jQuery and attribute to add aria-hidden="true" if the .menuIcon class is present? Any other ideas? I have one other question. Is tabindex="" going away in the future? Could one use something to traverse the node tree? Thanks again for sharing. On Thu, Jun 2, 2016 at 3:36 PM, Mark Sadecki <mark.sadecki@gmail.com<mailto:mark.sadecki@gmail.com>> wrote: Hi David, Thanks for sharing the video. It was good to hear your voice again. It’s been some time. An operating system setting is preventing you from accessing those controls with the keyboard in firefox. If you were a Mac OS X user who relied on keyboard only navigation, one of the first OS customizations you would make would be to change your Keyboard settings to move focus to All controls rather than just Text boxes and lists only. To do so, open up your System Preferences, then open up Keyboard, then open up the Shortcuts tab (because that is the most logical place to put such a setting <— sarcasm). At the bottom of the tab you will see a set of radio buttons with the label Full Keyboard Access. You will want to change that from Text boxes and lists only to All controls. You can also toggle this setting at any time using the Control + F7 key combination. Once you toggle this setting, you should be able to use Brian’s aria menu without a problem in Firefox with the keyboard. Best, Mark On Jun 1, 2016, at 10:21 PM, David MacDonald <david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote: Hi Mark Here's a video... feel free to let me know if there is something I'm missing... I know on a Mac with Safari, the tab key doesn't do much unless the user preferences have been adjusted... I didn't see anything like that of FF. http://davidmacd.com/video-demos/ff-dd/media/firexfox46-menu.mp4 And Bryan, you are one of the great contributors to open standards. thanks so much for your hard work. Cheers, David MacDonald CanAdapt Solutions Inc. Tel: 613.235.4902<tel:613.235.4902> LinkedIn <http://www.linkedin.com/in/davidmacdonald100> twitter.com/davidmacd<http://twitter.com/davidmacd> GitHub<https://github.com/DavidMacDonald> www.Can-Adapt.com<http://www.can-adapt.com/> Adapting the web to all users Including those with disabilities If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html> On Tue, May 31, 2016 at 6:42 PM, Taliesin Smith <talilief@gmail.com<mailto:talilief@gmail.com>> wrote: 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<mailto: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<mailto:bryan.garaventa@ssbbartgroup.com> 415.624.2709<tel:415.624.2709> (o) www.SSBBartGroup.com<http://www.ssbbartgroup.com/> From: Roger Hudson [mailto:rhudson@usability.com.au<mailto:rhudson@usability.com.au>] Sent: Saturday, May 28, 2016 2:25 PM To: 'Bryan Garaventa' <bryan.garaventa@whatsock.com<mailto:bryan.garaventa@whatsock.com>>; 'WAI Interest Group' <w3c-wai-ig@w3.org<mailto: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] 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] Sent: Friday, May 27, 2016 11:45 PM To: 'WAI Interest Group' <w3c-wai-ig@w3.org<mailto: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<http://www.usability.com.au/> Blog: www.dingoaccess.com<http://www.dingoaccess.com/> Twitter: http://twitter.com/rogerhudson Email: rhudson@usability.com.au<mailto:rhudson@usability.com.au>
Received on Saturday, 4 June 2016 08:12:59 UTC