Hi Dominic,

We can look at adding this work as part of ARIA 2.0 and the common
accessibility api work for browsers. The need for this goes beyond screen
readers. Alternative input solutions will need this too.

I am trying to wrap ARIA 1.1 up on time so that we can do all the
long-needed essential cross-platform API-related work like this moving.

Also, the traditional DOM is going away with web components if that takes
off necessitating more work like this.

Rich


Rich Schwerdtfeger



From:   Dominic Mazzoni via Accessibility-ia2
            <[email protected]>
To:     IAccessible2 mailing list
            <[email protected]>
Date:   12/30/2015 07:00 PM
Subject:        [Accessibility-ia2] aria-colcount and aria-rowcount mapping,
            again
Sent by:        [email protected]



Hi,

This is a follow-up to a mail thread from June on the correct mapping of
aria-rowcount, aria-colcount, aria-rowindex, aria-colindex, etc. to
IAccessible2.

The primary intended use case is when all of the rows and columns can't be
loaded, for performance reasons.

The current spec does not solve the problem that screen readers need a way
to request that the page load more rows / columns. I agree this is
important and I'd be happy to discuss this in a separate thread, but I
think it's out of the scope of what can be done in ARIA and I don't see any
reason why we shouldn't move forwards with the current proposal in the
meantime.

Jamie wrote:
  In order to do table navigation, screen readers need to be able to
  navigate
  from a given cell to the cell in the next column or the next row, as
  well as being able to fetch all cells in a given row or column. If the
  numbering is not sequential, we can't simply increase indexes to do
  this. No API I know of supports something like this.

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.

I'd like to point out that in vanilla HTML it's quite common for tables to
have missing cells already. Here's a trivial example:

<table>
  <tr>
    <td>1, 1</td>
  </tr>
  <tr>
    <td>1, 2</td>f
    <td>2, 2</td>
  </tr>
</table>

In this table, there's no cell 2, 1 even though there are 2 columns and 2
rows. When a screen reader calls IAccessibleTable2::cellAt(2, 2) it returns
null.

Therefore my proposal is to do the same thing with a table that uses ARIA
to change its row and column indexes. The browser would do the work of
interpreting the ARIA and would present a virtual table via IAccessible2,
with some cells missing. 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.

The obvious interpretation of aria-rowindex=-1 would be for the browser to
return an error from IAccessibleTable2::nRows. We'll have to figure out
what to do if that breaks existing screen readers.

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. A couple of
downsides of this are:

* Users wouldn't get any support at all if they use an older screen reader
* Screen readers wouldn't be able to jump to a cell by row, column index.
(JAWS has a keystroke for this now.)

- Dominic
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Reply via email to