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

I'm happy to see this initial work on aria-interactive!

On Thu, May 14, 2015 at 2:29 PM, Matthew King <mattking@us.ibm.com> wrote:

> Initially, aria-interactive can only be set on grid, treegrid, list, and
> directory.


I think we should allow it on every role, e.g. widget roles like button,
checkbox, link, etc. but even other roles like heading, etc.

The use-case I have in mind is for editing-type applications.

Consider a form editor, i.e. an application that lets you create web forms.
When the form is in "editing" mode, you might want to focus a control
you're interested in, then press Backspace to delete the form from the
page, or up/down arrows to rearrange where that control is in the order.
Pressing Enter might let you edit the control's name.

A similar example is for slide editors like Google Presentations or Prezi
where you've got a slide composed of a bunch of objects. The heading at the
top of the slide deserves a role of heading, and when viewing slides that's
what it should get. But what about in editing mode? It doesn't make sense
to just always make it a text box - it should be a heading with
aria-interactive=true, then you can activate it to edit its text, or
instead press Backspace to delete it, arrow keys to move it around the
slide, and so on.