RE: Question about event bubbling in FF versus IE and Chrome?

Sorry, I forgot to write the question, shouldn't canceling onMouseUp prevent onClick from triggering in the chain?

Thanks,
Bryan

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Monday, January 26, 2015 10:06 PM
To: WAI Protocols & Formats
Subject: Question about event bubbling in FF versus IE and Chrome?

Some of you may have noticed that the menus didn't appear to open in Firefox, which I fixed tonight, but this appears to be the result of an event bubbling discrepancy between FF and other browsers.

I'm not sure if this is intentional or not, so I wanted to ask.

Basically, the attached right click menus work by processing the onMouseUp handler and then use event.preventDefault() to cancel further processing, and an onClick event is attached to the document so that if you click outside of the menu it will cause it to close.

In IE and Chrome this works correctly, and the onClick is not continued after preventDefault is invoked, but in FF, the onClick is fired on the document regardless.
As a result, the menu was closing as soon as it opened in FF.

I've attached a demo that shows the bubbling behavior, if you right click the edit field, it throws a bubbling alert in FF, but not in IE or Chrome.

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com]
Sent: Monday, January 26, 2015 11:20 AM
To: Fred Esch; WAI Protocols & Formats
Subject: RE: Universal Menus and a research script

Thanks, that does help a lot :)

> I found the way to close the menu using the keyboard is using the tab key, which took me back to the button opening the menu. I found this non-intuitive.
> I would have expected the left arrow to close the menu.

That's true, the Tab key will close the menu and set focus back to the triggering element, so too will pressing Escape, as with a standard context menu.

Basically, I designed the menu module to emulate the functionality of a standard context menu on Windows, so if you right click anywhere on a webpage, then press the Left arrow in the top menu, focus remains within the menu and it does not close; the same is true for pressing Right on a menu item that does not open a submenu.

I can see how pressing Tab may seem strange to set focus back to the triggering element, but this is the only way to ensure keyboard support within variable implementations, because the menu container element is actually appended to the Body element to prevent CSS inheritance issues during rendering, so if you don't capture the Tab key in this case, it will non-intuitively move into the address bar after the menu closes. Plus, this can be applied to any active element type, such as complex widgets like ARIA Trees, Grids, Tabs, and so on, where it is important to return focus to the triggering element after the menu closes. So this design always does so, then leaves further navigation up to the user.

In the case of a Menubar however, I can see the benefit of setting the Left arrow to close the currently open menu then open the one directly to the left, and the same with pressing the Right arrow on a non-submenu menu item to open the next menu to the right, which is how it currently works within the Windows menubar.

This is simple to accomplish, by doing the following.

- Build a standard menubar from left to right including role=menubar and role=menuitem, then set the Left and Right arrow keys to move focus between each menuitem element.
- Programmatically bind a menu to each menuitem element using the method shown in the previously attached txt file, which automatically supports the Down arrow for opening the attached popup menu.
- Within the $A.setMenu function, simply modify the runAfter function like so (which recursively executes after each menu is rendered).

runAfter: function(dc){
                // Check if this is the top level menu instance
                if (dc == dc.top){
                                // Bind the Left arrow key to each role=menuitem node
                                $A.bind($A.query('*[role="menuitem"]', dc.containerDiv), 'keydown', function(ev){
                                                if ((ev.which || ev.keyCode) == 37){
                                                                // Close the current top level menu
                                                                dc.top.close();
                                                                // Use dc.top.triggerObj to determine the previous menu in the menubar, then open the next menu to the left
                                                                $A.trigger(prevMenuItemNode, 'popupmenu');
                                                                ev.preventDefault();
                                                }
                                });
                }
                // Do the same here for pressing Right on non-submenu triggering elements to open the next menubar popup menu.
                // E.G binding to '*.link[role="menuitem"]'
}

This system is a simple one, but effective.

> The button opening the menu does not have an menu indicator; the sub menus have little arrows to show that they can open I would add an indicator on the button.

Absolutely, will do!

> I would also switch from using a long skinny arrow to using the unicode black down pointing arrow (' \25BC' or ▼ or ▼ )
> as it is widely used.

Good point, I use CSS :before to render this, so I'll update the content value to use this other char instead.

> Finally, I would suggest you WordPress code or plug in for the menu.  WordPress allows developers to programmatically create menus,
> but they are silent for blind users and when generating multi-level menus don't generate submenus that a sighted keyboard user can use.

I'd be happy to, this code is all modular so it is easy to tie into templates. I'm just not sure how WordPress does so or who at WordPress could help with this. If anybody can help with this, I'd be happy to get this moving.

Thanks again,
Bryan

From: Fred Esch [mailto:fesch@us.ibm.com]
Sent: Monday, January 26, 2015 6:48 AM
To: WAI Protocols & Formats
Subject: Re: Universal Menus and a research script


Bryan,

Thanks for your efforts. I find menus somewhat problematic in that some folks want to put a link + menu on the main menu bar or use css with multi-level menus. I never found a practical solution for either situation. In CSS 4 focus-within should help menus that depend on the bubbling behavior of hover work for focus and James Craig has been nice enough to put a bug in web-kit to get it done. But I haven't seen additional traction on getting focus-within implemented. Yours is the first multilevel menu that behaves well.

I looked at http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Vertical%20%28Internal%20Content%29/demo.htm. Overall I liked the menu as it provides a reliable way to provide the menu functionality for keyboard users (sighted and blind). I do have a few picky issues. I found the way to close the menu using the keyboard is using the tab key, which took me back to the button opening the menu. I found this non-intuitive. I would have expected the left arrow to close the menu. The button opening the menu does not have an menu indicator; the sub menus have little arrows to show that they can open I would add an indicator on the button.  I would also switch from using a long skinny arrow to using the unicode black down pointing arrow (' \25BC' or ▼ or ▼  ) as it is widely used.

Finally, I would suggest you WordPress code or plug in for the menu.  WordPress allows developers to programmatically create menus, but they are silent for blind users and when generating multi-level menus don't generate submenus that a sighted keyboard user can use. WordPress is widely used and some users won't fix their menus even if given the HTML, css and JavaScript to do so. But if you give them an accessible version you may see lots of non-commercial sites become more PwD friendly.
Regards,

Fred Esch
Accessibility, Watson Innovations
AARB Complex Visualization Working Group Chair
W3C SVG A11y Task Force
[IBM Watson Group]

[Fred]



[Inactive hide details for Bryan Garaventa ---01/25/2015 02:46:48 PM---Hello, Recently I wrote a LinkedIn article that describes]Bryan Garaventa ---01/25/2015 02:46:48 PM---Hello, Recently I wrote a LinkedIn article that describes how to make the universal application of A

From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>
To: W3C WAI Protocols & Formats <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>
Date: 01/25/2015 02:46 PM
Subject: Universal Menus and a research script

________________________________



Hello,
Recently I wrote a LinkedIn article that describes how to make the universal application of ARIA Menus accessible
https://lnkd.in/bJWmDH2
Which uses all of the implementation details that we've been discussing in the APG calls as a proof of concept.

I've attached a page script that can be used to implement different types of triggering elements to see how they work when popup ARIA Menus are attached to them, which may be helpful for AT compatibility testing purposes.

The LinkedIn article includes various implementation examples, but a couple appear to expose some platform issues on iOS, tested using the latest iPhone6, that I wished to get James' opinion on in case I'm missing something in the markup.

The first is an ARIA Textbox, at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Variation%20Simulated%20Edit%20With%20Right%20Click/demo.htm
Which uses the contenteditable attribute to make a Div editable, plus all of the ARIA textbox attributes.

When I attempt to edit this using iOS by tapping it as with all edit fields, it shows the virtual keyboard, but typing into it with VoiceOver running just makes a bonking noise and nothing is typed into the field. Is there something special in the markup that needs to be done in order to get iOS to enter text into a contenteditable container?

The second is an ARIA Tree, at
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Variation%20ARIA%20Tree%20With%20Right%20Click/demo.htm
Which includes dynamically displayed hamburger icons appended to the LI nodes within the tree to provide tappable menu triggering elements for touch screen support on smaller devices. This is seen after navigating into the leaf nodes of the tree. These icons are marked up as ARIA Buttons.

In order to ensure the proper reading order when swiping, these elements need to be inline with their related role=treeitem nodes.
However, on iOS, it appears that they are entirely omitted from the Accessibility Tree, making it appear from a VoiceOver perspective that they don't exist at all. This only appears to happen when they are inserted within the markup of the role=tree structure. Can you confirm this? Is this assessment correct, or is something else causing this?

All the best,
Bryan
[attachment "menu_test.txt" deleted by Fred Esch/Arlington/IBM]