The current specification for ARIA defines a bunch of widget roles with explicit semantics that are commonly used across the Web but does not allow for the definition of a widget that is totally custom.

An example of such a widget is a "pan" control on a map.

In order to implement a pan control and allow the keyboard events to be delivered by default to the JavaScript handlers, implementors are forced to choose from the following imperfect solutions:

1) Use the application role
2) Use one of the other widget roles that provide for automatic switching between document browsing mode and application browsing mode

I propose either one of the following:

1) Changing the widget role from an abstract role to a widget role (preferred)
2) Creation a generic "control" role

In both instances, the aim would be that this would allow for the automatic switching from document browsing mode to application browsing mode and back again as focus moves to-and-from the element allowing implementors to then provide the required functionality.