[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[orion-dev] Web Accessibility Tip of the Day: Tip #5

Tip #5: More on role="application", role="document" and role="presentation"

If you are creating a complex custom control and you have implemented and tested its keyboard interaction,
and then you try a screen reader and find that the screen reader consumes arrow keys or other keys that your control needs for interaction...
then you *may* need to set role="application" on the element containing your custom control.

Besides being a landmark role, "application" tells the screen reader to pass user keystrokes through,
so that your _javascript_ has access to them.

Many screen readers have 2 modes of operation: "document/browse mode" and "forms/focus mode".
In browse mode, the screen reader consumes keystrokes like arrow keys and letter keys so that the user can use them to navigate through the document's content.
In forms mode, the screen reader passes many of these keys through to the browser and the _javascript_.
Forms mode is entered automatically when an interactive native HTML element or ARIA-enabled element gets focus.

CAVEAT EMPTOR: role="application" is a last resort. First, try to avoid it by considering the following:

- Make sure that your custom control is using the most semantically appropriate role.
  Is it very much like a tree? Then using role="tree" tells the screen reader which keys you (probably) need and it will pass those keys through.

- If your custom control contains non-focusable child elements that a screen reader user might typically use arrow keys to navigate to,
  for example table cells, then you may also need to turn off the semantics of these child elements by using role="presentation".
  (More on role="presentation" in another tip).

- Note that if you use role="application", then you will not get any free keyboard interaction behavior when a screen reader is running,
  so you need to handle all keystrokes yourself. You may be able to set role="document" on certain child elements of your custom control
  to regain the free navigation behavior for those child elements.
 
Also, before using role="application", read through these specs and relevant articles:
http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_impact
http://rawgithub.com/w3c/aria-in-html/master/index.html#using-aria-role-application
http://www.marcozehe.de/2012/02/06/if-you-use-the-wai-aria-role-application-please-do-so-wisely/
http://www.netmagazine.com/features/aria-s-application-role

Car