[Accessibility-ia2] aria-colcount and aria-rowcount mapping, again

James Teh jamie at nvaccess.org
Wed Jan 6 01:58:12 UTC 2016


Precisely what you're trying to say we need to do: allow for navigation 
other than row + 1 and col + 1. If we have a table which has a cell at 
r1c2 but no cell at r2c2 and the user navigates down by row from r1c2, 
how does an AT find the next appropriate cell? There are two choices 
right now:
1. Keep trying IAccessibleTable2::cellAt with increasing row numbers 
until we find a cell. But what if the next cell is at r1000c2 (which is 
entirely possible with these new ARIA properties)? That'd mean calling 
cellAt 999 times.
2. Use accNavigate to walk through the rows, query the first column in 
each row to get its row number, then use cellAt to get the cell n that 
row in the original column. This does allow us to skip rows which have 
no data at all. However, it's still horrible because:
* There might be interspersed thead/tbody/rowgroup elements, requiring 
hierarchical tree traversal.
* There are still a huge number of calls.

Aside from the complexity and performance horror, it's also difficult 
for implementers to grasp. They look at IA2 and see a table interface, 
but then have to understand that actually, the table interface isn't 
enough to navigate tables by row and column; they might actually have to 
do some insane tree walking to get anything useful.

Things get even worse if you believe an AT should do something other 
than skipping rows if there is no cell in the same column on the next 
non-empty row. Dominic suggests we should just go to the first column. I 
think that is a bad user experience and breaks a user's spatial feel of 
the table. So if we want to move to the next "nearest" cell, now we 
can't even use cellAt any more. We have to walk the children of every 
subsequent row looking for "nearby" coordinates.

Jamie

On 6/01/2016 11:39 AM, Richard Schwerdtfeger wrote:
>
> What are the use cases?
>
>
> Rich Schwerdtfeger
>
> Inactive hide details for James Teh ---01/05/2016 07:15:27 PM---My 
> point is that we don't currently have a way of handling thisJames Teh 
> ---01/05/2016 07:15:27 PM---My point is that we don't currently have a 
> way of handling this decently  with IA2 and that we need
>
> From: James Teh <jamie at nvaccess.org>
> To: Richard Schwerdtfeger/Austin/IBM at IBMUS
> Cc: IAccessible2 mailing list 
> <accessibility-ia2 at lists.linux-foundation.org>, 
> accessibility-ia2-bounces at lists.linuxfoundation.org, Dominic Mazzoni 
> <dmazzoni at google.com>
> Date: 01/05/2016 07:15 PM
> Subject: Re: [Accessibility-ia2] aria-colcount and aria-rowcount 
> mapping, again
>
> ------------------------------------------------------------------------
>
>
>
> My point is that we don't currently have a way of handling this 
> decently with IA2 and that we need new API calls. Saying "just faf 
> around with accNavigate and try all sorts of different stuff until you 
> find what you want" isn't good enough IMO, not least because it's 
> horribly unperformant cross-proc. If we're going to have gaps at the 
> start/in the middle of rows, we need some sort of table navigation 
> function that can handle different types of navigation. Currently, 
> there is no such function.
>
> Jamie
>
> On 6/01/2016 11:00 AM, Richard Schwerdtfeger wrote:
>
>
>     Jamie,
>
>     I have to agree with Dominic that you have a lot of different what
>     ifs for determining where to go when a cell is empty. I think you
>     need to be able to pass a parameter that asks the browser to go
>     where you want based on a set of criteria.
>
>     For example, So, what if several rows are skipped? When does the
>     situation become problematic?
>
>     What condition do you want to be met?
>
>     e.g. a parameter that tells us what to do if an empty cell is
>     encountered:
>
>     GOTO_FIRST_NONEMPTY_ADJACENT_CELL
>
>     What I am getting at is what is the algorithm you want the user
>     agent to follow when an empty cell is encountered. Does it Vary
>     based on a parameter. Do you want hidden cells to be ignored?
>
>
>     Rich
>
>
>     Rich Schwerdtfeger
>
>     Inactive hide details for James Teh ---01/05/2016 04:50:38 PM---On
>     5/01/2016 7:53 AM, Richard Schwerdtfeger wrote: >James Teh
>     ---01/05/2016 04:50:38 PM---On 5/01/2016 7:53 AM, Richard
>     Schwerdtfeger wrote: >
>
>     From: James Teh _<jamie at nvaccess.org>_ <mailto:jamie at nvaccess.org>
>     To: Richard Schwerdtfeger/Austin/IBM at IBMUS, Dominic Mazzoni
>     _<dmazzoni at google.com>_ <mailto:dmazzoni at google.com>
>     Cc: IAccessible2 mailing list
>     _<accessibility-ia2 at lists.linux-foundation.org>_
>     <mailto:accessibility-ia2 at lists.linux-foundation.org>,
>     _accessibility-ia2-bounces at lists.linuxfoundation.org_
>     <mailto:accessibility-ia2-bounces at lists.linuxfoundation.org>
>     Date: 01/05/2016 04:50 PM
>     Subject: Re: [Accessibility-ia2] aria-colcount and aria-rowcount
>     mapping, again
>     ------------------------------------------------------------------------
>
>
>
>     On 5/01/2016 7:53 AM, Richard Schwerdtfeger wrote:
>
>         Although it is possible to have 2 cells I don't think this
>         even close to the norm.
>     Two cells was just an extreme example to demonstrate the issue.
>     The point is that gaps at the start or middle of a row are
>     problematic.
>
>         Why would we we not just have the screen reader ask to go to a
>         row and column number?
>     Because if there is a gap, incrementing row or column by one isn't
>     sufficient. It could be 1, 2 or an arbitrary number.
>
>         It is not difficult to ask the user agent to navigate to
>         compute the effective cell to the right and ask for the user
>         agent to navigate there.
>     It's probably always true that navigating to the adjacent cell in
>     the next column is as simple as accNavigate with NAVDIR_NEXT.
>     However, navigating to the adjacent cell in the next row is not so
>     simple. What if several rows are skipped?
>
>         We can add a parameter that states to navigate to the first
>         non-empty cell to the ... or whatever algorithm we choose.
>     Add a parameter to what? I think this would require a new
>     function, which is what I was suggesting.
>
>     Dominic wrote:
>         Jamie, as an alternative, couldn't the screen reader try
>         navigating to the next / previous cell using the row, column
>         index, but if that fails, fall back on DOM navigation?
>
>         For example, given a current cell (x, y), if the user wants to
>         go right - to the next cell in the same row, try (x + 1, y)
>         but if that's empty, use the accessibility tree to navigate to
>         the next sibling. 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.
>         Similarly, given (x, y) if the user wants to go down - to the
>         same column in the next row, try (x, y + 1), but if that's
>         empty, use the accessibility tree to navigate to the next row, 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.
>         then try column x in that row, and if that fails, navigate to
>         the first cell in that row. We never want to fall back to the first column like that. If a
>     user moves down a row, they expect to move down a row, not down
>     and across (excepting column spans).
>
>     Jamie
>
>     -- 
>     James Teh
>     Executive Director, NV Access Limited
>     Ph +61 7 3149 3306_
>     __www.nvaccess.org_ <http://www.nvaccess.org/>
>     Facebook: _http://www.facebook.com/NVAccess_
>     Twitter: @NVAccess
>     SIP: _jamie at nvaccess.org_ <mailto:jamie at nvaccess.org>
>
>
> -- 
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306
> _www.nvaccess.org_ <http://www.nvaccess.org/>
> Facebook: _http://www.facebook.com/NVAccess_
> Twitter: @NVAccess
> SIP: _jamie at nvaccess.org_ <mailto:jamie at nvaccess.org>
>
>

-- 
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: jamie at nvaccess.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/accessibility-ia2/attachments/20160106/60620cbf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/accessibility-ia2/attachments/20160106/60620cbf/attachment.gif>


More information about the Accessibility-ia2 mailing list