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

I agree that this is valid. I think the reason that this has not come up before is that, in practice, you can normally achieve row ownership through judicious use of role=presentation and the grid roles without having to resort to aria-owns. 

We have used aria-owns on rows to point to the owned gridcells and this works quite well in FF. 


> On Mar 31, 2015, at 6:17 PM, Alexander Surkov <surkov.alexander@gmail.com> wrote:
> 
> 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
>