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

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
>>
> 
>

Received on Wednesday, 1 April 2015 13:28:07 UTC