Implementation bugs (present and anticipated) with aria-owns in tabular containers

Hey all.

Consider the following two examples:

Example 1:
  <div role="grid">
    <div id="childrow" role="row">
      <div role="gridcell">cell 1</div><div role="gridcell">cell 2</div>
    </div>
  </div>

Example 2:
  <div role="grid" aria-owns="siblingrow"></div>
  <div id="siblingrow" role="row">
    <div role="gridcell">cell 1</div><div role="gridcell">cell 2</div>
  </div>

If my Example 2 is author error, you can stop reading now. Though I'd
appreciate knowing what I got wrong so I can retry. Otherwise....

I examined each in the following environments:
* WebKit/Safari + Accessibility Inspector
* Firefox in Linux + Accerciser
* WebKitGtk/Epiphany + Accerciser

And the results I got were the same across the board, namely:

Example 1: The accessible table interface works as expected in reporting
the correct number of rows and columns and retrieving a specified cell.

Example 2: The accessible table interface does not work as expected,
with the reported number of rows being 0, and the reported number of
columns being 0. Not surprisingly, retrieving a specified cell from an
interface that doesn't think it has any cells fails.

My guess is that we probably have some broken grids already out there in
the wild. My prediction is that things are going to get worse with the
introduction of the new table roles *if* we allow authors to use
aria-owns and expect user agents to piece it all together.

Some of the issues can potentially be solved with the new table-related
properties we're adding for grid, treegrid, and the soon-to-be-created
table, namely:

* rowcount
* colcount
* rowindex
* colindex
* rowspan
* colspan

However, we determined that authors do not have to provide these if all
the cells are present in the DOM; if all the cells are present in the
DOM, the user agents are expected to calculate them. If my Example 2 is
indeed not authoring error, user agent calculation with aria-owns
appears broken for at least two engines and platforms [1] for a
dead-simple test case. If we let authors put bits of the table here, and
other bits there, but it's all in the DOM, is it reasonable for user
agents to have to piece it all together?

The other thing to consider is that the problem is not merely one of
reporting/exposing properties. Given a non-interactive table, screen
readers can (and do) provide table navigation commands whereby the user
can move straight to the next cell in any direction as well as to the
beginning and end of the table. This requires that the AT not only be
able to identify the coordinates of a given cell, but also to ask the
user agent for the cell at a given set of coordinates.

I'm not sure what the right thing to do is, but I think we need to
figure it out fairly soon. Ideas?

--joanie

[1] Regarding "at least two engines and platforms," see comment 7 of
http://community.nvda-project.org/ticket/3742

Received on Tuesday, 31 March 2015 23:48:53 UTC