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

Rich,

Will the inverse also work if you put aria-interactive=true on a TABLE element will it change the effective role to GRID and TD into GRIDCELLs?

Jon


From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Thursday, May 21, 2015 9:02 AM
To: Alexander Surkov
Cc: Dominic Mazzoni; Gunderson, Jon R; Matthew King; W3C WAI Protocols & Formats
Subject: 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

[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<mailto:surkov.alexander@gmail.com>>
To: Dominic Mazzoni <dmazzoni@google.com<mailto:dmazzoni@google.com>>
Cc: "Gunderson, Jon R" <jongund@illinois.edu<mailto:jongund@illinois.edu>>, Matthew King/Fishkill/IBM@IBMUS, "W3C WAI Protocols & Formats" <public-pfwg@w3.org<mailto: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<mailto: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<https://urldefense.proofpoint.com/v2/url?u=http-3A__rawgit.com_w3c_aria_matt-2Daction1505_aria_aria.html-23aria-2Dinteractive&d=AwMFAw&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=6sD7t8t4R7muXgN98CfG2dt4Z23BgbTC85TAcJuIQSM&s=--xSpFIycEtaUagkimblV-j3rvJy5TCHa9butvQp5JI&e=>, I agree it sounds complicated.

Here's the original bug I filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27866<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_Bugs_Public_show-5Fbug.cgi-3Fid-3D27866&d=AwMFAw&c=8hUWFZcy2Z-Za5rBPlktOQ&r=REZD8fc2AwufInstfW3L5jSLVS8bjZtAodDOhat7yAI&m=6sD7t8t4R7muXgN98CfG2dt4Z23BgbTC85TAcJuIQSM&s=Y1642vF4iMB_VPiHN5B_v9EF3bHfnI9bpiwnelZ3_TQ&e=>

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<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<mailto: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.