Rich, I think the problem is, what if the table consists of just two cells, (1, 1) and (999, 999) - the screen reader wants to go to the
Jamie, as an alternative, couldn't the screen reader try navigating to the next / previous cell using the row, column index, but if that fails, fall back on DOM navigation? For example, given a current cell (x, y), if the user wants to go right - to the next cell in the same row, try (x + 1, y) but if that's empty, use the accessibility tree to navigate to the next sibling. Similarly, given (x, y) if the user wants to go down - to the same column in the next row, try (x, y + 1), but if that's empty, use the accessibility tree to navigate to the next row, then try column x in that row, and if that fails, navigate to the first cell in that row. Anyway, I would be fine with also extending IAccessibleTableCell. On Mon, Jan 4, 2016 at 6:51 AM Richard Schwerdtfeger <[email protected]> wrote: > Would it not be better to just navigate to a given row and column index? > Why limit it to just the cell in a direction? > > > Rich Schwerdtfeger > > [image: Inactive hide details for James Teh ---01/03/2016 10:55:11 PM---On > 29/12/2015 5:52 AM, Dominic Mazzoni via Accessibility-ia2 wr]James Teh > ---01/03/2016 10:55:11 PM---On 29/12/2015 5:52 AM, Dominic Mazzoni via > Accessibility-ia2 wrote: > Totally agreed that screen rea > > From: James Teh <[email protected]> > To: Dominic Mazzoni <[email protected]>, IAccessible2 mailing list < > [email protected]> > Date: 01/03/2016 10:55 PM > Subject: Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping, > again > Sent by: [email protected] > ------------------------------ > > > > 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: [email protected] > > > _______________________________________________ > Accessibility-ia2 mailing list > [email protected] > > https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2 > > > >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
