Main Menu

Breadcrumbs

ARIA Widgets and Focus/Forms Mode Support in JAWS and NVDA

When using ARIA composite application widgets, e.g., combobox, menubar, tree, authors are expected to implement appropriate keyboard interaction and focus management. Where screen readers that use virtual buffers are concerned, notably JAWS, NVDA, and Window-Eyes, this means invoking their special passthrough mode referred to as forms mode, focus mode, or sometimes application mode.

VoiceOver on the Mac doesn't use virtual buffers, and the current version of Window-Eyes really doesn't support ARIA (although its anxiously awaited next version will). As such, what follows deals exclusively with JAWS and NVDA.

Native Focus Mode Support for Widget Roles

Focus or forms mode initially enabled screen reader users to interact with typical form controls such as text inputs and select dropdowns. With today's fancier custom widgets, it's not always the case that natively interactive HTML elements will be used (even when they can and should). Application widgets are being built using things like table or ul elements, if not simple divs and spans, none of which are natively interactive or focussable. Hence the need for authors to implement keyboard access and focus management themselves, and the similar need for a way to tell screen readers like JAWS and NVDA to use their special focus mode.

The nice thing about ARIA widget roles is that they themselves should notify relevant screen readers to automatically enter focus mode. This allows authors to not have to worry as much about the negative effects that can accompany using role="application", that special landmark role whose main purpose is to signal to screen readers that they should enter focus mode and pass keyboard commands through to the browser. I've addressed these negative effects before in Not All ARIA Widgets Deserve role="application", as have others, for example, Marco Zehe in his post If you use the WAI-ARIA role “application”, please do so wisely!.

Update (10 September 2012): James Teh from NVDA has pointed out that mode switching is not strictly to do with virtual buffers. For instance, VoiceOver's Quick Nav mode assigns special actions to the arrow keys. If Quick Nav mode was on, one would need to manually toggle it off again to make normal use of the arrow keys in a web application.

James also points out that, for NVDA, focus mode and the mode you get with role="application" are quite different. An earlier version of this post orginally discussed role="application", but that got edited out. So let me put some of it back in.

The effect of role="application" in NVDA is quite different from what it is in JAWS. In NVDA, there are no virtual buffers within a container set with role="application". NVDA only recognises an application, and no document content for which virtual buffers or a browse mode might be required. Because there are no virtual buffers for that container, there is no toggling NVDA's focus mode off and use browse mode commands. While NVDA does pass keystrokes through to the browser, it's not the normal focus mode.

But again, this is the nice thing about these ARIA widget roles. They invoke focus mode for those supporting screen reader and browser combinations, so there's no need to deal with role="application".

Testing Support in JAWS and NVDA

JAWS and NVDA do quite well entering forms mode with ARIA composite widgets. With some exceptions, both JAWS and NVDA automatically invoke forms mode when focus is moved to a widget container or, where suggested by the WAI-ARIA 1.0 Authoring Practices guide, to the first sub-component within the widget.

The following widget role structures were tested:

textbox in a combobox

gridcell in a grid

listbox

menuitem in a menu

menuitem in a menubar

radio in a radiogroup

slider

spinbutton

tab in a tablist

treeitem in a tree

columnheader in a treegrid

View the test page. Forms mode support was tested by using the Tab key to move focus from widget to widget in the following screen reader and browser combinations:

JAWS 10 and 11 in Internet Explorer 8 and Firefox 15

JAWS 12 in IE9 and FF15

JAWS 13 in IE9, IE10, and FF15

NVDA 2012.2.1 in IE8, IE9, IE10, and FF15

Test Results

Unless otherwise indicated, a "Yes" in the tables below means the screen reader automatically enters forms or focus mode when focus is set to the relevant element. In some cases, the screen reader does not automatically enter forms mode, but allows entering forms mode manually, e.g., by pressing Enter when the element has focus.

Note: No natively focussable HTML form or interactive elements were used in the test widgets. This was done in order to test how well the ARIA roles on their own are interpreted by the browser and screen reader. Where combobox widgets are concerned, the text field will typically (and should) be an actual input element, but it need not be. Had an actual input element been used for the combobox's textbox in these tests, both JAWS and NVDA would have automatically entered forms mode because they do this natively for text inputs. As it is, forms mode support for a div set with role="textbox" in a combobox container is variable.

Things to Note

JAWS 12 in IE9 and FF15 supports automatic forms mode for almost all of the widget roles tested, with the single exception of radio in a radiogroup which requires manually entering forms mode.

Support in JAWS 13 is the same as in JAWS 12, with the exception of a small regression when using IE9 and IE10 where a div set with role="textbox" in a combobox widget is concerned.

JAWS 11, 12, and 13 in IE will not properly recognise a slider unless it has an aria-valuenow property. However, since @aria-valuenow is somewhat integral to slider, this is unlikely to be an issue in practice.

JAWS 10 and 11 in FF15 appear to automatically enter forms mode for menuitem in a menubar, but they don't clearly signal this with the typical audible beep.

3 Responses to ARIA Widgets and Focus/Forms Mode Support in JAWS and NVDA

A couple of things, when you talk about focus mode you are talking about forms mode, right? I found the use of the two terms a little confusing in the beginning but if this is the case – then thats fine.

I also liked really liked your point about role=”application” and the presence of ARIA roles triggering forms mode within JAWS and giving focus to the children of an element with an ARIA role present. So this negates somewhat the need to use role=’application’ – which for me is a good thing, as I see it more as problematic to support and also difficult for SR users to understand and navigate (as of time of writing due to poor UA implementation).

I know that you haven’t covered VO but I wonder if the behavior is the same? I am guessing it is but there is no buffer used with VO IIRC which would mean that the net result that don’t have to add role=”application” to a widget either for it to work with VO and make the child elements focusable, right?

In some exploration I did very recently on a colleagues’ ARIA test cases the use of role=’dialog’ would trigger/enable focus for newer versions of VO (a la Mountain Lion) but not the version in Lion/Safari 5.1.3.

Anyway, these are all the trials of working with new technologies – and thanks for your insightful research.

“when you talk about focus mode you are talking about forms mode, right? I found the use of the two terms a little confusing in the beginning but if this is the case – then thats fine.”

Yes, forms and focus mode are the same thing. I’ve found that JAWS tends to refer to forms mode, while NVDA tends to refer to focus mode.

“So this negates somewhat the need to use role=’application’ – which for me is a good thing, as I see it more as problematic to support and also difficult for SR users to understand and navigate…”

Yes!

“I know that you haven’t covered VO but I wonder if the behavior is the same? I am guessing it is but there is no buffer used with VO IIRC which would mean that the net result that don’t have to add role=”application” to a widget either for it to work with VO and make the child elements focusable, right?”

VO does not use a virtual buffer, and seems to automatically permit direct keyboard input to elements that need it, based on how the element is mapped to the accessibility API. As for making child elements focussable, this depends on the element. Elements that aren’t natively focussable still need to be made focussable for Safari/VO, e.g. using tabindex, to be put in the tabbing order. How they behave in ARIA widgets is another story and depends on their construction and how keyboard interaction is managed (via scripting). I’m still trying to sort this out myself 🙂

“In some exploration I did very recently on a colleagues’ ARIA test cases the use of role=’dialog’ would trigger/enable focus for newer versions of VO (a la Mountain Lion) but not the version in Lion/Safari 5.1.3.”

What do you mean by focus in this instance? I’d be interested to play with the examples: do you have links? There are certainly some major differences in support for ARIA widgets between Safari/VO in earlier versions and the latest version. I’ve found this to be the case with tree view widgets, for example, about which I hope to write something “soon” 🙂

“In some exploration I did very recently on a colleagues’ ARIA test cases the use of role=’dialog’ would trigger/enable focus for newer versions of VO (a la Mountain Lion) but not the version in Lion/Safari 5.1.3.”

Actually, my bad I phrased that incorrectly. I meant that the presence of parent with the ARIA role=”dialog” was announced in a newer versions of VO (a la Mountain Lion) but not my version in Lion using Safari 5.1.3. This seems to be just because of better support for this ARIA role in a newer version of the Mac OS. I need to remind my self that ARIA is a work in progress, so support is improving (and changing all the time).