Arrow keys in input elements and role=application

[E.J. Zufelt]

Good morning,

I'm working on improvements to jQuery UI autocomplete http://bugs.jqueryui.com/ticket/7840

I'm trying to figure out when it is, and is not, necessary to use role="application" to ensure that key events are passed to the user agent.  Testing the current implementation ( http://view.jqueryui.com/master/demos/autocomplete/index.html ) with JAWS 13 and Firefox 8, the up and down arrow keys are being passed to the user agent, without role="application".

Any clarification that can be provided about this would be most useful.

Thanks in advance,

Everett Zufelt

http://zufelt.ca

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt

[Dominic Mazzoni]

Hi,

What you observed sounds correct. This document is the best explanation of how JAWS handles role=application:

  http://www.freedomscientific.com/fs_support/BulletinView.asp?QC=1404

The short answer is that your web application will always receive keystrokes when the user is focused on editable text fields, and a few other controls like sliders, and listboxes - in essence, any control that you'd normally use arrow keys to interact with.

- Dominic

--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.
To post to this group, send email to free...@googlegroups.com.
To unsubscribe from this group, send email to free-aria+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/free-aria?hl=en.

[E.J. Zufelt]

Good morning Dominic,

Thanks for the information.

From the article that you you cited:

ARROW keys: 

• When the virtual cursor is active, JAWS enters Forms Mode upon encountering an edit field. Focus is moved to the edit control, and the user can begin typing. 

• In Forms Mode, the ARROW keys move the caret within the edit field. 

• In Forms Mode, if an ARROW key is pressed and the caret has already reached the boundary of the edit field, JAWS exits Forms Mode and resumes using the virtual cursor. 

• In Forms Mode, pressing ESC or NUMPAD PLUS will cause JAWS to exit Forms Mode.

This confirm for me, that at least for JAWS, if you need to pass all arrow keys through to a text field, then you need to make sure that the input element is within a parent with role="application". Otherwise, if the user has auto forms mode enabled (default), then arrow keys may cause JAWS to enter virtual document mode, and may not be passed to the input element.

Thanks again,

Everett Zufelt

http://zufelt.ca

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt

[Bryan Garaventa]

I've found that role=dialog is more reliable for this type of behavior.

 

The biggest problem with applying this to an edit field though is that, when arrowing down the page in JAWS, focus is trapped whether the user wishes to be or not, which gets old really fast when you just want to read the page.

[Dominic Mazzoni]

Everett,

The docs aren't very clear here, because they don't say how JAWS knows if you pressed the arrow key and you've already reached the bottom of the field. My experience has been that JAWS only escapes the edit field if you press the down arrow and the text field does not respond to the event. if you use JavaScript to capture the arrow key events (to be safe, capture keydown, keypress, and keyup) and call event.stopPropagation() and event.preventDefault() on each event, then you can implement whatever behavior you want and prevent JAWS from going to the next control automatically.

- Dominic

[E.J. Zufelt]

Good afternoon Dominic,

Thanks for the additional info.

Do you know how any other screen-readers (WE, NVDA, etc) handle this?

Thanks again,

Everett Zufelt

http://zufelt.ca

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt

[James Teh]

On 30/12/2011 6:42 AM, E.J. Zufelt wrote:
> Do you know how any other screen-readers (WE, NVDA, etc) handle this?

For this type of control, you should not use role application or role
dialog, as it isn't an application or a dialog. (Btw, that's generally
the best way to figure out whether you should be using those roles.)

The way NVDA handles this depends on how it is configured. By default,
when in focus mode (which is the normal way of interacting with editable
text fields), all keys are passed through to the field except escape.
However, if the user has enabled Automatic focus mode for caret
movement, the arrow keys will be captured if the user is at the edge of
the field; i.e. pressing the arrow key causes no movement. This is one
reason this setting is disabled by default. However, if users enable it,
they should be aware of this issue and compensate accordingly.

Jamie

--
James Teh
Vice President, NV Access Inc
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/
Phone: +61 7 5667 8372

[E.J. Zufelt]

On 2011-12-29, at 5:09 PM, James Teh wrote:

> On 30/12/2011 6:42 AM, E.J. Zufelt wrote:
>> Do you know how any other screen-readers (WE, NVDA, etc) handle this?
> For this type of control, you should not use role application or role dialog, as it isn't an application or a dialog. (Btw, that's generally the best way to figure out whether you should be using those roles.)
>

Sadly for a UI component that will be used in many different UIs, where we do not have control over the settings of assistive technology, or the ability to easily educate users, we do need some method of reliably catching all keys passed to the component. Perhaps a suggestion for WAI-ARIA Next would be a 'widget' (or otherwise named) role, that serves the same purpose as application / dialog, but without the additional semantics. For the present, it looks like we need to use application or dialog in order to ensure that we can consistently trap arrow keys across assistive technology, particularly where auto forms mode (or equivalent) is enabled.

Thanks,
Everett
.

[Victor Tsaran]

Unfortunately Everett is right here.
I know that NVDA and VoiceOver are giving up the keyboard control for most ARIA widgets but in the case with the former screen-reader some widgets still need attention.

[Victor Tsaran]

Sorry, hit "send" too early.
I do feel a little awkward though when developer suggest using the role of APPLICATIOn or a DIALOG to force screen-reader give up its control. If we stand behind the standard and stop favoring certain screen-readers, we may just force them to change their behavior.
NVDA, in particular, has a very responsive development team and FS, if approached correctly, would be willing to work with interested parties.
So, I'd think twice before resorting to roles of application and dialog.
Just my two cents.
Victor

On Dec 29, 2011, at 3:35 PM, E.J. Zufelt wrote:

[James Teh]

On 1/01/2012 10:01 AM, Victor Tsaran wrote:
> I know that NVDA and VoiceOver are giving up the keyboard control for most ARIA widgets but in the case with the former screen-reader some widgets still need attention.

Despite several requests, no one has provided proper information on what
ARIA widgets NVDA does not enable focus mode for. One exception is
toolbars, which is a known issue.

>> Sadly for a UI component that will be used in many different UIs, where we do not have control over the settings of assistive technology, or the ability to easily educate users, we do need some method of reliably catching all keys passed to the component. Perhaps a suggestion for WAI-ARIA Next would be a 'widget' (or otherwise named) role, that serves the same purpose as application / dialog, but without the additional semantics. For the present, it looks like we need to use application or dialog in order to ensure that we can consistently trap arrow keys across assistive technology, particularly where auto forms mode (or equivalent) is enabled.

This approach is extremely flawed. It solves the problem of passing keys
through to the widget at the expense of completely breaking consistency
and standard workflow. For example, if you do as you suggest and you
have Automatic focus mode for caret movement (or equivalent) enabled,
down arrow will move you into the widget but then you won't be able to
get out of it without pressing tab. Similarly, even if this is not
enabled, pressing escape won't switch out of focus mode, which is what
users expect. Many of us don't use the tab key to move between widgets,
which is essentially the only method of interaction your method allows.

Users need to be familiar with how to use their AT of choice and the AT
needs to specify sensible defaults to assist with this. Once they are,
all of this becomes trivial. The aforementioned autocomplete example
will work just fine in NVDA with the defaults we have chosen.

[Victor Tsaran]

On Dec 31, 2011, at 4:10 PM, James Teh wrote:

> Despite several requests, no one has provided proper information on what ARIA widgets NVDA does not enable focus mode for. One exception is toolbars, which is a known issue.
>

There you go, "toolbars".
I'll follow up with others although they may have been fixed. Toolbar is abiggy one though.

>>> Sadly for a UI component that will be used in many different UIs, where we do not have control over the settings of assistive technology, or the ability to easily educate users, we do need some method of reliably catching all keys passed to the component. Perhaps a suggestion for WAI-ARIA Next would be a 'widget' (or otherwise named) role, that serves the same purpose as application / dialog, but without the additional semantics. For the present, it looks like we need to use application or dialog in order to ensure that we can consistently trap arrow keys across assistive technology, particularly where auto forms mode (or equivalent) is enabled.
> This approach is extremely flawed. It solves the problem of passing keys through to the widget at the expense of completely breaking consistency and standard workflow. For example, if you do as you suggest and you have Automatic focus mode for caret movement (or equivalent) enabled, down arrow will move you into the widget but then you won't be able to get out of it without pressing tab. Similarly, even if this is not enabled, pressing escape won't switch out of focus mode, which is what users expect. Many of us don't use the tab key to move between widgets, which is essentially the only method of interaction your method allows.
>
> Users need to be familiar with how to use their AT of choice and the AT needs to specify sensible defaults to assist with this. Once they are, all of this becomes trivial. The aforementioned autocomplete example will work just fine in NVDA with the defaults we have chosen.
>
> Jamie
>
> --
> James Teh
> Vice President, NV Access Inc
> Email: ja...@nvaccess.org
> Web site: http://www.nvaccess.org/
> Phone: +61 7 5667 8372
>

[Scott González]

On Sat, Dec 31, 2011 at 7:10 PM, James Teh <ja...@nvaccess.org> wrote:

Sadly for a UI component that will be used in many different UIs, where we do not have control over the settings of assistive technology, or the ability to easily educate users, we do need some method of reliably catching all keys passed to the component. Perhaps a suggestion for WAI-ARIA Next would be a 'widget' (or otherwise named) role, that serves the same purpose as application / dialog, but without the additional semantics. For the present, it looks like we need to use application or dialog in order to ensure that we can consistently trap arrow keys across assistive technology, particularly where auto forms mode (or equivalent) is enabled.

This approach is extremely flawed. It solves the problem of passing keys through to the widget at the expense of completely breaking consistency and standard workflow. For example, if you do as you suggest and you have Automatic focus mode for caret movement (or equivalent) enabled, down arrow will move you into the widget but then you won't be able to get out of it without pressing tab. Similarly, even if this is not enabled, pressing escape won't switch out of focus mode, which is what users expect. Many of us don't use the tab key to move between widgets, which is essentially the only method of interaction your method allows.

In the case of automatic focus mode, does NVDA ignore whether the default action is prevented for arrow key events? Does it still navigate if there are modifier keys pressed? For example, would alt+down arrow (as suggested in the DHTML style guide) invoke the autocomplete widget, and not navigate even in automatic focus mode?
 

Users need to be familiar with how to use their AT of choice and the AT needs to specify sensible defaults to assist with this. Once they are, all of this becomes trivial. The aforementioned autocomplete example will work just fine in NVDA with the defaults we have chosen.

This is a completely reasonable and valid statement, and is in line with our (jQuery's) goals. We recognize the unfortunate truth that right now it's not logical to try to support every AT on every browser on every OS, certainly not with every possible configuration setting. We're trying to choose the best path forward and we're using latest NVDA on latest Firefox as the base line. I do have a few questions about the expected behavior for a user who has chosen automatic forms mode:

Should they have additional key strokes that would navigate the menu?

Should they just know to temporarily change their settings if they want to use the suggestions?

What is the behavior of native autocomplete fields? Does native autocomplete in a web page behave exactly the same as the autocomplete in the location bar?

[James Teh]

On 3/01/2012 11:37 PM, Scott Gonz�lez wrote:
> I do have a few questions about the
> expected behavior for a user who has chosen automatic forms mode:
> Should they have additional key strokes that would navigate the menu?

I don't think so.

> Should they just know to temporarily change their settings if they want
> to use the suggestions?

That depends. NVDA has two options for automatic focus mode: automatic
focus mode for focus changes and automatic focus mode for caret
movement. The former is enabled by the default, while the latter is not.
If only the former is enabled, autocompletes will be unaffected because
up/downArrow is never intercepted by NVDA while in focus mode. If the
latter is enabled, users should expect that up/downArrow will move
through the document and will behave unreliably in autocomplete fields.
This is one reason we have it disabled by default. A user can always
force the screen reader into focus mode with NVDA+space or use pass key
through (NVDA+f2).

> What is the behavior of native autocomplete fields?

They actually bring up a menu which is outside the document. However, if
auto focus mode for caret movement is enabled, this will cause problems
because the user is probably expecting up/downArrow to move through the
document, not move through autocompletes. Autocomplete and auto focus
mode for caret movement are incompatible unless the user is willing to
work around the conflicts.

> Does native
> autocomplete in a web page behave exactly the same as the autocomplete
> in the location bar?

Pretty similar, yes.

[Scott González]

Thanks James. So it sounds like the suggestion is that we should diverge from how native autocomplete works (not sure that we could even accomplish the same thing with existing technology anyway) and just let these fields fail for users who have enabled auto focus mode for caret movement, which is what the user would expect anyway.

On Tue, Jan 3, 2012 at 9:07 PM, James Teh <ja...@nvaccess.org> wrote:

--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.
To post to this group, send email to free...@googlegroups.com.

To unsubscribe from this group, send email to free-aria+unsubscribe@googlegroups.com.

[E.J. Zufelt]

I find this a difficult position to support. Users must understand how their technology works, and most of them do not.

Recognizing that jQuery UI uses NVDA as a baseline, and perhaps broadening this discussion. I expect that JAWS still holds the majority market share, and JAWS ships with autofocus enabled. This means, that using an approach of ignoring autofocus, with a user base that we know does not understand their assistive technology, means that the majority of users cannot use the widgets built without application mode (or other alternatives) supported.

If we could get agreement from screen-reader vendors to not exit a field when autofocus is enabled, and an arrow key event is cancelled by a textfield, we could have a level of consistency that would allow us to proceed as widget developers without users needing to understand their technology, and without using application mode.

The workflow could be something like:

1. User is in a textfield and presses down arrow.

2. Screen-reader is configured with autofocus enabled, but passes arrow to textfield anyway.

3. Screen-reader listens at end of event chain to see if arrow key has been pressed, if so then exits textfield, if not then some other event handler has cancelled the event, and does nothing.

Everett Zufelt

http://zufelt.ca

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt

To unsubscribe from this group, send email to free-aria+...@googlegroups.com.

[Octavian Rasnita]

If the screen readers could detect if the current control is a menu or if it has a list of options it could scroll (like the autocomplete widget), and if the screen reader is configured to use auto forms mode on, then it could speak a short message announcing this, and the screen reader could offer an alternative hotkey for scrolling in that list, for example "Press Control+up and down arrows to scroll" or something like that.
Or the screen reader users might try that hotkey and see if the current control has some options to choose from.

I am not sure about the best options for those who use auto forms mode on, because I turn this options off always, but I hope the list elements will continue to be accessible in the future by just using the up and down arrows for those who don't use this option.

Octavian

----- Original Message -----
From: "E.J. Zufelt" <li...@zufelt.ca>
To: <free...@googlegroups.com>
Sent: Wednesday, January 04, 2012 3:28 PM
Subject: Re: [free-aria] Arrow keys in input elements and role=application

Everett Zufelt
http://zufelt.ca

[James Teh]

On 4/01/2012 11:28 PM, E.J. Zufelt wrote:
> I find this a difficult position to support. Users must understand how
> their technology works, and most of them do not.

The solution you're advocating makes this even worse, since now the user
can't rely on the documented behaviour of the screen reader. Whether
that behaviour is ideal or not is irrelevant.

> If we could get agreement from screen-reader vendors to not exit a field
> when autofocus is enabled, and an arrow key event is cancelled by a
> textfield, we could have a level of consistency that would allow us to
> proceed as widget developers without users needing to understand their
> technology, and without using application mode.

The whole point of auto focus mode for caret movement is that the user
*expects* to be able to press up/downArrow to move out of an editable
text field. This proposal would break this expectation, thus breaking
the user's understanding of their technology, thereby counteracting its
original intent. We already have this problem with native autocompletes.

> 1. User is in a textfield and presses down arrow.
> 2. Screen-reader is configured with autofocus enabled, but passes arrow
> to textfield anyway.

NVDA already does this.

> 3. Screen-reader listens at end of event chain to see if arrow key has
> been pressed, if so then exits textfield, if not then some other event
> handler has cancelled the event, and does nothing.

It's very possible that the screen reader can't hook into the DOM event
chain like this. This is certainly true in Firefox.

It's worth noting that if something else gains focus when downArrow is
pressed (e.g. a menu item or similar), NVDA will not switch to browse
mode. This means that if your autocomplete widget implements suggestions
as by focusing menu items or similar, you will get the behaviour you're
asking for, though I'd still argue this will confuse users.