RE: Role=table plus aria-owns, expectations versus reality

Bryan
Did you mean to attach anything to this email?
I don't see a link to example code or an attachment to your email.
Maybe your general description of the situation is the best that we can get.
But it sounded like you meant to either attach something or provide a link
to a working (or not so much working due to poor a.t. support) set of
examples.
Thanks
you 

-----Original Message-----
From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Friday, May 13, 2016 1:44 PM
To: ARIA Working Group <public-aria@w3.org>
Subject: Role=table plus aria-owns, expectations versus reality

Hi,
Since James N is working on the aria-owns detail, I wished to pass these two
tests along with the results.

I'm working on this for a client who needs a simulated data table to be
accessible, where the main table is separate from the sticky column header
that floats outside of the construct. Unfortunately a common use for
something like this.

So, according to what is expected, the first example denoted by "1" uses
aria-owns in combination with aria-owns to provide the correct order in the
accessibility tree.

This does work for reordering the accessibility tree in Firefox and Chrome,
though Chrome does not support role=table so it breaks the data table
construct.

JAWS17 appears to be ignoring the accessibility tree in this case, and
places the external role=rowgroup container at the end of the table instead
of at the beginning in accordance with what aria-owns is supposed to be
doing. This only occurs in IE11, and doesn't reflect the accessibility tree
at all in Firefox nor does it rearrange anything virtually.

In NVDA, nothing is reflected properly in IE11, Firefox, or Chrome.

Now, the second example uses an aria-owns hack, which is technically valid
though not something most people would expect to try.

As expected it does not rearrange the accessibility tree in IE11, but does
do so in Firefox and Chrome.

Using JAWS17, this works accessibily in IE11 and in Firefox, but not in
Chrome. For some reason there is a ghost representation of the floating
container outside of the table, which appears to be another JAWS bug.

NVDA doesn't support anything like this in IE11, Firefox, or Chrome.

So currently the only thing I can recommend to the client is the second one,
and not the first, simply to get something to work properly at present, even
though this goes against all expectations according to the spec.

Hopefully this research info will be helpful for others here.

All the best,
Bryan



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com

Received on Friday, 13 May 2016 23:19:46 UTC