Re: issue-606 and aria-colindex, aria-rowindex

I wonder whether rowspan/colspan is more easy to use technique than
colindex/rowindex one. That's closer to HTML markup and may require less
computations.
Thanks.
Alexander.

On Sat, Oct 11, 2014 at 3:24 PM, Daniel Trebbien <dtrebbien@gmail.com>
wrote:

> Hi,
>
> I was wondering if there is an update on adding aria-colindex and
> aria-rowindex attributes to the gridcell and row roles?
>
> aria-colindex and aria-rowindex were mentioned at a November 5, 2013
> teleconference:
> http://www.w3.org/2013/11/05-aapi-minutes.html#item03
>
> .. and then two weeks later at a November 19, 2013 teleconference:
> http://www.w3.org/2013/11/19-aapi-minutes.html#item01
>
> The most recent discussion that I could find is from a May 5, 2014
> teleconference:
> http://www.w3.org/2014/05/05-aria-minutes.html#item03
>
> These would be very useful additions for creating large AJAX-backed
> tables, where the data for rows are only downloaded by the web application
> when the user views them.  For example, the application might know that
> there are 150,000 total rows in a table, but the user is only viewing rows
> 1000 through 1020, so the application only has to download the data for
> those rows.
>
> Because aria-colindex and aria-rowindex are not supported, the only
> solution is to try to use HTML rowspan and colspan attributes to make the
> table model match the data model.  However, browsers that I have tested
> (Chrome 37.0.2062.124, Firefox 32.0.3, Safari 7.1, and Internet Explorer
> 11), do not expose implied rows to the accessibility layer:
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0092.html
> In order to have the browser expose the correct number of rows, it is
> necessary to add an empty <tr> element for each of the implied rows (thus
> making all rows explicit).
>
> Unfortunately, browsers start exhibiting performance issues with many rows:
> https://code.google.com/p/chromium/issues/detail?id=418360
>
> If aria-colindex and aria-rowindex attributes were available, then these
> performance issues could be avoided.
>
> Sincerely,
>
> Daniel Trebbien
>