[Accessibility-ia2] aria-colcount and aria-rowcount mapping, again
Richard Schwerdtfeger
schwer at us.ibm.com
Sat Jan 2 00:00:01 UTC 2016
Yes, IBM has a commercially available accessibility test tool up on
BlueMix. Also, Deque has one.
There are 2 problems:
1. Internet Explorer and ATs. All the ATs go through the regular DOM and
for the most part ignore the accessibility apis. This is largely because
Microsoft did an incomplete accessibility api mapping. This is not an issue
with Firefox or Chrome. However, because of IE the whole industry is
impacted because all US Federal agencies are IE shops.
2. Accessibility test tools, today, test WCAG compliance to the DOM. The
reason they do this is because of IE and because we don't have a consistent
API mechanism. IOW, something may be exposed in one browser via the
accessibility API but not in another. See HTML5accessibility.com as an
example. These test tools are what product teams use to test accessibility
compliance WCAG.
We agree this situation needs to change. Microsoft is not longer supporting
IE accessibility (no further investment) and their Edge focus will be on
APIs. In this scenario we will be in a better position. We also agree that
for AT support we must focus on APIs.
We need to push for an alignment in accessibility API post ARIA 1.1. This
is also when we must expand ARIA to support Web components.
The last I looked we did not have enough JavaScript API available to walk
into the shadow DOM. What additional APIs do we have at disposal and do all
browsers support them? To my knowledge, commercial accessibility test tools
are not using them. I am more than willing to look into using the new APIs
for our tool and share that information with other commercial tools.
Rich
Rich Schwerdtfeger
From: Dominic Mazzoni <dmazzoni at google.com>
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
Date: 12/31/2015 04:27 PM
Subject: Re: [Accessibility-ia2] aria-colcount and aria-rowcount
mapping, again
On Thu, Dec 31, 2015 at 2:19 PM Richard Schwerdtfeger <schwer at us.ibm.com>
wrote:
What I mean by the DOM going away is accessibility test tools, today,
don't get access to the Web Components DOM. It is hidden. This is a gap.
Have you had an experience with a specific testing tool?
If any testing tool uses a native accessibility API only, like
MSAA/IAccessible2, then it will see the full "composed" DOM including the
shadow DOM of all web components because that's what browsers expose. For
example, if you open a webpage containing web components in Chrome and
examine it using accProbe, you'll see the contents of all components just
as if they were part of the DOM.
In addition, any testing tool that's written in JavaScript and runs inside
the webpage has full access to the shadow DOM of web components too. It's
true that they need to use some newer APIs to dive inside of a component
and some of them haven't been updated yet, but the APIs have been there
since the beginning, so it's just a question of tools catching up with the
times, not gaps in the spec or available APIs.
So, regarding API mappings you want to have the ATs control the browser
(move focus and have the browser load more content)?
Two separate things. For API mappings I just mean that we need to define
how browsers are to implement things like aria-colcount and aria-rowcount
using APIs like IAccessible2 and UIA. Nothing special there but it's not
clear how we should do it.
The second issue is that in order to implement things like spreadsheets,
yes we do want a way for AT to be able to request that the browser load
more content that isn't currently available. I think that's an important
requirement, but I don't think it will be easy and I agree that ARIA 2.0
would be a good timeframe to talk about that.
- Dominic
Rich Schwerdtfeger
graycol.gifDominic Mazzoni ---12/31/2015 04:07:54 PM---On Thu, Dec 31,
2015 at 1:51 PM Richard Schwerdtfeger <schwer at us.ibm.com> wrote:
From: Dominic Mazzoni <dmazzoni at google.com>
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
Date: 12/31/2015 04:07 PM
Subject: Re: [Accessibility-ia2] aria-colcount and aria-rowcount mapping,
again
On Thu, Dec 31, 2015 at 1:51 PM Richard Schwerdtfeger <schwer at us.ibm.com>
wrote:
Hi Dominic,
We can look at adding this work as part of ARIA 2.0 and the common
accessibility api work for browsers.
I don't think anything I'm asking for is a change in the ARIA spec. I'm
basically okay with what's in ARIA 1.1 now. However, we need to nail this
down as part of the User Agent Implementation Guide for ARIA 1.1.
The need for this goes beyond screen readers. Alternative input
solutions will need this too.
Sure, of course.
Also, the traditional DOM is going away with web components if that
takes off necessitating more work like this.
What makes you say the DOM is going away? Web components are just an
extension of the DOM by letting authors define their own elements, but
there's still a pretty well-defined "composed" DOM tree. Assistive
technology shouldn't know or care about whether there are web components
or not. I think some work is needed to address some gaps right now (for
example the IDREF issue that makes some ARIA attributes not work well
with web components) but there are workarounds.
- Dominic
Rich
Rich Schwerdtfeger
graycol.gifDominic Mazzoni via Accessibility-ia2 ---12/30/2015
07:00:47 PM---Hi, This is a follow-up to a mail thread from June on
the correct mapping of
From: Dominic Mazzoni via Accessibility-ia2 <
accessibility-ia2 at lists.linuxfoundation.org>
To: IAccessible2 mailing list <
accessibility-ia2 at lists.linux-foundation.org>
Date: 12/30/2015 07:00 PM
Subject: [Accessibility-ia2] aria-colcount and aria-rowcount
mapping, again
Sent by: accessibility-ia2-bounces at lists.linuxfoundation.org
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
Accessibility-ia2 at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/accessibility-ia2/attachments/20160101/b74b8015/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/20160101/b74b8015/attachment.gif>
More information about the Accessibility-ia2
mailing list