RE: Agenda: August 27, 2015 WAI-PF ARIA Caucus (Correction I am still chairing this week)

James,

>>> For example, what's the real-world need to focus a row group?

A row group can represent the entity of orders by an individual customer by subrows.

Level 1       Level 2
-----------------------
            | Order 1 |
Customer 1  | Order 2 |
            | Order 3 |
-----------------------

Suppose the fact you want to *select entire* row group (all orders by an individual customer) by keyboard.

For the sake of signaling to UI user “you have selected all orders” it could be clever to trigger selection of all subrows at a glance.

To do so, you can activate mouse or keyboard the level 1 header (will act as row selector). The individual order selection is by activation of level 2 headers.

The question is now for me where the keyboard focus for activation is and what that semantically MEANS.

In this example, the focus will be put on the active level 1 header cell customer for activation/selection. The point is, doing so, one has “by principle” influenced semantically (not technically focused) the entire rowgroup.

So bottom line, there is maybe no need to focus frame *technically* a whole rowgroup (you run into keyboard nav definition issues, too), but entire rowgroup is affected by active header interactions.

More and more I’m convinced that active headers of grids and tables should be given more love within ARIA concepts. There should be already on definition level roles/indicators when table/grid cell headers allow for selection of row content (row/column selector role/attribute). But maybe we have that implicitly already and I just missed it ..


-    Stefan


From: James Craig [mailto:jcraig@apple.com]
Sent: Mittwoch, 9. September 2015 04:13
To: Richard Schwerdtfeger
Cc: Joseph Scheuhammer; PF
Subject: Re: Agenda: August 27, 2015 WAI-PF ARIA Caucus (Correction I am still chairing this week)

Rich wrote:

Asking the group to waste cycles finding a real world example where this element is used is a waste of people's time for something we just want to protect the user against in case it happens.
It seems like a waste of time to ask an engineering team to make an explicit change to a rendering when, as you say, "There was NO real world need for it…"
The right thing would be to NOT have rowgroup receive a tabindex at all but the browser vendors decided differently. There was NO real world need for it to receive tabindex.
I think the right fallback behavior is for a focusable thead/tfoot/tbody to be exposed as a generic focusable element, which would invalidate the containing table's semantic role.

…unless there is a valid need to focus a rowgroup. It seems like you're saying there is no need.

More importantly, the "group" role is not identical to the generic role. Otherwise there would be no difference between <div> and <div role="group">... This is not a cleanup exercise. Changing all generic elements to be exposed as groups would have very broad and undesirable effects.

James



On Sep 8, 2015, at 4:58 PM, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>> wrote:

James,

What the group is trying to do is deliver consistency across browsers. All the other browsers, except Safari, are consistent. This is a cleanup exercise.

Do we see a lot of use of this? No.

However, the fact that the HTML working group decided to make every element accept a tabindex and rowgroup can receive focus we had to address the gap in the browsers.

Do we think this will happen a lot? No.

There needs to be some degree of predictability in the browser implementation. Should, for whatever reason, an author put tabindex on this useless element the user will receive a very confusing user experience that only impacts the user of the assistive technology as the user who is not impaired will see physical showed in the UI around the rowgroup.

Asking the group to waste cycles finding a real world example where this element is used is a waste of people's time for something we just want to protect the user against in case it happens. The right thing would be to NOT have rowgroup receive a tabindex at all but the browser vendors decided differently. There was NO real world need for it to receive tabindex.

Rich


Rich Schwerdtfeger

[Inactive hide details for James Craig ---08/31/2015 03:39:43 PM---Is there a real-world use case that does this? It seems like]James Craig ---08/31/2015 03:39:43 PM---Is there a real-world use case that does this? It seems like a pretty complicated example to discuss

From: James Craig <jcraig@apple.com<mailto:jcraig@apple.com>>
To: Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>>
Cc: PF <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>
Date: 08/31/2015 03:39 PM
Subject: Re: Agenda: August 27, 2015 WAI-PF ARIA Caucus (Correction I am still chairing this week)
________________________________



Is there a real-world use case that does this? It seems like a pretty complicated example to discuss as a theoretical problem.

For example, what's the real-world need to focus a row group?

James


> On Aug 26, 2015, at 9:02 AM, Joseph Scheuhammer <clown@alum.mit.edu<mailto:clown@alum.mit.edu>> wrote:
>
> Hi James,
>
> On 2015-08-25 12:40 PM, Richard Schwerdtfeger wrote:
>>
>> *Agenda: August 27, 2015 WAI-PF ARIA Caucus*
>> ...
>>
>>    6. Action 1578 Discuss Issue 700 with the Working group (Should
>>    rowgroup, tbody, and thead have any role mapping in AAPIs? should
>>    there be an accessible object?
>>    or, should it be a generic object? (Rich)
>>      o I believe we discussed this and we made the "group" role the
>>        generic role. This would be consistent with IE and Safari
>>        mappings. Shouldn't this be closed?
>>      o _https://www.w3.org/WAI/PF/Group/track/issues/700_

>>      o _https://www.w3.org/WAI/PF/Group/track/actions/1578_

>>
>
>
> Rich notes above, "I believe we discussed this and we made the 'group' role the generic role".  I can confirm that the AAPI group decided to change the mappings for role="rowgroup" to a generic group-like role for the various platforms [1].  The reason is that authors can create a grid with rowgroup elements that are focusable and interactive (e.g., respond to clicks) [2].
>
> However, the statement, "This would be consistent with IE and Safari mappings" is not correct with respect to Safari.  The current AXAPI mapping for rowgroup is "Not mapped".  There is a webkit bug in this regard [3].  What is the current thinking regarding AXAPI's mapping of the rowgroup role?
>
> Thanks.
>
> [1] http://w3c.github.io/aria/core-aam/core-aam.html#role-map-rowgroup

> [2] http://clown.idrc.ocad.ca/Fluid/aria/FocusableRowGroup.html

> [3] https://bugs.webkit.org/show_bug.cgi?id=146239

>
> --
> ;;;;joseph.
>
> 'Array(16).join("wat" - 1) + " Batman!"'
>           - G. Bernhardt -
>