Re: Question about the new/proposed "tbody" role for tables

+1 for wontfix

On Wed, Apr 1, 2015 at 9:27 AM, Joanmarie Diggs <jdiggs@igalia.com> wrote:

> Hey James, all.
>
> Fair enough. I guess we should remove the note about the 2.0 issue which
> was raised then. While that note doesn't say we plan to fix the issue,
> it could be interpreted as meaning that. At least that was my
> interpretation. :) If we all agree it's a WONTFIX, that potential
> interpretation should not be encouraged.
>
> Do we all agree it's a WONTFIX?
>
> --joanie
>
>
> On 04/01/2015 02:59 AM, James Craig wrote:
> > I don't think we should do this.
> >
> > There is no practical benefit that I can see for the API mappings, and
> it makes the ARIA spec more complicated. Authoring accessible plain-old
> semantic HTML is already challenging enough, authoring complex interactive
> ARIA widgets like treegrids is next to impossible.
> >
> > We should be striving to make ARIA easy to author. That means editing
> what we've got, deprecating the failed parts like drag-and-drop, and *only*
> adding new features when they serve a practical need that cannot be
> resolved any other way.
> >
> > James
> >
> >
> >> On Mar 31, 2015, at 7:20 PM, Joanmarie Diggs <jdiggs@igalia.com> wrote:
> >>
> >> Hi all.
> >>
> >> As you know, right now we have a generic "rowgroup" role, along with a
> >> note [1] that states:
> >>
> >>    Note: This role does not differentiate between types of row groups
> >>    (e.g., thead vs. tbody), but an issue has been raised for WAI-ARIA
> >>    2.0.
> >>
> >> Given that we're creating the new non-interactive table roles for 1.1, I
> >> think we can/should address the above now, creating ARIA roles thead,
> >> tfoot, and tbody. If you don't agree with this, please tell me now. :)
> >>
> >> If you do agree these roles should be created: My plan was to make
> >> thead, tfoot, and tbody subclasses of the current rowgroup role. An ARIA
> >> table or grid could have at most one ARIA thead and one ARIA tfoot, just
> >> like in HTML. The question is what about ARIA tbody?
> >>
> >> HTML lets you have multiple tbody elements, so we could do that as well.
> >> However, HTML also prescribes exactly where these tbody elements can be
> >> placed. ARIA, on the other hand has aria-owns. I think a non-interactive
> >> ARIA table which can have an unspecified number of ARIA tbody instances
> >> that can be scattered throughout the DOM thanks to aria-owns is asking
> >> for trouble.
> >>
> >> The solutions that spring to my mind are:
> >>
> >> 1. You can have at most one ARIA tbody, but can then further delineate
> >>   the rows in that tbody into ARIA rowgroups.
> >>
> >> 2. You can have as many ARIA tbody instances as you want, just like
> >>   HTML. But then you cannot use aria-owns to place them outside of
> >>   the parent ARIA table or grid.
> >>
> >> My personal preference at the moment is for option 1. But it's not a
> >> strong preference. Whatever works for authors and user agents and in the
> >> end is accessible via the accessible table interface is fine by me.
> >>
> >> Mind you, if everyone thinks it's no problem to have however many tbody
> >> instances you want, and put them wherever in the DOM you want, and the
> >> accessible table interface implementation for that table will work as
> >> expected for each platform.... I'm skeptical, but ok. :)
> >>
> >> Lemme know. Thanks!
> >> --joanie
> >>
> >> [1] http://www.w3.org/TR/wai-aria/roles#rowgroup
> >>
> >
> >
>
>
>