This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This is similar to bug 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>
I agree that this would be useful and would supply a solution to the bug I filed. I would like to propose an extension to the proposal that would make it normative to expect ALL AT to suspend all event interception including keyboard interception, touch and gesture interception etc. when the focus is on an element where the value of this attribute is true. The exception to this would be the gestures/keyboard events that allow navigation off the element itself. This would allow this attribute to also be used in cases where custom gestures are required. In addition, this attribute should also require that AT and browser work together to ensure that all accessible name, state and value changes to the element while it has focus, are announced immediately to the user.
Don't know how that double comment happened - apologies
https://github.com/w3c/aria/issues/746