Yes, that's how I'd interpret it too. I like this because it essentially frees each AT from needing to reason about complex table structures. The browser takes care of understanding the virtual table structure and exposes it via a more straightforward API to the AT.
One question, though: How would the AT move to the first or last cell in the table, or the first cell in a row or column? I guess moving to the first cell in the table would be easy just by following the tree structure rather than using IAccessibleTable. Moving to the first or last cell in the current row or column seems a lot harder, though, because a virtual table might not start anywhere near a row or column index of 1. Perhaps we should add some convention, for example cellAt(n, 0) means the first column in row n, and cellAt(0, n) means the first row in column n. Any value larger than the largest row or column would move to the last row or column, so passing MAX_INT would work. Does that seem like a good idea? The other alternative would be to extend accNavigate with additional constants to move to the first or last cell in a row/column. On Wed, Feb 15, 2017 at 9:20 AM Alexander Surkov <[email protected]> wrote: > Hey, sorry about the delay. > > NAV_UP/DOWN/LEFT/RIGHT relations look reasonable on a cell object both > in context and out of context of aria-rowcol stuff. > > Please correct me if I'm wrong in assumptions: > * NAV_UP/DOWN/LEFT/RIGHT on each cell object that returns > up/down/left/right cell corresponding to a table structure, i.e. > up/down moves through a column and returns a closest cell of the same > column if any, left/right moves in a row; > * IAccessibleTable2::nColumsn/nRows return aria-col/rowcount on a table > element; > * IAccessilbeTableCell::columnIndex/rowIndex return aria-col/rowlindex > on a cell element; > * IAccessilbeTableCell::columnExtent/rowExtent return aria-col/rowspan > on a cell element; > * IAccessibleTable2::cellAt returns a cell at the given row or column > indices which correspond to > IAccessilbeTableCell::columnIndex/rowIndex. If there's a gap at the > given indices, then null with S_FALSE is returned. If indices are out > of range, then it fails; > * If aria-col/rowspan is missed, then value of 1 is assumed; > * If aria-col/rowindex is missed, then index is calculated as previous > known index + number of cells in between. > > Thanks. > Alex. > > On Fri, Feb 10, 2017 at 1:34 AM, James Teh <[email protected]> wrote: > > Let's get this discussion started again. :) > > > > I was thinking about this recently and it occurred to me that we may not > > need new API after all, just more implementation of existing (if rarely > > used) API. What do you think about implementing the NAVDIR_LEFT, > > NAVDIR_RIGHT, NAVDIR_UP and NAVDIR_DOWN directions for accNavigate on > table > > cells? This way, we could expose the aria-col/row* values via > > IAccessibleTable*, even for non-contiguous indexes without any of this > > object attribute ugliness. Even if there were a column with cells only at > > row 1 and row 100, a simple call to accNavigate with NAVDIR_DOWN would > take > > you straight from r1c1 to r100c1. > > > > Jamie > > > > On Wed, Jan 6, 2016 at 9:32 AM, Dominic Mazzoni <[email protected]> > wrote: > >> > >> I don't think it's true that tables can currently only have missing > cells > >> at the end of a row. There's nothing preventing an author from marking > any > >> cell as aria-hidden, which removes it from the accessibility tree, but > >> doesn't affect its row and column index. NVDA gets confused if you do > this. > >> I filed a new issue with an example: > >> > >> https://github.com/nvaccess/nvda/issues/5655 > >> > >> I think it'd make sense for screen readers to be as robust as possible > at > >> dealing with sparse tables using existing APIs. Then if we also want to > add > >> additional APIs to make this faster and easier, that's great too. > >> > >> On Tue, Jan 5, 2016 at 2:50 PM James Teh <[email protected]> wrote: > >>> > >>> 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. > >> > >> > >> As I said, I'm totally happy to implement extensions to the table > >> interface, I'm just pointing out that there are APIs available as a > fallback > >> in the meantime. > >> > >> It's up to you. Maybe as a compromise you could look at the aria-hidden > >> table above and make NVDA slightly more robust in the presence of > missing > >> cells, then when we extend IAccessibleTable2 you could make it handle > these > >> cases well. > >> > >>> 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. > >> > >> > >> I'm not sure that's the best behavior, because the user wouldn't realize > >> they skipped over rows containing content. Think about what happens > when you > >> move the cursor in a text editor: when you press the down arrow, it > tries to > >> move to the same column in the next line. However, if there's no text at > >> that column position in the next line, it moves the cursor to the > closest > >> character in that line. > >> > > >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
