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

Richard Schwerdtfeger schwer at us.ibm.com
Mon Jan 4 21:53:38 UTC 2016


Although it is possible to have 2 cells I don't think this even close to
the norm. Why would we we not just have the screen reader ask to go to a
row and column 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. We can add a parameter that states to navigate to
the first non-empty cell to the ... or whatever algorithm we choose.

Rich


Rich Schwerdtfeger



From:	Dominic Mazzoni <dmazzoni at google.com>
To:	Richard Schwerdtfeger/Austin/IBM at IBMUS, James Teh
            <jamie at nvaccess.org>
Cc:	IAccessible2 mailing list
            <accessibility-ia2 at lists.linux-foundation.org>,
            accessibility-ia2-bounces at lists.linuxfoundation.org
Date:	01/04/2016 10:47 AM
Subject:	Re: [Accessibility-ia2] aria-colcount and aria-rowcount
            mapping, again



Rich, I think the problem is, what if the table consists of just two cells,
(1, 1) and (999, 999) - the screen reader wants to go to the

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.

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, then try column x in that row, and if
that fails, navigate to the first cell in that row.

Anyway, I would be fine with also extending IAccessibleTableCell.


On Mon, Jan 4, 2016 at 6:51 AM Richard Schwerdtfeger <schwer at us.ibm.com>
wrote:
  Would it not be better to just navigate to a given row and column index?
  Why limit it to just the cell in a direction?


  Rich Schwerdtfeger

  James Teh ---01/03/2016 10:55:11 PM---On 29/12/2015 5:52 AM, Dominic
  Mazzoni via Accessibility-ia2 wrote: > Totally agreed that screen rea

  From: James Teh <jamie at nvaccess.org>
  To: Dominic Mazzoni <dmazzoni at google.com>, IAccessible2 mailing list <
  accessibility-ia2 at lists.linux-foundation.org>
  Date: 01/03/2016 10:55 PM
  Subject: Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping,
  again
  Sent by: accessibility-ia2-bounces at lists.linuxfoundation.org





  On 29/12/2015 5:52 AM, Dominic Mazzoni via Accessibility-ia2 wrote:
  > Totally agreed that screen readers need to be able to navigate from
  > cell to cell and fetch rows at a time. Note that the spec requires the
  > numbering to be sequential, so you don't need to worry about that.
  When I said sequential, I also meant contiguous; i.e. 1, 2, 3, not 1, 2,
  5.
  >
  > I'd like to point out that in vanilla HTML it's quite common for
  > tables to have missing cells already.
  Missing cells only towards the end of rows, never in the middle or at
  the start. So, you might not be able to move to the next cell at the end
  of an incomplete row, but that's okay because you've already seen all of
  the cells on that row. Conversely, if there are cells missing at the
  start or in the middle of a row, it may be impossible to get to other
  cells in the row.

  > Screen readers shouldn't have to do any extra work to deal with most
  > such tables because they already need to be able to handle missing
  > cells, so this wouldn't be any different.
  >
  See above. Start/middle gaps are a problem and I can't even think of a
  good way to handle this. This is why I am probably more for this
  solution:

  > The alternative proposal seems to be to export the ARIA attributes
  > and/or use group position and have the screen reader announce the ARIA
  > row and column indexes but otherwise explore the table from the DOM.

  > * Screen readers wouldn't be able to jump to a cell by row, column
  > index. (JAWS has a keystroke for this now.)
  Hmm. That certainly is a problem, yes.

  I guess another solution could be to extend IAccessibleTableCell to
  provide a way to get to the next cell in a given direction. I *think*
  that would solve the start/middle gap problem.

  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



  _______________________________________________
  Accessibility-ia2 mailing list
  Accessibility-ia2 at lists.linuxfoundation.org


  https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2


  [attachment "graycol.gif" deleted by Richard Schwerdtfeger/Austin/IBM]
  [attachment "graycol.gif" deleted by Richard Schwerdtfeger/Austin/IBM]




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/accessibility-ia2/attachments/20160104/56046ec2/attachment.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/20160104/56046ec2/attachment.gif>


More information about the Accessibility-ia2 mailing list