Re: Please clarify ARIA definition of "grid" role

Maciej,

Typical object inheritance hierarchy states clearly indicates that a grid
is a table but with additional features. A base concept states that a grid
is "like" a table but not actually a table. A good analogy would be that a
spreadsheet is a table but a table is not a spreadsheet. At one time we had
a table role in ARIA but after some discussions with others, including the
Ian, we agreed that for now we would simply rely on an HTML Table and force
people to use the HTML table. For ARIA 2.0, however, and as a result of
these discussions we have agreed to discuss adding a table role to ARIA
2.0. This may benefit SVG as well.

Conversely a table is NOT  a grid. It is not interactive by nature and and
it does not allow the user to navigate it in a pre-determined fashion. This
is clearly stated in the ARIA spec. What we will be doing is bringing these
additional aspects of grid from the text into the one line definition as we
discussed.

Now if you make a grid apply to tables we have a serious problem. The fact
that grids are interactive and the author supplies the keyboard navigation
for them is an indicator to screen readers that they must stop stealing
browser keys and pass them off to the web application. If we allow grids to
apply to static tables that would be a serious break in AT support of ARIA
which we cannot have.

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From: Maciej Stachowiak <mjs@apple.com>
To: James Craig <jcraig@apple.com>
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Steve Faulkner
            <sfaulkner@paciellogroup.com>, public-pfwg-comments@w3.org
Date: 09/07/2010 02:00 PM
Subject: Re: Please clarify ARIA definition of "grid" role




On Aug 31, 2010, at 8:08 PM, James Craig wrote:

>>>
>>> This still isn't right. The BaseConcept of grid is "HTML table", and
the Required Owned Elements for grid are:
>>>    • row
>>>    • rowgroup → row
>>>
>>> Last November at the F2F, we added the rowgroup role specifically so
that ARIA grids could have role symmetry with the HTML table child elements
thead, tbody, and tfoot.
>>>
>>>    rowgroup http://www.w3.org/WAI/PF/aria/complete#rowgroup

>>>    BaseConcept: HTML thead, tfoot, and tbody
>>>    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.
>>>
>>> One of the reasons we needed role symmetry was due to the complexities
of presentation inheritance with host language implicit semantics.
>>>
>>> From the spec: http://www.w3.org/WAI/PF/aria/complete#presentation

>>
>> Would this imply that the "grid" definition *should* cover
non-interactive presentations of tabular data, such as HTML <table>?
>
> That's my understanding, but it's obvious we have some differing opinions
in the group. We'll need to discuss this in a Working Group call before we
can answer definitively.
>
>> That is fine by me. I just want the ARIA spec and the HTML5 spec to be
in sync on this.
>
> Agreed. Thanks.
>
>> The thing I didn't like about Rich's proposal is that it would make HTML
<table> be a "grid but not really". I don't think that is a useful state.
Either it's a grid or it's not.
>>
>> I have no personal stake in the question of whether it is actually a
grid. I just want it to be one or the other.


Ian mentioned in the bug that the "grid" role mentions "HTML table" as the
"Base Concept", and that he took this to mean that an HTML table *is* a
grid.

He also mentions that the rowgroup role description says: "The rowgroup
role establishes a relationship between owned row elements. It is a
structural equivalent to the thead,tfoot, and tbody elements in an HTML
table element."

These things really make it seem like <table> is encompassed in what "grid"
covers.

At this point, I think ARIA needs to be updated to make this issue crystal
clear one way or the other.

I am personally leaning to making "grid" apply even to non-interactive
tables. From the point of view of an assistive technology, I suspect the
issues in presenting and navigating a table vs a grid are quite similar; it
seems to me that it's the tabular presentation that is essential, not
whether there are keybindings to move between cells. Furthermore, a
definition that depends on specifically *keyboard* navigability is
problematic because it is not device-independent. Touchscreen devices with
no keyboard (such as Apple's iOS family of devices) are increasingly
popular, and iOS in particular offers strong accessibility support. In the
touchscreen paradigm, there is no such thing as a keyboard navigable grid;
everything is done through direct manipulation, whether it is meant to be
"interactive" or not.

Ultimately, though, this is a matter for PFWG to decide. I think it's
important to have a clear decision on this and update the ARIA spec to
match, so that HTML5 can be brought in sync.

Regards,
Maciej