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,
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
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
(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.