RE: pulldown issue questions (resend)

"My current menu implements something like this, except that it only has one level.  I played with this demo and was a bit confused by its behavior.  I applaud the fact that it is keyboard accessible, but I didn't like the fact that I _had_ to use the keyboard to (for example) escape from a sub-menu.  I am used to being able to navigate sub-menus using only the mouse.  Is there some reason that this cannot be supported in this type of menu?"

It is okay for this type of implementation to support the mouse to close the menu when mousing out of the region. I've already added this functionality to the module on the live site to demonstrate this. 

However, there are some caveats to be aware of when doing this. This is okay on desktop machines that use the keyboard and a traditional mouse, but not well supported on touch screen devices because the act of using VoiceOver on iOS for example will fire these events and cause the menu to automatically close when trying to read it. VoiceOver will also fire onFocus and onBlur in the same manner, which is why all of these things must be considered when building auto-suggest combobox widgets as well. So at present the only semi-reliable method available is to check for the presence of a touch device and do one thing while another thing is done when this is not detected.

E.G Here is the code I added to make the menus close when the mouse leaves the menu container, which uses this logic to determine what type of device is being used.

mouseLeave: function(ev, dc){
	if (!('ontouchstart' in window || navigator.maxTouchPoints > 0 || navigator.msMaxTouchPoints > 0)){
		dc.close();
	}
},

This is based on the article at
https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/

Granted this solution is not perfect, such as if you have a computer that supports a touch monitor and a keyboard, but we don't have reliable event hooks for dealing with this as yet across devices and platforms.

"I was also perplexed by the fact that the page heading text "ARIA HORIZONTAL MENU ..." isn't selectable (i.e., webkit-user-select is disabled).  Is there some accessibility-related reason why this should be the case?"

That's strange, I have no idea why you are seeing this, I've gone through all of the CSS and there is no instance of -webkit-user-select or user-select in any of the files. There is no accessibility related reason why content would not be selectable.

By the way, the reference to "horizontal" was a typo since this is a vertical menu, which I've also corrected. :) 

"In these demos, I'm not sure how the typical web user is supposed to know that right clicking is _required_ to access the extra functionality.  I could put an explanation in a help page, but..."

That's a good question, and a broad one. Personally I haven't physically seen a computer menu since 1994, so how do sighted people generally know when there is a right-click menu attached to anything?

"More generally, I guess I'm hoping for something like "unobtrusive accessibility".  ARIA attributes and semantic HTML5 tags seem unobtrusive to me, but custom widgets that require right-clicking and/or keyboard interaction (with no obvious way for the user to know this) do not.  Am I missing something?"

First, it's important not to confuse functional accessibility with styling and content. Functional accessibility is absolutely required to make a widget accessible, but this is entirely separate from what that widget contains or what it looks like, even though these things are all related.

So when you refer to "unobtrusive accessibility", this is technically the holy grail of accessibility that may happen some day when accessibility APIs include integrated web components that automatically map to the platform APIs and that automatically interface with assistive technologies like screen readers. This is actually being worked on now at the W3C, but it's quite a ways off as yet.

So at present, the only other way of doing this to accomplish unobtrusive accessibility is to use a JavaScript layer that will automatically parse standard HTML markup and use this standard content to automatically configure and render complex interactive widgets that include all of the requisite focus handling and ARIA markup as needed to make it work accessibly, like this one:
http://whatsock.com/bootstrap/jquery/
(https://github.com/accdc/bootstrap-jquery )

Regarding content and styling, both of these things can be used to provide more intuitive UIs and widget layouts that will increase usability and accessibility, such as providing usability hints to sighted keyboard only users and the like.

It's important to note that content and styling changes like these are variable and easily tweakable to accomplish this upon widgets that are already functionally accessible. Whereas if you start out with an interactive widget that is not functionally accessible at the beginning, it will be much more difficult and sometimes impossible to make it so.



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com

-----Original Message-----
From: Rich Morin [mailto:rdm@cfcl.com] 
Sent: Saturday, February 18, 2017 7:06 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: WAI Interest Group <w3c-wai-ig@w3.org>; Amanda Lacy <lacy925@gmail.com>
Subject: Re: pulldown issue questions (resend)

> On Feb 17, 2017, at 16:40, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com> wrote:
> Are you referring to a single click menu like the following?
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Vertical%20(Intern
> al%20Content)/demo.htm

My current menu implements something like this, except that it only has one level.  I played with this demo and was a bit confused by its behavior.  I applaud the fact that it is keyboard accessible, but I didn't like the fact that I _had_ to use the keyboard to (for example) escape from a sub-menu.  I am used to being able to navigate sub-menus using only the mouse.  Is there some reason that this cannot be supported in this type of menu?

I was also perplexed by the fact that the page heading text "ARIA HORIZONTAL MENU ..." isn't selectable (i.e., webkit-user-select is disabled).  Is there some accessibility-related reason why this should be the case?

> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Variation%20ARIA%2
> 0Tabs%20With%20Right%20Click/demo.htm
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Variation%20ARIA%2
> 0Tree%20With%20Right%20Click/demo.htm

In these demos, I'm not sure how the typical web user is supposed to know that right clicking is _required_ to access the extra functionality.  I could put an explanation in a help page, but...

More generally, I guess I'm hoping for something like "unobtrusive accessibility".  ARIA attributes and semantic HTML5 tags seem unobtrusive to me, but custom widgets that require right-clicking and/or keyboard interaction (with no obvious way for the user to know this) do not.  Am I missing something?

> All of these differences are covered in the ARIA Menu Role Matrices 
> table at http://whatsock.com/training/matrices/#menu

That's a nice resource; thanks!

-r

P.S.  I used Google Chrome Version 55.0.2883.95 on Mac OS X 10.10.5 to try out these demos.

 -- 
http://www.cfcl.com/rdm           Rich Morin           rdm@cfcl.com
http://www.cfcl.com/rdm/resume    San Bruno, CA, USA   +1 650-873-7841

Software system design, development, and documentation

Received on Sunday, 19 February 2017 07:56:17 UTC