Hey, here's some commenting inline.
On Wed, Feb 22, 2017 at 1:13 AM, James Teh <[email protected]> wrote: > Hi guys, > > Sorry for the delay in responding. I needed to find time to sit down and > digest all of this. :) > > > 1. Alex, your (thorough) outline of how this should work looks correct > to me and is what I intended. Thanks. > 2. Moving to the first cell in the table is easily achieved by > navigating the tree. > 3. Moving to the last cell in the table isn't so easy if there is a > cell in an earlier row with a row span. > - For example, consider a 2 x 2 table where r1c2 spans both r1 and > r2. Technically, the last cell in the table is actually r2c2, which is > the > same as r1c2. That accessible will only appear in the row for r1. > Therefore, navigating to the last accessible in the tree will give you > r2c1. > - You can't even just ask for cellAt(nRows, nCols) because nRows > and nCols might be greater than the last row/column index. For example, > there might be 2 x 2 cells, but aria-rowcount and aria-colcount might be > set to 3 (if you can have gaps in the middle of a table, why not at the > end?). > 4. We have similar problems when navigating to the first cell in a > row. If a cell in a previous row had a row span, first child on the row is > not sufficient. > 5. Navigating to the first cell in a given column is complicated as > has already been described, but it's even worse if you take col span into > account. > 6. I think I like the idea of having magic values for cellAt. -1 means > first, -2 means last. These should account for row/col span. You can then > do: > - First cell in table: (-1, -1) > - Last cell in table: (-2, -2) > - First cell in row r: (r, -1) > > If a row is spanned, then would this return a cell from previous row, that the spanning started from, or it returns a first available cell in the row or returns null? > > - Last cell in row r: (r, -2) > - First cell in column c: (-1, c) > - Last row in column c: (-2, c) > 1. Regarding a table with lots of holes, I agree this is confusing > enough that the benefits of table navigation start to be lost. The user > would probably end up just navigating linearly. In IA2 terms, they would > follow the tree/text interface. > > Would it be nice to have an iterator interface on a table/cell instead of providing a low level methods? The iterator can keep the navigational context, and figure out what the next/prev/up/down/first/last cells are. > > 1. It's worth noting that while we do now have relationTargetsOfType, > there's actually a benefit to fetching all relations at once. Screen > readers in particular tend to need all (or most) of the available > information for an object to report it well. If we know we're eventually > going to need all relations, we may as well fetch them all ahead of time, > particularly if we're doing so cross-process. > > It's unfortunate for a server's performance, and probably a client's performance as well, because as long as you cached something, then you have to keep it updated. > > 1. Alex, I'm confused about your comment concerning relations not > being strings. They *are* strings at present. Sure, they're constants in > the IDL, but we don't require everyone to build new binaries just to use a > new relation; they can define the constant themselves, even if temporarily. > > Thanks, I should read the IDL before making the statements :) I was confused with we have the predefined constants. > > I think I got everything! :) > > > Thanks! > > Jamie > >
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
