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

Yes, there were initially two sample .htm files attached, but perhaps that got stripped. Attached are two .txt files instead. Please let me know if this comes through.

Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
415.624.2709 (o)

-----Original Message-----
From: Birkir Gunnarsson [] 
Sent: Friday, May 13, 2016 4:19 PM
To: Bryan Garaventa <>; 'ARIA Working Group' <>
Subject: RE: Role=table plus aria-owns, expectations versus reality

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.

-----Original Message-----
From: Bryan Garaventa []
Sent: Friday, May 13, 2016 1:44 PM
To: ARIA Working Group <>
Subject: Role=table plus aria-owns, expectations versus reality

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 Garaventa
Accessibility Fellow
SSB BART Group, Inc.
415.624.2709 (o)

Received on Friday, 13 May 2016 23:23:57 UTC