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)
- Last cell in row r: (r, -2)
- First cell in column c: (-1, c)
- Last row in column c: (-2, c)
7. 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.
8. 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.
9. 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.
I think I got everything! :)
Thanks!
Jamie
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
