Screen reader support for aria-owns

[Becky Gibson]

Hi,

What is the support for aria-owns in the screen readers?  It doesn't seem to work as I would expect.

I'm trying to implement a simple tab panel.  I can't get VoiceOver or JAWS 15 to announce the number of tabs properly.  I have added aria-owns to the element with role=tablist but it still doesn't work.  Here is the basic markup:

<ul role="tablist" aria-owns="settings button key-button">

<li><button role="tab" id="settings-button" aria-controls="settings-panel">Settings</button></li>

<li><button role="tab" id="key-button" aria-controls="key-panel">Keyboard Shortcuts</button></li>

</ul>

<div role="tabpanel" id="settings-panel" aria-expanded="true">

panel data - this is the initially visible panel

</div>

<div role="tabpanel" id="key-panel" aria-hidden="true" aria-expanded="false">

panel data

</div>

Running on Windows 7 in Chrome 36, JAWS just announces each item as "tabname, tab".   Running on Windows 7 in IE11 JAWS announces, "tabname tab". Running on OS X 10.9.4 in Safari 7.0.5, Voice Over announces each item as "tab name, tab".  Those 3 scenarios have basically the same behavior. 

However, running on OS X 10.9.4 in Chrome 36, VoiceOver announces each tab as, "tab name, tab 1 of 1".  On Windows 7 in Firefox 31, JAWS announces, "tabname 1 of 1".That misnumbering is the problem I am trying to work around. 

I tried putting the aria role and properties on the listitem. Then VoiceOver will announce "Settings 1 of 2" in Chrome but I don't get the action of the button to activate the tab. I'd rather not have to hand code that since the inner button should do the work.  I also tried putting role="presentation" on the listitems.  In theory this should also mark the child button as presentation (it doesn't) and it doesn't help make the tabs have the desired numbering. Any ideas appreciated. 

thanks,

-becky

[Marco Zehe]

Hi Becky,

nope, role "presentation" will only act on the element it is set on, never on the children. And yes, you definitely want that to be on there since you don't want the list item accessibles show up.

I don't think you need aria-owns for this at all, since the tabs are already the children of the tablist (or grandchildren, rather), aria-owns, if implemented, is supposed to alter the hierarchy of otherwise unrelated elements into a pseudo-hierarchy. So, I'd leave that attribute out completely.

Also, it might be a good idea to check your markup with Firefox and NVDA. For me, if that works, it means the markup is basically correct. Remember that JAWS does its own thing with interpreting HTML and other DOM stuff, doesn't strictly rely on accessibility info alone. That also means, one is slightly dependent on their interpretation of WAI-ARIA attributes. The safe haven is Firefox + NVDA, since they strictly get everything from IA2, and Firefox does the calculation of posinset and setsize for NVDA.

Also, there is an example of ARIA tabs on my blog from last year that might help. You can find it here.

Hope this helps!

Marco

--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to free-aria+...@googlegroups.com.
To post to this group, send email to free...@googlegroups.com.
Visit this group at http://groups.google.com/group/free-aria.
For more options, visit https://groups.google.com/d/optout.

[Steve Faulkner]

On 7 August 2014 16:22, Marco Zehe <marco...@gmail.com> wrote:

role "presentation" will only act on the element it is set on, never on the children.

except required children

--

Regards

SteveF

HTML 5.1

[Bryan Garaventa]

Please don’t forget to add proper scripting support to handle keyboard focus, otherwise it will not work consistently with the paradigm for a Tab control, which is to have one tab stop and then use the arrow keys to switch between each Tab.

 

E.G

http://www.w3.org/TR/wai-aria-practices/#tabpanel

A working demo also available at

http://whatsock.com/tsg/Coding%20Arena/ARIA%20and%20Non-ARIA%20Tabs/ARIA%20Tabs%20(Internal%20Content)/demo.htm

Marco’s article outlines all of the same concepts.

 

Regarding aria-owns, if you set focus to the container element with role=tablist instead of the buttons with role=tab, then aria-owns should technically provide the correct parent / child relationship in the Accessibility Tree. This also requires the use of aria-activedescendant also on the element with role=tablist to indicate which Tab is currently selected. Last I tested, aria-owns wasn’t working reliably for this type of construct across platforms however.

 

If setting focus to each button instead, then aria-owns has no impact, and aria-activedescendant should not be used. If it helps, these differences are more fully described at

https://www.ssbbartgroup.com/blog/2013/10/22/why-there-are-only-two-ways-to-make-aria-widgets-programmatically-focusable-for-screen-reader-users/

 

Regarding specific X of Y data, you can use aria-posinset and aria-setsize on the element with role=tab in order to force a specific numbering order, such as “1 of 3”, “2 of 3”, etc.

 

Last I checked, this doesn’t work using VoiceOver on iOS however, but it does work using JAWS and NVDA in IE and FF.

--