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

I think your example is valid and grid should work as if the sibling row
was a child of the grid. The browser have two options to make it working:
fix table interface implementation for this case or change the accessible
tree to reflect aria-owns in the hierarchy. I find 2nd approach more
prominent to implement, we have a bug for Firefox [1].
Thanks.
Alex.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1133213

On Tue, Mar 31, 2015 at 7:48 PM, Joanmarie Diggs <jdiggs@igalia.com> wrote:

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