Need an aria-interactive attribute to indicate a control has its own keyboard handlers

[jnurthen]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27866

This is similar to bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=27576, but a possibly different approach. I also wrote about this at http://www.w3.org/WAI/PF/wiki/ARIA_2_Requirements (search for aria-interactive).

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>

[carmacleod]

This would be really useful. Particularly if it was paired with aria-interactivedescription in the same way that role can have a roledescription.

So, for the interactive slide title example, authors could say something like:

<h1 tabindex=0
    aria-interactive="true"
    aria-interactivedescription="press the arrow keys to move the title; press Enter to edit the title text">
    Slide title
</h1>

For a "pan control" in a map, authors could give a role description and a description of the interaction:

<...
    roledescription="pan"
    aria-interactive="true"
    aria-interactivedescription="press the arrow keys to pan north, south, east or west"
>

[devarshipant]

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>

This can be helpful.

Question: Since keyboard navigation instructions and methods vary depending on the type of control, shouldn't there be a role too? Wouldn't the screen reader vendor need a role to map navigation keys in forms mode?

[carmacleod]

Wouldn't the screen reader vendor would need the role to map navigation keys in forms mode?

Yes, I guess a text description isn't enough info for the AT. They'd need a list of keys to pass through.

Anyhow, I'm guessing this is a pipe dream. It would be very powerful, but...

"With great power comes great responsibility...". ;)

[stes-acc]

A good start would be to influence AT vendors to extend their "forms mode" control set that it covers all active ARIA roles and does automatic mode switching from reading modes to interaction modes when encountering those with active handlers on it. This should be the first step.

Before inventing a new property aria-interactive this should be clarified if classic solutions can do the trick, too.

For things that remain like active headings (the example) I think we have two options

<span role="button" tabindex="0" onclick="doSomething()"><h1> Do something</h1></span>

or

<h1><span role="button" tabindex="0" onclick="doSomething()">Do something></span></h1>

Focus is on button element in both cases. Which variant is correct for HTML validators? And, having clarified that, what should AT announce? "Button Heading Level 1 Do Something" or "Heading Level 1 Button Do something"?? Or just one role? Who defines this?

But if you have active stuff that is considered by HTML as inactive: it does not help to declare clickable headings as "red herring" in HTML because people do code this. And it is needed and simply useful. Another example are active list items. Even entire sections can be active and are coded already likewise (especially triggered by Tap on mobile devices).

I doubt that an aria-interactive flag will be correctly understood and accepted by AT since then many discussions will start and interaction algorithm was always based on known role for an element and this is (by nature) totally unknown for a heading since it is not interactive. The only thing that would help in my opinion is that HTML5 itself extends its definitions what is an active element and what is not and will never be.

Headings and list items would be a good start to be included in the first list. Consequently, for all elements interactions are NOT allowed browsers immediately should stop the JS event support (since this is invalid code then) and THAT is the can of worms they want to avoid at all cost because it will break tons of code out there.

Regarding ARIA 1.1: in the end it would be better to collect ARIA structural roles that may be used also interactively and use aria-roldescription to express that when it is so and aria-describedby for a keyboard usage description (having no designated property for this yet). But this requires that AT is reading and announcing roledescription also for structural roles which is not so 100% clear for me in the moment that they will do that.