[Webkit-unassigned] [Bug 146239] AX: accessibles for focusable/interactive <tbody> elements or elements with ARIA role='rowgroup'

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=146239

Joanmarie Diggs (irc: joanie) <jdiggs at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #4 from Joanmarie Diggs (irc: joanie) <jdiggs at igalia.com> ---
(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. :-/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150712/c53376ec/attachment.html>