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

I'm not sure whether it's semantically correct. Is a grid inside an
editable area still interactive?

On Thu, May 21, 2015 at 10:02 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:

> Alex, for ARIA 1.1 we are going to limit the use of aria-interactive. By
> default, widgets are considered to be interactive.
>
> If you put aria-interactive="false" on a grid why can't you simply map the
> role as "cell" to the AT like you do table? I don't see why the the browser
> can't handle this.
>
>
> Rich Schwerdtfeger
>
> [image: Inactive hide details for Alexander Surkov ---05/21/2015 08:55:28
> AM---Thinking of a button inside an editable area, whether th]Alexander
> Surkov ---05/21/2015 08:55:28 AM---Thinking of a button inside an editable
> area, whether the button is not interactive or not, because
>
> From: Alexander Surkov <surkov.alexander@gmail.com>
> To: Dominic Mazzoni <dmazzoni@google.com>
> Cc: "Gunderson, Jon R" <jongund@illinois.edu>, Matthew
> King/Fishkill/IBM@IBMUS, "W3C WAI Protocols & Formats" <public-pfwg@w3.org
> >
> Date: 05/21/2015 08:55 AM
> Subject: 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*
> <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*
>    <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*
>       <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*
>       <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.
>
>
>
>
>
>
>
>
>
>
>
>
>