ARIA 1.1: implementation for aria-col-* and aria-row-*.

ARIA 1.1: implementation for aria-col-* and aria-row-*.

This patch adds implementation for aria-col-index, aria-col-count, aria-
col-span, aria-row-index, aria-row-count, aria-row-span from ARIA 1.1,
https://rawgit.com/w3c/aria/master/aria/aria.html.

As aria-col-span and aria-row-span are from html attributes without
modification, they are not added as ax attr.

For windows, aria-col-count, aria-col-index, aria-row-count, aria-row-
index, aria-col-span and aria-row-span are exposed as object attribute
as FF reference.

There is related patches from WebKit, the patch written by Nan Wang<
n_wang@apple.com>; wkrev.com/190833. This CL takes some part of it
but doesn't take ariaRowSpanWithRowIndex() because it should not affect
other attributes which already exist.

BUG=543050

[je_julie(Not used), 2015-12-22 15:37:28]

je_julie.kim@samsung.com changed reviewers:
+ dmazzoni@chromium.org

[je_julie(Not used), 2015-12-22 15:37:28]

Hi Dominic,
This patch has implementation for aria-col-count, index, span and
aria-row-count, index, span.
I brought some of implementation from WebKit, wkrev.com/190833.
I didn't take ariaRowSpanWithRowIndex() part because it affects row index
attribute, as I understood aria-row-* and aria-col-* from ARIA 1.1 don't affect
attributes which already exist.

This patch includes some trivial modification.
1) Moved code for values of progressbar, scrollbar and slider out of
UpdateRequiredAttributes(), because the API is to handle html attributes but
these are not related to html attributes.
2) Includes time role in GetEquivalentAriaRoleString.

PTAL.

[dmazzoni, 2015-12-22 18:10:04]

Thanks for working on this!

I think you need to make changes to the AXARIAGrid classes too, right?

I had hoped that we could keep all of this computation inside Blink and not make
the Chromium code have to deal with the differences between ARIA row and column
properties and the native ones.

For example, instead of a table having a columnCount and an ariaColumnCount,
it'd just have a single columnCount that would be the correct value to expose.
Then the Chromium code outside of Blink wouldn't care whether the value came
from the table or from ARIA.

And I was assuming that the values returned from the IAccessibleTable2 API would
be affected too:

http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_...

Do you think it would be possible to do it this way?

I'm not sure how much existing screen readers have any support for these
attributes, but it seems much better if we could just support their existing
table APIs, rather than require them to support new attributes in order to
handle tables.

If that doesn't work, then we may have to reconsider, but I'd at least like to
understand that approach better.

https://codereview.chromium.org/1547643002/diff/20001/content/browser/accessi...
File content/browser/accessibility/browser_accessibility_win.cc (right):

https://codereview.chromium.org/1547643002/diff/20001/content/browser/accessi...
content/browser/accessibility/browser_accessibility_win.cc:1313: STDMETHODIMP
BrowserAccessibilityWin::get_nRows(long* row_count) {
I was assuming that get_nRows would return a different number when aria-rowcount
was set, and so on...

https://codereview.chromium.org/1547643002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/modules/accessibility/AXTable.h (right):

https://codereview.chromium.org/1547643002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/modules/accessibility/AXTable.h:68: int
ariaColumnCount();
How about if we just combine this into columnCount() and rowCount(), with a
comment saying that they might not match the number of columns and rows.

For example:

    // The column count and row count are virtual and can be
    // overridden by ARIA, so columnCount() may not be the
    // same as columns().size(), for example.
    int columnCount();
    int rowCount();

[je_julie(Not used), 2015-12-23 13:20:22]

On 2015/12/22 18:10:04, dmazzoni wrote:
> Thanks for working on this!
> 
I'm so sorry that it's been a long time since I told that I'll support it.
I'll keep working on it.

> I think you need to make changes to the AXARIAGrid classes too, right?
Because AXARIAGrid is inherited from AXTable and AXARIAGrid returns true for
isAriaTable() as well,
I thought the implementation was enough at AXTable. Do I modify that, too?

> 
> I had hoped that we could keep all of this computation inside Blink and not
make
> the Chromium code have to deal with the differences between ARIA row and
column
> properties and the native ones.
> 
> For example, instead of a table having a columnCount and an ariaColumnCount,
> it'd just have a single columnCount that would be the correct value to expose.
> Then the Chromium code outside of Blink wouldn't care whether the value came
> from the table or from ARIA.
> 
> And I was assuming that the values returned from the IAccessibleTable2 API
would
> be affected too:
> 
>
http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_...
> 
> Do you think it would be possible to do it this way?
> 
> I'm not sure how much existing screen readers have any support for these
> attributes, but it seems much better if we could just support their existing
> table APIs, rather than require them to support new attributes in order to
> handle tables.
Before I start to implement them, I read the mail,
"[Accessibility-ia2] aria-colcount and aria-rowcount mapping",
http://lists.linuxfoundation.org/pipermail/accessibility-ia2/2015-June/001900....

If we follow that mail thread, we can see some concern about how to expose them.

The comment below is from Jamie.
"If we kept table interface to reflect actual table structure, and put aria
row/colcount/index into object attributes, then would it work?
I'm not sure what the use case for this was, but regardless, this is
potentially going to require a pretty big change to table interfaces. 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."

The comment below is from Alexander.
"So, groupPosition on a row returns row
count and row index, groupPosition on a cell returns a col count and col
index. Right?"

I think people agree that we need them but don't decide how to expose them.
After I read that mail thread and check FF behavior,
I thought I can add these attributes with object attributes at least.

> 
> If that doesn't work, then we may have to reconsider, but I'd at least like to
> understand that approach better.
I've checked FF and Safari behaviors.
Firefox: They expose them as object attributes.
Safari: They expose aria-*-count and index as new NSAccessibility attributes.   
  

With that investigation, I made first patch for aria-col* and aria-row* support.
WDYT?