Remember to remove the application role when ARIA 1.1 is final

[mcking65]

No description provided.

[accdc]

One note, if we are dealing with a menubar that includes links that navigate to different landing pages onClick and also opens a dropdown menu onFocus and onMouseOver and when the Downarrow is pressed, this only works if role=application is present to surround the role=menubar construct, otherwise screen readers like JAWS and NVDA will always trigger onClick when trying to activate the menubar. This is a common design pattern and we need to support this with one example at least.

[mcking65]

When a reading cursor is active and enter is pressed, screen reader should not activate the menu item but instead just set focus. The fact it is generating click should be considered a screen reader bug because menubar is a composite like listbox and tree. Using application in this way is not consistent with the ARIA 1.1 definition of the application role.

[accdc]

I'm not sure where my FS bug credentials are, can you file a bug against JAWS for this? Also NVDA does the same. Another issue with JAWS is the unreliability of entering Forms Mode when focus is set to role=menu, role=menubar, or one of the role=menuitem nodes, which is necessary to start processing the arrow key navigation. At present this surrounding role is the only way to make this dual functionality work, but if it can be changed, I agree it should not be necessary for what is already defined as an interactive widget construct.