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

On Thu, May 21, 2015 at 11:47 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:

> 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.
>
Rather than restricting the text, please at least consider allowing it to
apply to other roles. This is not a hypothetical situation, there are web
apps that could benefit from this now.

- Dominic


>
>
>
> Rich Schwerdtfeger
>
> [image: Inactive hide details for Dominic Mazzoni ---05/21/2015 11:53:23
> AM---On Thu, May 21, 2015 at 7:02 AM, Richard Schwerdtfeger <s]Dominic
> Mazzoni ---05/21/2015 11:53:23 AM---On Thu, May 21, 2015 at 7:02 AM,
> Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
>
> 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* <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
>
>
>
>