Bug 146239 - AX: accessibles for focusable/interactive <tbody> elements or elements with ARIA role='rowgroup'
Summary: AX: accessibles for focusable/interactive <tbody> elements or elements with A...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-06-23 09:58 PDT by Joseph Scheuhammer
Modified: 2019-10-22 00:16 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Scheuhammer 2015-06-23 09:58:46 PDT
Webkit does not provide an accessible object for <tbody> elements nor elements with the ARIA role='rowgroup'.  However, there are cases where the <tbody> or rowgroup is focusable and interactive.  Here, "interactive" means responds to user mouse clicks and keystrokes.

Two examples are given on the following page:
http://clown.idrc.ocad.ca/Fluid/aria/FocusableRowGroup.html

Both examples are of a commuter train time table where a rowgroup or tbody is used to group morning rush hour, afternoon, and evening rush hour departure times separately.  The first example uses a <div role='rowgroup' ...>, while the second uses multiple <tbody> elements to make these groupings.  These groupings are configured such that users can show only the departure times they are interested in -- they can click on a grouping to hide that grouping, and/or move keyboard focus to it, and hide it with a SPACE  keystroke.

It is expected that there be accessible objects in the accessibility tree for these elements.  Also, that these accessibles show a focus state when they have focus.

However, the Accessibility Inspector app shows that
1. There is no accessible for the interactive rowgroup/tbody elements.
2. When DOM focus is on one of the rowgroup/tbody elements, the inspector shows that focus is on the AXWebArea (pretty much the entire web page).
Comment 1 Radar WebKit Bug Importer 2015-06-23 09:59:18 PDT
<rdar://problem/21505582>
Comment 2 James Craig 2015-07-07 00:02:27 PDT
rowgroups should not be focusable. We added this to ARIA purely so that we could make the algorithm for presentational inheritance work. See #presentation: 

http://www.w3.org/TR/wai-aria/complete#presentation
"Likewise, although an HTML table element does not have an implicit native semantic role corresponding directly to a WAI-ARIA role, the implicit native semantics of its thead/tbody/tfoot/tr/th/td descendants will also be removed, because the HTML specification indicates that these are required structural descendants of the table element."

The role mapping for "rowgroup" was explicitly defined as "no mapping" but unfortunately Alex didn't get the memo and added it to Firefox.

ARIA 1.1 should be updated to make it clear that making a rowgroup focusable is an authoring error.
Comment 3 Joseph Scheuhammer 2015-07-09 07:40:54 PDT
(In reply to comment #2)
> rowgroups should not be focusable. We added this to ARIA purely so that we
> could make the algorithm for presentational inheritance work. See
> #presentation: 
> 
> http://www.w3.org/TR/wai-aria/complete#presentation
> "Likewise, although an HTML table element does not have an implicit native
> semantic role corresponding directly to a WAI-ARIA role, the implicit native
> semantics of its thead/tbody/tfoot/tr/th/td descendants will also be
> removed, because the HTML specification indicates that these are required
> structural descendants of the table element."

The specification also says that rowgroup is to be used only in the context of a grid:
http://www.w3.org/TR/wai-aria/complete#rowgroup
"Authors MUST ensure elements with role rowgroup are contained in, or owned by, an element with the role grid."

An element with role="grid" is the opposite of an element with role="presentation".  If authors follow this aspect of the spec, rowgroups should only appear in an interactive context, and never in a presentational one.

> 
> The role mapping for "rowgroup" was explicitly defined as "no mapping" but
> unfortunately Alex didn't get the memo and added it to Firefox.
> 

I've discussed this with Alex.  His is a considered approach.  And, the other attendees of the AAPI meetings have moved away from the "not mapped" position.  All platforms, except AXAPI, now define mappings for rowgroup:
http://w3c.github.io/aria/core-aam/core-aam.html#role-map-rowgroup

The rationale is that if an element is focusable and can emit AAPI events, then it must have some representation in the accessibility tree.  Put another way, if the non-AT user can interact with the element, so can the AT user.  The price, exposing an accessible, doesn't seem that steep.

> ARIA 1.1 should be updated to make it clear that making a rowgroup focusable
> is an authoring error.

That is another way to resolve the situation. If that's what the group decides then ARIA 1.1 should go on to say that if an author desires to make a rowgroup focusable/clickable, they should not use the rowgroup role, but some other role.

Also, these recommendations would apply to the <tbody>, <thead>, and <tfoot> elements.  That is, if authors should not make rowgroup focusable, then likewise authors should not make <tbody>, <thead>, nor <tfoot> focusable.
Comment 4 Joanmarie Diggs 2015-07-12 14:23:25 PDT
(In reply to comment #2)
> rowgroups should not be focusable. We added this to ARIA purely so that we
> could make the algorithm for presentational inheritance work. See
> #presentation: 
> 
> http://www.w3.org/TR/wai-aria/complete#presentation
> "Likewise, although an HTML table element does not have an implicit native
> semantic role corresponding directly to a WAI-ARIA role, the implicit native
> semantics of its thead/tbody/tfoot/tr/th/td descendants will also be
> removed, because the HTML specification indicates that these are required
> structural descendants of the table element."
> 
> The role mapping for "rowgroup" was explicitly defined as "no mapping" but
> unfortunately Alex didn't get the memo and added it to Firefox.

I agree with you in spirit: Mapping rowgroups on my platform results in objects with ATK_ROLE_PANEL showing up in yet another place where they (imho) don't belong. By the same token, an author can make a rowgroup interactive. If an author does that, how do we then make that interactive rowgroup accessible if we've pruned it from the tree?
 
> ARIA 1.1 should be updated to make it clear that making a rowgroup focusable
> is an authoring error.

We could.... However, I fear that the outcome of stating in the spec that "making a rowgroup focusable is an authoring error" won't be that authors cease JavaScripting rowgroups into interactivity (and thus solving the mapping problem); instead, they'll just remove the tabindex, leaving us with a non-keyboard-focusable interactive rowgroup. So unless we can make it clear that making a rowgroup interactive is an authoring error, I think we do need to map rowgroup -- at least the interactive ones. And I think we do not want to do anything that encourages authors to remove tabindex from their interactive rowgroups.

I'm reopening this bug. If you (James) believe that an *interactive* rowgroup should never be exposed on your platform, let's slap an "[ATK]" into the bug's summary. Because as much as I don't like the idea, I've come to accept the fact that this practice exists in the wild and that we need to cope with it as best we can. :-/
Comment 5 James Craig 2015-07-15 01:08:24 PDT
Copying Chris F for opinion. Mapping rowgroup to anything will result in malformed AXTables on OS X, which could prevent VoiceOver from accessing the content. I'm not sure what the right solution should be.
Comment 6 James Craig 2015-07-15 01:10:33 PDT
Leaning towards: expose the content as generic, focusable elements, but not as tables because of the authoring error.
Comment 7 Joanmarie Diggs 2015-08-25 13:07:53 PDT
Ping? Chris and/or James: For a table-y element (i.e. one in which clearly looks and acts like a table, such as a bus schedule), is it really an authoring error to have a group of rows in the table focusable? And is it indeed desirable to remove the table role in that instance?
Comment 8 James Craig 2015-08-31 13:33:55 PDT
Is there a real-world use case that does this? It seems like a pretty complicated example to discuss as a theoretical problem.