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

Thinking of a button inside an editable area, whether the button is not
interactive or not, because it has 'enter' keystroke to edit its label (the
example from your previous mail). Wouldn't it mean an interaction on the
button?

On Tue, May 19, 2015 at 5:04 PM, Dominic Mazzoni <dmazzoni@google.com>
wrote:

> So your saying is that using aria-interactive would not change the
>> effective role for a widget role, only that there is some, hopefully
>> discoverable, interactive behavior associated with this element,
>>
>
> Yes.
>
>
>> where as part of the current proposal is aria-interactive=false would
>> change GRID/GRIDCELL roles to TABLE/TD.
>>
>
> I don't like the idea that aria-interactive=false turns a grid cell into a
> table cell. I think the main issue should be whether it's focusable or not
> - if it's focusable then it's an interactive grid, and if not then it's a
> table and may have interactive things in the cells optionally.
>
> I'd totally support having "table" and "tablecell" roles. That'd be very
> clear.
>
> I think aria-interactive=false on a grid cell would only imply that you
> wouldn't switch to focus mode / forms mode.
>
> aria-interactive seems like it could have a lot of different meanings and
>> effects, so how will all these meanings be defined and explained?
>>
>
> The way it's written up here
> <http://rawgit.com/w3c/aria/matt-action1505/aria/aria.html#aria-interactive>,
> I agree it sounds complicated.
>
> Here's the original bug I filed:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27866
>
> I would simplify the explanation to just this:
>
> * It indicates whether or not this element has interactive actions that
> can be performed on it when focused.
> * 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.
>
> That's it.
>
> I'd get rid of any implications that it changes what role is exposed, or
> whether it gets propagated or inherited. I don't think any of that is
> necessary.
>
> However, I would do one other thing which is to add a default (implied)
> value of aria-interactive for each role that corresponds to how screen
> readers currently interpret it. So role=listbox implies
> aria-interactive=true but role=checkbox implies aria-interactive=false.
> That way web authors know they only need to override it if it's not already
> the default for this role.
>
>
>>   Is it better to overload a single attribute with a lot of different
>> features or to have more refined roles and attributes that better describe
>> the type of interaction or function of the content?
>>
>
> Basically, I don't think aria-interactive should affect roles at all. We
> should just pass it straight through to AT as an additional hint.
>
>
>
>
>
>
>>
>>
>> Jon
>>
>>
>>
>> *From:* Dominic Mazzoni [mailto:dmazzoni@google.com]
>> *Sent:* Tuesday, May 19, 2015 2:11 PM
>> *To:* Matthew King
>> *Cc:* Alexander Surkov; Gunderson, Jon R; W3C WAI Protocols & Formats
>> *Subject:* 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>