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

Dominic, Rich,

I think the definition of interactive needed to address bug 27866 would be 
quite different from what is in the current proposal. The issue raised in 
bug 27866 is important but very different from the issues addressed by 
this proposal. The fact that some of the same words are being used, 
especially the word "interactive", really is coincidental.

I believe interpreting the current aria-interactive proposal as both a 
resolution to bug 27866 and a resolution the table mapping gaps would lead 
to very substantial confusion, especially for content authors and AT 
developers.

At this time, I think we need to focus on whether or not the group wants 
to resolve the table mapping gap with the kind of approach proposed in the 
current aria-interactive description. It does not necessarily need to be 
called aria-interactive. During the teleconference, there were no strong 
objections to that approach so it is the current plan.

John is questioning the wisdom of this plan. As this conversation 
progresses, I am starting to lean in the same direction -- it would be 
better to add separate table roles and not have a property that makes such 
a radical transformation in mapping. But, a couple people leaning that way 
is different from a clearly stated and well-supported objection.

There is a form of precedence; We have some properties that effect 
mapping. aria-pressed and aria-haspopup on buttons are 2 such examples. 
But, in both cases, those just special case button. They do not transform 
the button into a completely different entity with significantly different 
semantics.

The aria-interactive proposal is fundamentally different. It is designed 
as a property that flip-flops the semantics of a role between the 
structural and widget branches of the ontology.

One potential problem I see with controlling such a flip in semantics with 
a property is that the states and properties that are common in the widget 
branch are quite different from those in the structure branch. So 
shouldn't the states and properties supported on an interactive widget 
role that is "flipped" into a non-interactive structure change along with 
the flip? Similarly, shouldn't the states and properties supported for an 
element with a structural role transformed into an interactive widget be 
different from those supported on that structural role? But, without a 
specific role that defines which states and properties are supported for 
the flipped element, how do user agents and authors know which are 
supported and what they will do?

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Richard Schwerdtfeger/Austin/IBM
To:     Dominic Mazzoni <dmazzoni@google.com>, 
Cc:     "Gunderson, Jon R" <jongund@illinois.edu>, Matthew 
King/Fishkill/IBM@IBMUS, "W3C WAI Protocols & Formats" 
<public-pfwg@w3.org>, Alexander Surkov <surkov.alexander@gmail.com>
Date:   05/21/2015 11:47 AM
Subject:        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