Re: indicating a context menu

On 13 Dec 2010, at 14:20, Steve Faulkner wrote:
> What is the mest way to indicate the presence of a context menu on a
> link using ARIA?
> 
> aria-haspopup seems inadequate for the task.
> 
> how does one let users know that they have tu use a particular
> keystroke (http://dev.aol.com/dhtml_style_guide#popupmenu)

It's not obvious to me that UAs /must/ indicate to the accessibility layer that system context menus have been modified, since users are typically unaware of this until they activate the context menu. I think users are likely to want to activate a context menu to access custom actions on the basis of some sort of hint about the nature of the object they're interacting with. For example, a user might see a word with a squiggly red underline in a text field, then right click on it to access spelling suggestions. I think in this case, the critical thing is to identify the nature of the object, such that users are encouraged to interact with it, rather than specify the presence of modified context menus. For example, in the spelling scenario, the word can be annotated with "aria-invalid='spelling'".

If, however, we believe it is critical to identify the presence of modified context menus, the UA knows whether the context menu has been modified, so we should make the UA responsible for expressing that fact to the accessibility tree, rather than having authors add an annotation like "aria-context" to their markup that might or might not reflect what the UA has actually done. This could be a UA conformance requirement in WAI-ARIA or UAAG.

But Steve's AOL link is discussing a scenario where the system context menu activation is suppressed on a link and some other menu in the DOM receives focus. So really, what we're talking about here is a secondary action (opening a menu) that cannot be accessed via the normal context menu."

I agree with Steve that "aria-popup" is inadequate. The definition of "aria-popup" implies that activation of the widget opens the menu, but in the case the link is followed instead.

http://www.w3.org/WAI/PF/aria/complete#aria-haspopup

The Best Practices document suggests that author-defined shortcuts like Shift-F10 should be explicitly documented.

http://www.w3.org/WAI/PF/aria-practices/#AuthDefKeys

So that's the first option.

The Best Practices also say that all functionality should be available "with the basic keys like Tab/shift+tab, arrow, Enter, space and Escape". One could insert a button to pop up the menu into the focus order immediately after the link. Depending on how globally accessible you want the menu to be, you might keep the button there always but off-screen until focused, or you might actually add it to the DOM when the link receives focus and remove it from the DOM when the next control receives focus. Users with the link focused could discover the additional functionality by tabbing away from the link or listing buttons on the page. The link and the button could be associated programmatically using a container element with the "group" role ("Authors SHOULD use a group to form logical collection of items in a widget"):

http://www.w3.org/WAI/PF/aria/complete#group

The Best Practices also say XHTML 2 WG's Access Module might address this issue. Now that XHTML 2 WG is dissolved, Access Module is frozen as a note:

http://www.w3.org/TR/xhtml-access/

Access Module has no concept of context-sensitive rather than document-global mappings. But I suppose one could add and remove "access" element from a DOM as focus moves through that DOM. So when the link in question received focus, you would add an "access" element pointing to the popup menu element with a defined access key. Note Access Module does not allow you to map function keys like F10 or combinations of keys with modifiers like Shift. So while you could use Access Module to provide access to the menu, you could not use it to express the fact that the author was also (trying to) hijack a system shortcut.

I've not heard of anyone trying to implement Access Module, but you could use the "accesskey" feature from XHTML 1/HTML5 in precisely the same way, and with the same limitations.

http://www.w3.org/TR/html401/interact/forms.html#adef-accesskey

http://dev.w3.org/html5/spec/editing.html#assigning-keyboard-shortcuts

What could be specified to improve this situation?

Allowing authors to request shortcuts like "Shift-F10" via an "accesskey"-like feature would be harmful as this is not consistent with all system UIs or even possible to enter via all devices.

Allowing authors to hijack the system context menu would be harmful because it prevents users accessing features - possibly including accessibility features - in the system context menu. Unfortunately this is already possible although in a brittle fashion. HTML5 provides a standard hook for authors who want to do this however in the form of the "contextmenu" event.

http://dev.w3.org/html5/spec/interactive-elements.html#context-menus

Allowing authors to annotate their documents to imply successful hijacking of the system context menu is harmful because the hijack attempt might have been frustrated.

Allowing authors to specify an element as providing context menu items for another control seems less harmful. It's easier for authors because it's completely declarative. It's better for users because the UA is in a position to notify accessibility APIs about modified context menus (as I noted earlier) and can make decisions about to replace its default context menu with the specified items or simply add them. This is the tack taken in HTML5 with the "contextmenu" attribute:

http://dev.w3.org/html5/spec/interactive-elements.html#context-menus

Especially useful is the provision that UAs may guarantee access to the system context menu:

"User agents may provide means for bypassing the context menu processing model, ensuring that the user can always access the UA's default context menus. For example, the user agent could handle right-clicks that have the Shift key depressed in such a way that it does not fire the contextmenu event and instead always shows the default context menu."

If we want to provide the same functionality in other host languages at the ARIA level, maybe the PFWG should consider adding a requirement on host languages to provide authors with a facility to define context menus for renderable elements, just as it currently requires host languages to support making such elements focusable:

http://www.w3.org/WAI/PF/aria/complete#host_general_focus

PFWG could give HTML5 "contextmenu" as an example implementation.
 
PFWG could then advise, in its Best Practices documentation, that authors should add a context menu item for *all* secondary actions that are associated with a specific element rather than global to the document. This would provide a standard way for users to access and activate secondary functionality on elements.

In this way, PFWG would kill two accessibility birds with one stone: customized context menus and secondary functions.

--
Benjamin Hawkes-Lewis

Received on Saturday, 18 December 2010 17:43:19 UTC