Re: accessible drop-down menus

Thank you for the reply.  I appreciate the lesson.  I'll do some research.

On Sat, Jun 4, 2016, 4:13 AM Bryan Garaventa <
bryan.garaventa@ssbbartgroup.com> wrote:

> No worries, thanks again for testing it out :)
>
> If we don't work together to validate what works, then it's difficult for
> anybody to agree on anything.
>
> Kind regards,
> Bryan
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> bryan.garaventa@ssbbartgroup.com
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> From: David MacDonald [mailto:david100@sympatico.ca]
> Sent: Friday, June 03, 2016 9:23 AM
> To: Mark Sadecki <mark.sadecki@gmail.com>
> Cc: 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 Mark
>
> My Twitter feed talks about my journey into the Mac world after 25 years
> Windows. I guess each OS has its own strengths and weaknesses...
> historically Windows has been where the accessibility is but that is
> changing. In general, I love my Mac.
>
> Suppressing keyboard functionality and hiding it in a weird place seems
> like odd quirky behaviour, and thanks for pointing it out to me... why they
> would make a default setting like that is beyond me, but now I know...
> thanks for my first embarrassing moment in my new "religion" <smile>
>
>
> Cheers,
> David MacDonald
>
> CanAdapt Solutions Inc.
> Tel:  613.235.4902
> LinkedIn
>
> twitter.com/davidmacd
> GitHub
> 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
>
> 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
>
> CanAdapt Solutions Inc.
> Tel:  613.235.4902
> LinkedIn
>
> twitter.com/davidmacd
> GitHub
> 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
>
> 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
>
> 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]
> 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>
> 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
>
>
>
>
>
>
>