Review editor menubar example (menubar-2.html) #144
Comments
|
The code and role usage looks good, plus the focus movement. One note, at present the spec doesn't support the use of aria-expanded on role=menuitem, however this is an important addition that needs to be made in the spec to support touch screen devices. To this end, the following bug has been submitted: |
|
The menu labels include the icon character for indicating the pull down: The edit field with the sample text needs a label. |
|
@accdc, you said focus movement is good. I am seeing two issues that are inconsistent with the design pattern. Are you experiencing these?
|
|
Regarding 1, I did notice that too, however there may be a difference between what a person does when pressing Enter on a top level menubar menu item versus pressing the downarrow on it, assuming that the menubar is horizontal. It may sound non-intuitive, but pressing on a top level menubar item as implemented on the web often navigates to another landing page, whereas pressing down will open the attached submenu, so we need to figure out a way of dealing with these circumstances. Regarding 2, personally I think it makes more sense when right is pressed and there is no submenu present to move focus to the next top level menu item in the menubar, otherwise it is difficult to know what menu is opening otherwise. I know this deviates from the Windows menubar functionality slightly by doing this, but I don't see any problem with it personally because I think it provides a more intuitive experience. Otherwise, if the user doesn't know what menu they are in, then they have to press Escape to figure out what it is, which is what happens to me on Windows all the time. |
|
Bryan, thank you. So, we are seeing the same behavior. The purpose of the example is to demonstrate the design pattern. So, it needs to be consistent with the pattern, and these two behaviors are not consistent. The only examples that should deviate are additional supplementary examples that serve the purpose of demonstrating what to do in circumstances that compel an alternative approach. For point 1 about the behavior of the enter key in the menubar, please see the last note in the design pattern keyboard section. It addresses the scenario you describe. We may want to have an example of that behavior, but not on this menubar. That would be more appropriate for the page demonstrating the navigation menubar. However, I am not sure we want to even demonstrate that ... it is not something we should promote. If we were to include it, we should first demonstrate more accessible alternative solutions to the same problem. For point 2 about pressing left/right when focus is in a vertical menu opening from a horizontal menubar, it sounds like you are saying we should reconsider the guidance in the pattern. None of the desktop platforms behave like this menubar. However, Mac OS is similar. The difference is that the submenu associated with the newly focused item in the menubar should be expanded. Visually, I imagine it is a bit weird for it not to be. As you describe, moving focus into the parent menubar has some advantages for screen reader users. I would be fine with changing this aspect of the guidance if we emulate the Mac behavior. In reality, both work fine, and screen readers can handle either. My main point is that the example needs to be consistent with the guidance in the pattern. |
|
Regarding point 1, sounds good to me if we limit this example to support both Enter plus Downarrow to invoke and set focus into the menu. I understand the dislike of the more complex dual functionality design pattern, but we should work on one of those too, simply so that we can get screen readers to properly support it in the future, a large part of this being so that screen readers only enter Forms Mode or Applications Mode when Enter is pressed on a menu while navigating in Virtual Cursor mode so that the menu item is not automatically clicked. Otherwise it is impossible to enable this functionality when needed because the onClick is always invoked on the menu item and causes a new page to load every time. This is what currently happens in both JAWS and NVDA. Regarding point 2, I personally would prefer changing the design pattern guidance to match the functionality in this demo when Left and Right is pressed, instead of automatically expanding a submenu as it states currently. It would be good to talk about this together with all of the others during the next meating though to weigh pros and cons. |
|
Bryan, not sure you completely understood what I said on point 2. The Mac OS menubar interaction model is just like this example except that the submenu is visually expanded while the focus moves like it does in this example. It works like:
This interaction model retains all the advantages you describe while behaving in a way that is consistent with a major desktop platform. And, I believe there are some Windows programs that behave in this way even though Windows does not. The only part of that model that is missing from this example is step 5. Going with this model would be a rather minor change in the pattern guidance, which itself is not binding. I am comfortable making the change if we get enough people chiming in here. I agree that it has screen reader user advantages. It is worth noting that ARIA menubars are more friendly than native Windows menubars because we can report the expanded/collapsed state of submenus of a menubar. With respect to how the enter key behaves in JAWS and NVDA while in reading mode, we have a larger issue related to their notion of composites. They both lack good support for the idea of moving focus to a composite element without activating an element within it. It is silly to rely on tab for that functionality. The obvious simple answer is to change what the enter key does. But, this applies to all kinds of composites from menus to trees to grids and even toolbars, which are not technically composites but usually manage focus. This topic is already on my screen reader support list. |
|
Yes indeed, I understood but didn't write that very clearly. If others are in agreement too, I support changing the guidance to illustrate this updated functionality as well. If you want to propose to the screen reader venders that Enter should activate Forms/Applications Mode to allow for the correct keyboard functionality afterwards when this is pressed in Virtual Cursor mode, which I agree is applicable to all of the interactive widget roles, I will happily jump on the bandwagon in support since we really need this sooner than later. |
|
This |
|
Would you please change how the menu behaves when right arrow is pressed when focus is in a submenu on an item that does not have a submenu? For example, say the focus is in the font submenu on the "Sans-serif" item and you press right arrow. Currently, the focus moves to the style item in the menubar without expanding the style submenu. Could you make it so the focus movement is the same, but the style menu is expanded? Similarly for left arrow. However, for left arrow, the behavior is the same regardless of what kind of item has focus. Use the guidance for left and right arrow in this branch: |
|
Please look at what I did to the mnavigation menubar example with commit 6a24c6c Can you do the same with this text formatting menubar example so it conforms to our example template? Please note that the links to aria-practices.html can not have the file name in them. That is because, when the APG is published, the file name changes to index.html. So, those links work in gh-pages, but they will not work in rawgit or in your local system. |
|
@mcking65 @accdc @jongund @jnurthen I did not realize till now that we have discussed this topic here. I should be "watching" this repo.
or -Option 2: make the same as revised menubar1 example focus management. say the focus is in the font submenu on the "Sans-serif" item and you press right arrow. move the focus in the first item of the "style/color", which is "bold" while the style menu is expanded. (I vote for this option since it is consistent with menubar1 focus management) Please let me know what the decision is. |
|
When using with JAWS, it seems to me that the revised navigation menu example is currently behaving like option 1, not option 2. Option 1 is what we decided on for the recommended behavior. It is the behavior described in the |
|
Functionality for right/left arrow is the same as menu bar1 example now. I am still editing html section according to the template. Here is the revised menubar2 example |
|
Reviewed ARIA Menubar Example: menuitemradio and menuitemcheckbox (http://w3c.github.io/aria-practices/examples/menubar/menubar-2/menubar-2.html). "Checked" indicator for menuitemcheckboxes within the menuitem doesn't seem to display properly when the menuitem is displayed.. |
|
ARIA Menubar Example: menuitemradio and menuitemcheckbox (http://w3c.github.io/aria-practices/examples/menubar/menubar-2/menubar-2.html) doesn't contain any code sample on the page - is this by design? |
|
@annabbott, it is not by design. Jemma is working on updating the page to use the example template, which includes the source code section. |
|
@mcking65 |
|
Enter and space are not working correctly in the menubar. Raised issue #196. |
|
@carmacleod, Thank you for the feedback. The current version is the github.io page. In these review issues, I always have a link to the page for review in the first comment on the page. That rawgit page is an out of date branch in Jemma's fork of the w3c repo. We may occasionally have discussion of a branch in someone's fork, but that should generally be in a pull request, not one of our review issues. I understand why you would ask, though, as this issue had a momentary lapse from that practice. |
|
Thanks, @mcking65. So, I do see a problem on the github.io page: |
|
@carmacleod, thank you, we can see the issue and @jongund will address it. |
|
There are 2 more issues that I have noticed. (I realize that these are visual issues, however I think it's important to fix them because we need sighted devs to want to use these accessible controls). Issue 1When moving a mouse horizontally across a menubar, hovering over each menu button to see what is in its menu, each newly-opened menu appears instantly (good) but the previously-open menu hesitates before closing, which looks like both menus are open for a while, which feels really odd. This odd behavior does not happen when I use right/left arrow keys to traverse through the menus. MenubarItem.prototype.handleMouseout = function (event) {
this.hasHover = false;
setTimeout(this.popupMenu.close.bind(this.popupMenu, false), 300);
};I don't know why there's a timeout here - is it necessary? If it does need to be kept for some reason, then 300 ms is way too long to wait before closing the previous menu, so we need to determine what minimum value it can be set to. Issue 2Using either keyboard or mouse, when the user opens a menu and then traverses to a menu item inside that menu, the menu button in the menubar no longer looks selected. For example, open the Font menu, and arrow down to the Serif menu item. The selected look of the Font menu button disappears. This is different from the look of a desktop menubar, which would show the Font menu button as "pushed in" (for Windows menubars) or "blue" (for Mac menubars) while the Font menu is open. |
|
@carmacleod, any chance you'd be able to submit a PR with proposed fixes to these two issues? |
|
I was thinking I really ought to submit a PR. |
|
carmacleod commented:
That would be fabulous! Thank you!! |
No problem. If anybody has any history on what that timeout is doing on mouseout, it would be good to know before I try removing it. ;) |
|
OK, flagging the question of what the purpose of the timeout on mouseout is as a discussion topic for Monday's meeting. |
|
The timeout is related to using the mouse, if there is no delay the menu closes as soon as people move 1 pixel away and this doesn't feel right. So I would suggest making the delay shorter. |
|
If someone is going to work on the menubar examples they can also fix the issues related to ignoring certain combinations of modifier keys and the the return key behavior for a menu of links + modifier keys. You can look at the updated examples of the treeview and menu button examples for examples of how to fix the problems. |
|
We discussed the timeout in Monday's meeting. @jongund described the purpose above. The task force agreed that the timeout is good as long as the user is moving the mouse away from the menus. However, if moving the mouse opens another menu, the timeout should be cleared so any already open menus close instantly and so there is never more than one menu visible at a time. |
|
I reviewed mouse hover behavior for open menus in the following menubars:
In each case, the menu that was open remains open if the user moves the mouse away. The menu only closes if and when the user clicks somewhere else. I would argue that we should do the same (only close menu on click; do not close on timeout), for the following reasons:
So, if you agree that instead of closing on timeout, we should close on click, then that is what I will implement. (Otherwise, I will go with the behavior described in the previous comment, e.g. timeout if mouse is moving away from menus, but close immediately if another menu is being opened). |
|
Discussed 5/1/2017 in APG meeting. We agree with the substance of @carmacleod comments. 2 additional clarifications.
|
|
Agree completely. |
…Links For issue #144, made the following changes to the editor menubar example in examples/menubar/menubar-2/menubar-2.html. 1. Clarified and simplified introduction. 2. Moved Notes from example section in to a separate accessibility features section to be consistent with the example template. 3. Removed use of term "popup" and used "submenu" as agreed in issue #268. 4. Editorial revisions to keyboard tables. 5. Editorial revisions to role, state, and property tables. 6. Fix broken links to source files.
|
All feedback has now been addressed except for changes requested for mouse behavior, which are now tracked in issue 408. Closing this issue. |
github-project-automation
bot
moved this to Complete
in Menu, Menubar, and Menu Button patterns and examples development project
Provide editorial and functional feedback on the
editor menubar example that demonstrates use of menuitemradio and menuitemcheckbox in submenus of a menubar.
The text was updated successfully, but these errors were encountered: