We definitely should reach out our AT vendor contacts, pointing to the summary of the thread, but in general I'd say it's reasonable to expect that all IA2 consumers/implementers follow the list.
On Wed, Feb 22, 2017 at 2:39 AM, Dominic Mazzoni <[email protected]> wrote: > Great summary. I think the next step is to bring this to other AT vendors > and see if this will work for everyone. > > On Tue, Feb 21, 2017 at 10:13 PM 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) >> - 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
