Re: aria-interactive and the authoring/debug process problems

I see your point. When working with Freedom Scientific they made it so that
interactive controls would not have the keys stolen. For example, a drop
menu button <div role="button" aria-haspopup="true"> does respond to an
arrow key without stealing the key and moving the point of regard in the
virtual buffer down a row.

We did not consider the basic buttons when we added that text. We also were
not adding the aria-interactive feature to buttons, checkboxes, and radio
buttons. So, we should restrict that text.


Rich Schwerdtfeger



From:	Dominic Mazzoni <dmazzoni@google.com>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	Alexander Surkov <surkov.alexander@gmail.com>, "Gunderson, Jon
            R" <jongund@illinois.edu>, Matthew King/Fishkill/IBM@IBMUS,
            "W3C WAI Protocols & Formats" <public-pfwg@w3.org>
Date:	05/21/2015 11:53 AM
Subject:	Re: aria-interactive and the authoring/debug process problems



On Thu, May 21, 2015 at 7:02 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
  Alex, for ARIA 1.1 we are going to limit the use of aria-interactive. By
  default, widgets are considered to be interactive.


That isn't consistent with the current text of the spec. It says "When a
user navigates an element that has aria-interactive set to "true",
assistive technologies that intercept standard keyboard events should
switch to a mode that passes keyboard events through to the user agent."

However, that's not currently how Windows screen readers behave. Buttons,
checkboxes, radio buttons, etc. are all "widgets", but screen readers do
NOT switch to a mode that passes keyboard events through to the user agent
now when elements with those roles are focused, even though that's
sometimes what web application authors would like them to do.

It'd be most accurate to say that the following roles are already
interactive: textbox, combobox, spinbutton, listbox, tab, menubar,
menuitem, treeitem, gridcell

However, these are not: button, checkbox, radiobutton, link

(We should double-check that list. I'll be happy to test it with JAWS,
NVDA, and Window-Eyes and figure out the current behavior.)

If we indeed want assistive technologies that intercept standard keyboard
events to switch to a mode that passes keyboard events through to the user
agent, we should allow authors to change a button to aria-interactive=true.

- Dominic

Received on Thursday, 21 May 2015 18:47:38 UTC