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