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

I don't think you should expect click events to be suppressed by preventing
the default action of mouseup. Here's a simple test case which shows that
click still occurs, even in Chrome (I didn't test in other browsers):
http://jsbin.com/xiqevudupi/1/edit?html,js,output

On Tue, Jan 27, 2015 at 1:05 AM, Bryan Garaventa <
bryan.garaventa@ssbbartgroup.com> wrote:

>  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 &#9660; or &#x25bc; )
>
> > 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 <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 &#9660; or &#x25bc;  ) 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
> [image: IBM Watson Group]
>
> [image: Fred]
>
>
>
> [image: 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>
> To: W3C WAI Protocols & Formats <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]
>