Re: Mapping for interactive rowgroup/tbody (was: Thoughts on nested rowgroups?)

Seems like this example:
http://clown.idrc.ocad.ca/Fluid/aria/FocusableRowGroup.html
Should be a table-- not a grid.

This is a pretty good use case for interactive rowgroups.

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:   Joseph Scheuhammer <clown@alum.mit.edu>
To:     James Craig <jcraig@apple.com>, 
Cc:     W3C WAI Protocols & Formats <public-pfwg@w3.org>
Date:   05/19/2015 07:06 AM
Subject:        Mapping for interactive rowgroup/tbody (was: Thoughts on 
nested rowgroups?)



Hi James,

A while back (2015-04-02 8:30 AM) I wrote:

> The AAPI task force has been working on better mappings for role 
> rowgroup for the past month, and the mapping specs are likely going to 
> change.
>
> We are converging on the following:  If an element has 
> role="rowgroup", it is generally not mapped.  If, however, it is 
> focusable, is interactive, or has some global aria-* property on it, 
> then it will be mapped.
>
> If you agree, how would AX API map it?

You replied (2015-04-03 5:09 AM):

> If there are other attributes on it, then presumably we'd map it as 
something other than a rowgroup.
>
> Tables and grids are tricky. WebKit glosses over as many author errors 
as it can, but when an author vends a malformed grid, WebKit avoids 
exposing it to the APIs as a malformed table. WebKit instead falls back to 
exposing the content in generic containers (e.g. just back to the div soup 
the author provided). A focusable rowgroup should probably be one of the 
heuristics that would cause WebKit to refrain from exposing the table to 
the API as a table.
>
> I mentioned this during the CR phase of ARIA 1.0. Many of the test case 
examples were malformed (e.g. <div role="row"></div> with no child cells 
or containing grid). Mozilla mapped these directly and left it to the 
assistive technology to figure out, but WebKit avoids exposing orphaned 
child roles to the APIs.

Yes, sometimes authors produce a poor div soup when it comes to 
interactive grids and tables.  And, yes, the ARIA 1.0 tests with respect 
to grid were lacking.

But, what about valid grids and tables?  What happens when a developer 
makes the effort to properly create a table or grid and make some tbody 
or rowgroup interactive?

Consider a train time table where a rowgroup or tbody is used to group 
morning rush hour, afternoon, and evening rush hour departure times 
separately.  The author also leverages these groupings such  that users 
can show only the departure times they are interested in.

A rough example is given here:
http://clown.idrc.ocad.ca/Fluid/aria/FocusableRowGroup.html

This is a case where rowgroup roles or tbody elements are focusable and 
interactive.  The current proposal is that in this case, the rowgroup or 
tbody should have an accessible in the tree to represent this 
interactivity.

Earlier you wrote, "If there are other attributes on it, then presumably 
we'd map it as something other than a rowgroup".  How would it be mapped 
under AXAPI?

Thanks.

-- 
;;;;joseph.

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