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> 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>
> 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
>
>
> *Can**Adapt* *Solutions Inc.*
> Tel:  613.235.4902
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
> 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>
> 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> 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 <http://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
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>