ISSUE-431: Define a user agent approach for providing RIAS with effective and consistent keyboard interfaces to access RIIA functions and components, e.g., toolbars, commands, help, landmarks, etc.

Effective Keyboard Interface for Application Context

Define a user agent approach for providing RIAS with effective and consistent keyboard interfaces to access RIIA functions and components, e.g., toolbars, commands, help, landmarks, etc.

ARIA 2.0
Raised by:
Richard Schwerdtfeger
Opened on:
Matt: moving to ARIA 1.1 since I have a proposal that will support this without browser changes.

Currently, it is not possible to build RIAs with keyboard interfaces that are as complete or efficient as desktop applications.

Regardless of platform, desktop apps have substantial capability to fully exploit the keyboard and provide an effective alternative to the mouse. Because the browser itself is a desktop application, and because browsers consume the keyboard interface, applications delivered inside the browser, for all practical purposes, do not have a keyboard interface.

For example, compare a typical e-mail application delivered as a desktop application on Windows and as a RIA in Firefox. On the desktop, when reading an e-mail, the user can likely press escape and be returned to the inbox. In Firefox, the user will need to hunt for and press a "back to inbox" button because escape is assigned to the Firefox "ccancel page load" function. On the desktop, to reply, the user will likely press ctrl+r, but in Firefox, that will re-load the page. On the desktop, the user mayt press ctrl+s to save a draft copy, but in Firefox, that will open the save dialog to save a copy of the web page. On the desktop, the user will press F1 to get to help about the mail program, but in Firefox that will open help about the browser. The list goes on.

Generally, an operating system provides many of the same kinds of functions that a browser does. It just does not keep them on the surface all the time. For example, Windows has bookmarking-like functionality. It has a recent document or "history" type of capability. It has a help system of its own. It has a print screen function too. But, to get to most Windows functions from within a Windows application, you must first access the chrome, e.g., Windows itself. A concept similar to this is critical for delivering effective keyboard access in RIAs. Without it, keyboard users will never be able to use RIAs as well as they do desktop apps.

Note that simply giving the RIA first dibs on a key assignment and then passing it on to the browser would be very problematic. If this is done, the user will press a key and not know what is going to happen. Is it going to print the whole web page or just my memo? Is it going to perform a browser save function or an application save function, and so on. In Windows, application keys that are not assigned are harmless. They are not passed on to the operating system to do something the user may not want to do.

Possible traits of a solution:

- when browser focus is inside a RIA application context, an optional attribute of that context could be to own the keyboard with the exception of operating system keys and a very limitted (and widely agreed upon) set of browser function keys.

- When the RIA owns the keyboard, the browser chrome could be reduced, brayed, or possibly disappear with the exception of the browser equivalent of the Windows start button.
Related Actions Items:
No related actions
Related emails:
No related emails

Related notes:

Is this overcome by IndieUI? In either case, definitely too big for ARIA 1.1.

James Craig, 17 Sep 2013, 01:28:05

Display change log ATOM feed

James Nurthen <>, Valerie Young <>, Chairs, Daniel Montalvo <>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 431.html,v 1.1 2023/05/22 16:31:57 carcone Exp $