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

Dominic Mazzoni <dmazzoni@google.com> wrote on 05/19/2015 02:04:12 PM:
> 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.

Dominic, that is the definition of grid; grid is always interactive. There 
is no need for aria-interactive to say that a grid is interactive; it is 
by default.

> I'd totally support having "table" and "tablecell" roles. That'd be 
> very clear.

The primary reason aria-interactive is being introduced at this time is to 
avoid having table and tablecell roles. That is the reason for its 
current, and I agree complex, description and requirements.

> I think aria-interactive=false on a grid cell would only imply that 
> you wouldn't switch to focus mode / forms mode.

If the table is static -- non-interactive, then don't make it a grid. In 
HTML this is entirely possible since there is a table element.

> Here's the original bug I filed: 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27866

Unfortunately, bug 27866 was not on the agenda or part of the discussion 
of aria-interactive. Bug 27866 is for a completely different kind of 
issue. And the language used (aria-interactive) is just coincidentally the 
same.

The items on the agenda for ARIA 1.1 are all in tracker; I do not think 
bugzilla is being used at all for that purpose.

I think if we mix the 2 sets of issues, the conversation will become 
hopelessly convoluted.

The not so great, but perhaps equally workable, ARIA 1.0 answer to bug 
27866 is role=application complemented by judicious use of 
aria-describedby on contained elements. I am not a fan of the application 
role, and I look forward to ARIA 2.0 for better approaches.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   Dominic Mazzoni <dmazzoni@google.com>
To:     "Gunderson, Jon R" <jongund@illinois.edu>, 
Cc:     Matthew King/Fishkill/IBM@IBMUS, Alexander Surkov 
<surkov.alexander@gmail.com>, "W3C WAI Protocols & Formats" 
<public-pfwg@w3.org>
Date:   05/19/2015 02:04 PM
Subject:        Re: aria-interactive and the authoring/debug process 
problems



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.