I think I miss why AT can't rely on accessible tree structure to fetch first or last cell in a row. If AT has a row, then NAVDIR_FIRSTCHILD/NAVDIR_LASTCHILD can be used on the row.
It may be tricky though to navigate through table with holes by means of UP/DOWN/LEFT/RIGHT relations. For example, say, we have a table 3x3 with cells at the diagonal only: ------------------------ | cell | hole | hole | | hole | cell | hole | | hole | hole | cell | ------------------------ If AT is at (3, 3) cell, then the closest cell with be a cell at (2,2). Neither of UP/DOWN/LEFT/RIGHT/FIRST/LASTCHILD/NEXT/PREVSIBLING relations seems helpful here. On Wed, Feb 15, 2017 at 12:35 PM, Dominic Mazzoni via Accessibility-ia2 < [email protected]> wrote: > 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 > >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
