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

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



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>
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, 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.