[orion-dev] Web Accessibility Tip of the Day: Tip #5

[Carolyn MacLeod <Carolyn_MacLeod@xxxxxxxxxx>]

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