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 <dmazz...@google.com> 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 <ja...@nvaccess.org> 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 Accessibility-ia2@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
