27576 2014-12-11 20:09:40 +0000 Generic UI control role is required 2018-05-11 22:10:52 +0000 1 1 1 Unclassified ARIA Spec 1.1 PC All RESOLVED FIXED P2 enhancement --- 1 dylan jcraig dmazzoni w3cbugzilla oldest_to_newest 116166 0 dylan 2014-12-11 20:09:40 +0000 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. 117354 1 dmazzoni 2015-01-20 16:43:40 +0000 I think this is an important use case. I proposed bug 27866 as a different potential solution. 129237 2 w3cbugzilla 2018-05-11 22:10:52 +0000 Any reason we can't use role=application and aria-roledescription for this?