[Accessibility-ia2] aria-colcount and aria-rowcount mapping, again

[James Teh]

On 29/12/2015 5:52 AM, Dominic Mazzoni via Accessibility-ia2 wrote:
> Totally agreed that screen readers need to be able to navigate from 
> cell to cell and fetch rows at a time. Note that the spec requires the 
> numbering to be sequential, so you don't need to worry about that.
When I said sequential, I also meant contiguous; i.e. 1, 2, 3, not 1, 2, 5.
>
> I'd like to point out that in vanilla HTML it's quite common for 
> tables to have missing cells already.
Missing cells only towards the end of rows, never in the middle or at 
the start. So, you might not be able to move to the next cell at the end 
of an incomplete row, but that's okay because you've already seen all of 
the cells on that row. Conversely, if there are cells missing at the 
start or in the middle of a row, it may be impossible to get to other 
cells in the row.

> Screen readers shouldn't have to do any extra work to deal with most 
> such tables because they already need to be able to handle missing 
> cells, so this wouldn't be any different.
>
See above. Start/middle gaps are a problem and I can't even think of a 
good way to handle this. This is why I am probably more for this solution:

> The alternative proposal seems to be to export the ARIA attributes 
> and/or use group position and have the screen reader announce the ARIA 
> row and column indexes but otherwise explore the table from the DOM.

> * Screen readers wouldn't be able to jump to a cell by row, column 
> index. (JAWS has a keystroke for this now.)
Hmm. That certainly is a problem, yes.

I guess another solution could be to extend IAccessibleTableCell to 
provide a way to get to the next cell in a given direction. I *think* 
that would solve the start/middle gap problem.

Jamie

-- 
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: jamie at nvaccess.org