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
