aria-interactive

[Dominic Mazzoni]

This is the text I filed with the following bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27866

The primary motivation behind this feature is that some "modal" screen readers, especially JAWS and NVDA on Windows, make a distinction between "simple" controls like checkboxes and buttons, and "interactive" controls like text fields and list boxes - the latter require you to switch to "forms mode" or something like that in order to interact with them, while simpler controls are just toggled while still in "browse mode" / "virtual pc cursor mode".

The problem arises when the author has a custom control that doesn't match one of the existing ARIA roles. The "pan control" in a map mentioned in bug 27576 is a good example. Another would be elements in a presentation editor like Google Presentations (similar to PowerPoint) - when you click on the heading of a slide, pressing the arrow keys moves its location on the page, and pressing Enter edits its text - there's no ARIA role that gives you that sort of behavior.

Rather than adding a new role, I propose we add an attribute aria-interactive that hints to the AT whether or not a particular element has keyboard handlers (or possibly other event handlers).

Some HTML elements and ARIA roles would map to aria-interactive=true by default, ideally closely matching the set of roles for which existing screen readers automatically switch to forms mode on focus (when that option is enabled by users).

However, this attribute would allow an author to override this in either direction.

While the primary motivation was to properly handle screen readers with modes, aria-interactive would be useful hints for other AT as well - on any platform, AT could announce or describe a control differently, and it could possibly help on mobile, too.

Examples:

1. This is the markup for an interactive slide title that you can position on the page with arrow keys when focused:

<h1 tabindex=0 aria-interactive="true">Slide title</h1>

2. This markup indicates a text field that shouldn't trigger auto forms mode, maybe because it's in a spreadsheet and it's more efficient for the user to use browse mode to find the cell they want first, and only then enter forms mode manually.

...

  <td>

    <input type="text" aria-interactive="false">

  </td>

[Alexander Surkov]

I'm curious to know Jamie's thinking.

I'm not sure about naming because checkbox and complex widgets are both interactive.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYyRxQCy10V-xQnrpwhubWEN%2BO%2BRBFiG0yOdUgYT_0tAaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Yura Zenevich]

I was wondering if you considered looking beyond aria-interactive indicating only support for keyboard interactions. Some additional interaction indicators could be for touch events (for example when authors prevent corresponding mouse events from firing). It would even be more awesome if aria-interactive could indicate that it supports both (maybe aria-interactive=“keyboard, touch”?).

[Dominic Mazzoni]

Could you explain more about what assistive technology should do if aria-interactive=touch? What's the broken behavior now, and how would it work differently if this was implemented?

[Dominic Mazzoni]

Reviving this thread. While there are a lot of details to work out, do we have overall agreement that aria-interactive seems like a good idea? I'd like to propose that we actually implement this one behind a flag and try it out.

[Alexander Surkov]

Can we have opinion from AT developers? CC'ing Jamie and Joanie.

Thanks.

Alex.

On Fri, Apr 3, 2015 at 7:01 PM, 'Dominic Mazzoni' via Browser Accessibility Development <browser-acce...@googlegroups.com> wrote:

Reviving this thread. While there are a lot of details to work out, do we have overall agreement that aria-interactive seems like a good idea? I'd like to propose that we actually implement this one behind a flag and try it out.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYyWcVy8gW9yi07VMqWfzvEjoc%3Dhnk-a1x2R0_SGHU_7SQ%40mail.gmail.com.

[Joanmarie Diggs]

Generally speaking, the ability to communicate to an AT, "Hey I'm handling this, step out of the way" seems better to me than a heuristic designed to figure out the same thing.

On Tuesday, April 7, 2015 at 12:49:10 PM UTC-4, Alexander Surkov wrote:

Can we have opinion from AT developers? CC'ing Jamie and Joanie.

Thanks.

Alex.

On Fri, Apr 3, 2015 at 7:01 PM, 'Dominic Mazzoni' via Browser Accessibility Development <browser-acce...@googlegroups.com> wrote:

Reviving this thread. While there are a lot of details to work out, do we have overall agreement that aria-interactive seems like a good idea? I'd like to propose that we actually implement this one behind a flag and try it out.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibility-dev+unsub...@googlegroups.com.

To post to this group, send email to browser-acce...@googlegroups.com.

[Victor Tsaran]

Hi.

For some reason this discussion got stale. Alexander, how difficult / feasible would it be for you guys to impelemnt the aria-interactive attribute? Do you have any objections in this regard?

[Alexander Surkov]

Hi, Victor. On the implementation side there's no need to make any effort in Firefox because if you put aria-interactive attribute on the accessible DOM element then it will be exposed as object attribute in IA2 and ATK. Personally I'm ok with aria-interactive but never looked close at the issue. If everybody is good with the proposal so good I am.

Thanks.

Alexander.

On Mon, May 11, 2015 at 2:40 PM, Victor Tsaran <vts...@gmail.com> wrote:

Hi.

For some reason this discussion got stale. Alexander, how difficult / feasible would it be for you guys to impelemnt the aria-interactive attribute? Do you have any objections in this regard?

On Tuesday, April 7, 2015 at 10:17:04 AM UTC-7, Joanmarie Diggs wrote:

Generally speaking, the ability to communicate to an AT, "Hey I'm handling this, step out of the way" seems better to me than a heuristic designed to figure out the same thing.

On Tuesday, April 7, 2015 at 12:49:10 PM UTC-4, Alexander Surkov wrote:

Can we have opinion from AT developers? CC'ing Jamie and Joanie.

Thanks.

Alex.

On Fri, Apr 3, 2015 at 7:01 PM, 'Dominic Mazzoni' via Browser Accessibility Development <browser-acce...@googlegroups.com> wrote:

Reviving this thread. While there are a lot of details to work out, do we have overall agreement that aria-interactive seems like a good idea? I'd like to propose that we actually implement this one behind a flag and try it out.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.

To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYyWcVy8gW9yi07VMqWfzvEjoc%3Dhnk-a1x2R0_SGHU_7SQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.

To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/ca5c4bf8-31e2-401e-9c9b-edbfb4314ed2%40googlegroups.com.

[Victor Tsaran]

Thanks ALex.

*** *** ***

Find me on Twitter http://www.twitter.com/vick08

[Dominic Mazzoni]

Forwarding a message from Jamie as I accidentally replied off-list.

Here was my original message:

Here's one proposal for behavior that tries to
take this type of control into account, what do you think?

If auto focus mode is not enabled and aria-interactive=true:
1. On a control that would normally engage focus mode, do nothing differently.
2. On a control that would not normally engage focus mode, like a link, optionally announce an extra hint like "press Enter to activate", and on Enter switch to focus mode rather than activating it.
3. On a control that works in both modes, like a radio button, optionally announce an extra hint like "press Enter to activate", and on Enter switch to focus mode in addition to activating it.

If auto focus mode is not enabled and aria-interactive=false, do nothing differently.

If auto focus mode is enabled and aria-interactive=true:
1. On a control that would normally engage focus mode, do nothing differently.
2. On a control that would not normally engage focus mode, like a link, switch to focus mode.
3. On a control that works in both modes, like a radio button, switch to focus mode.

If auto focus mode is enabled and aria-interactive=false:
1. On a control that would normally engage focus mode, do not switch modes.
2. On a control that would not normally engage focus mode, like a link, do nothing differently.
3. On a control that works in both modes, like a radio button, do nothing differently. 

 

Jamie's reply:

The behaviour you suggest takes this type of control into account, but unless I'm missing something, it doesn't allow you to simulate that kind of control using aria-interactive. That is, if you want to have a control which isn't a radio button or a tab control that simply activates when you press enter (i.e. *doesn't* switch to focus mode) but *does* auto switch to focus mode when it gets focus, I don't think you can manage that. Maybe this is an edge case that doesn't need to be considered, but it's worth noting.
1. On a control that would normally engage focus mode, do not switch modes.
This means that aria-interactive="false" and aria-interactive undefined must have two different meanings. That is, we can't assume that aria-interactive always defaults to false. Was that your intent? That's fine if so; it just needs to be made clear in the spec when we get there.

You're absolutely right, but here's my reasoning for not trying to cover all of those cases. The way I see it, we shouldn't try to make web accessibility standards reflect the way screen readers happen to behave today too much, and ARIA attributes should just communicate overall semantic information that can be broadly interpreted by AT. We don't know what devices are going to look like in 5 years and we don't know what AT feature sets are going to be like.

I like aria-interactive=true and aria-interactive=false because they communicate something really clear from the web developer. aria-interactive=true communicates that this control has custom keyboard handlers - or possibly other handlers like gestures - and so the AT should allow the user to focus and send events directly to this control. The reverse, aria-interactive=false, says that this control does not handle any events other than mandatory ones for this role, so there's no point in routing events to it directly.

I feel that's something that's reasonably clear to developers and somewhat future-proof. Screen readers then have to figure out how exactly they want to interpret it.

Also, I can't think of a use-case where a developer would be unable to create a good experience without the ability to explicitly set a control to radio-button-like behavior where it stays in whatever mode you're in. That seems like a nice convenience but not an absolutely critical one for the web app to be able to control.

Anyway, that's my opinion but I'm open to ideas. If you think there could be multiple values for aria-interactive I guess I'd just want to hear a clear definition of what they mean from the perspective of the web app semantics, not specific AT behavior.

- Dominic

[Dominic Mazzoni]

Another wrinkle: aria-interactive is being discussed on public-pfwg right now, but apparently whoever wrote it up never saw the bug I filed and they independently came up with something remarkably similar. I think that's a good sign that this idea is clearly needed as everyone keeps inventing it and picking the same name!

I've pasted the proposed text of aria-interactive, below, from http://rawgit.com/w3c/aria/matt-action1505/aria/aria.html#aria-interactive.

The only thing I dislike is that they're proposing it should only be allowed on roles grid and list. I think it makes sense on a lot of roles, given the example of a presentation editor or form editor where you want to select objects, delete them with backspace, or move them with arrow keys.

If you have an opinion on this, please let it be known!

- Dominic

Here's the text of http://rawgit.com/w3c/aria/matt-action1505/aria/aria.html#aria-interactive

aria-interactive (property)

Indicates that the element provides widget behaviors when focused.

Used in Roles:

grid

list

If a structural element supports aria-interactive, setting aria-interactive "true" will cause the structure to be exposed to assistive technologies as a widget. For example, a structural list can be made into an interactive listview. 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.

If a widget element supports aria-interactive, setting aria-interactive to "false" will cause the element to be exposed to assistive technologies as a structure. For example, an interactive grid can be transformed into a static table. When a user navigates an element that has aria-interactive set to "false", assistive technologies that intercept standard keyboard events should continue to intercept those keyboard events for the purpose of facilitating document browsing, as opposed to passing the keyboard events through to the user agent.

Some elements are only complete when additional descendant elements are provided. For example, in HTML, table elements (matching the grid role) require tr descendants (the row role), which in turn require th or td children (the gridcell , columnheader , rowheader roles). Similarly, lists require list item children. The descendant elements that complete the semantics of an element are described in WAI-ARIA as required owned elements.

When an author applies the aria-interactive property to an element with a WAI-ARIA role that has required owned elements, in addition to exposing the value of aria-interactive for that element with the explicit declaration of the aria-interactive property, the user agent must also apply the same value of aria-interactive to the descendant required owned elements.

When an author applies aria-interactive to a host language element which has an implicit WAI-ARIA role that supports aria-interactive and has required children as defined by the host language specification, in addition to exposing the value of aria-interactive for the element with the explicit value of aria-interactive , the user agent must apply the same value of aria-interactive to any required children. For example, in HTML, a ul or ol element with aria-interactive="true" will automatically have aria-interactive="true" applied to its li elements by the user agent because the list role to which the ul or ol corresponds has a required owned element of listitem .

[Alexander Surkov]

I'm not sure if I see the definition of "structure" in ARIA spec and if the "widget" term describes same matter you refer to [1], but I would rather put aria-interactive into generic words (assuming we have proper structure and widget definitions) like

"If a element supports aria-interactive, setting aria-interactive="true" will cause the element to be exposed to AT as a widget. For example, .. Removing aria-interactive="true" on the element will cause it to be exposed as a structure to AT. For example, ..."

Also I don't see why aria-interactive should be restriction to certain roles. What is reasoning behind that?

[1] http://rawgit.com/w3c/aria/master/aria/aria.html#terms

[Dominic Mazzoni]

On Thu, May 21, 2015 at 7:52 AM, Alexander Surkov <surkov.a...@gmail.com> wrote:

Also I don't see why aria-interactive should be restriction to certain roles. What is reasoning behind that?

I think they don't understand the valid use-cases. Please contribute to public-pfwg so we can try to change their minds.

[Alexander Surkov]

Yeah, I asked couple questions there, it'll be helpful if you answer some of them. Would it be useful if you put some use-cases into the spec draft?

--
You received this message because you are subscribed to the Google Groups "Browser Accessibility Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to browser-accessibil...@googlegroups.com.
To post to this group, send email to browser-acce...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/browser-accessibility-dev/CAFz-FYz1yerDigyzPynQc1z31%3D5ewob-Pf35Tum_Cz_4aZhF1g%40mail.gmail.com.