List: screen reader doesn't announce selected element / list node should be focusable #54

Closed
wkeese opened this Issue Mar 5, 2014 · 10 comments

Comments

Projects
None yet
4 participants
Owner

wkeese commented Mar 5, 2014

Try list_singleSelection_markAfter.html using JAWS 14. The screen reader never announces which item(s) are selected. Thus, blind users have no way of knowing which item(s) are selected.

Contrast with the HTML below, where the selected item is announced when the list is focused:

<div role="listbox" tabindex="0">
    <div role="option" tabindex="0">goat</div>
    <div role="option" aria-selected="true" tabindex="0">frog</div>
    <div role="option" tabindex="0">horse</div>
</div>

I don't know how to get JAWS to announce which item(s) are selected without focusing the List itself, but the current code is not usable (if you don't have vision).

sbrunot was assigned by wkeese Mar 5, 2014

Owner

cjolif commented Mar 5, 2014

We should target latest JAWS release that is 15. Is the result different with 15?

Owner

wkeese commented Mar 5, 2014

No, it doesn't work with JAWS 15 either. You might get confused by what JAWS announces, since (in English anyway) it uses the word "selected" to mean something like focused, but it doesn't announce which items are checked AFAICT.

Owner

cjolif commented Mar 6, 2014

FYI with the HTML you pasted I get selection announced when focusing on FF and IE but not Chrome (JAWS 15, W7).

Member

sbrunot commented Mar 6, 2014

I'm following the recommandation of accessibility experts by using the aria-selected attribute on list items to mark the selection state.

Everything seems fines regarding the WIA-ARIA spec in the samples/list/list_singleSelection_markAfter.html sample: list has the role grid, its aria-selectable attribute is set to true, and the single selected item, if any, has its aria-selected attribute set to "true" (all list items have the "row" role).

I'll check with usability experts to see what the problem is.

Owner

pruzand commented Mar 6, 2014

FYI with the HTML you pasted I get selection announced when focusing on FF and IE but not Chrome (JAWS 15, W7).

It seems (quite hard to understand) that Chrome announces the selected item when the list if focused by "frog 2 of 3", while FF says "frog selected, 2 of 3".

Member

sbrunot commented Mar 6, 2014

According to usability experts, this is a known bug in JAWS, described in the WebAIM mailing list:

JAWS does not properly announce the value of aria-selected when set to 'true' on selectable rows and cells when navigating in Applications Mode.

Owner

wkeese commented Mar 7, 2014

Even if JAWS and VoiceOver fixed their bugs, it's a bad user experience to have to navigate to every single list-item to find out which one is selected. If you have a page with many lists on it, you should be able to find out the selection on each list just by tabbing to it.

Compare with test_Select.html and notice that you don't have to scroll through the items in the drop down list to find out which one is selected.

So, the real problem is probably that you aren't focusing the List itself. Admittedly, KeyNav is not setup to do this... it wasn't an issue until you made this List widget that functions as a <select> or <select multiple=true>.

Member

sbrunot commented Mar 10, 2014

Usability experts reports that the selected status is correctly announced when using JAWS 15.0.7023 and Firefox 27.0.1.

Member

sbrunot commented Mar 10, 2014

I suppose that the tree widget will need the same kind of main node focus ? Should I expect an update of KeyNav that supports it, or should I try to find a way to implement it in List bypassing KeyNav default behaviour ?

Member

sbrunot commented Mar 12, 2014

The WIA-ARIA Best Practices guide state that the current initial focus behaviour is the expected one: http://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#aria_ex_widget

So I don't think we should update KeyNav / List so that the widget node receives the focus...

sbrunot closed this Mar 12, 2014

@wkeese wkeese added a commit to wkeese/deliteful that referenced this issue Mar 12, 2015

@wkeese wkeese more fixes about test/ directory reorg, fixes #54 5c2a222
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment