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

Richard Schwerdtfeger schwer at us.ibm.com
Wed Jan 6 01:39:22 UTC 2016


What are the use cases?


Rich Schwerdtfeger



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>
      To: Richard Schwerdtfeger/Austin/IBM at IBMUS, Dominic Mazzoni
      <dmazzoni at google.com>
      Cc: IAccessible2 mailing list
      <accessibility-ia2 at lists.linux-foundation.org>,
      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
      Facebook: http://www.facebook.com/NVAccess
      Twitter: @NVAccess
      SIP: 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/20160105/42ef17cd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/accessibility-ia2/attachments/20160105/42ef17cd/attachment-0001.gif>


More information about the Accessibility-ia2 mailing list