On 5/01/2016 7:53 AM, Richard Schwerdtfeger wrote:
Although it is possible to have 2 cells I don't think this even close
to the norm.
Two cells was just an extreme example to demonstrate the issue. The
point is that gaps at the start or middle of a row are problematic.
Why would we we not just have the screen reader ask to go to a row and
column number?
Because if there is a gap, incrementing row or column by one isn't
sufficient. It could be 1, 2 or an arbitrary number.
It is not difficult to ask the user agent to navigate to compute the
effective cell to the right and ask for the user agent to navigate there.
It's probably always true that navigating to the adjacent cell in the
next column is as simple as accNavigate with NAVDIR_NEXT. However,
navigating to the adjacent cell in the next row is not so simple. What
if several rows are skipped?
We can add a parameter that states to navigate to the first non-empty
cell to the ... or whatever algorithm we choose.
Add a parameter to what? I think this would require a new function,
which is what I was suggesting.
Dominic wrote:
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.
I suppose we could do that, but it's pretty inelegant. Oh look, we have
a table interface... but uh, sometimes it's not very useful, so you
might need to use tree navigation. It's not so bad for columns i guess,
but see below for rows.
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,
Navigating to the next row has two problems:
1. It's not a simple navigation, since there might be
thead/tbody/rowgroup elements to think about. Sure, it's just a
depth-first traversal, but now we're starting to get fairly complicated
for what should be a simple operation.
2. What if the next row doesn't include that column, but there is a row
3 rows beyond that that does? Surely we should move to the row with the
matching column. That's not possible with your algorithm.
then try column x in that row, and if that fails, navigate to the
first cell in that row.
We never want to fall back to the first column like that. If a user
moves down a row, they expect to move down a row, not down and across
(excepting column spans).
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: ja...@nvaccess.org
_______________________________________________
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
