Ticket #5403 (closed Bug: fixed)

Opened 4 years ago

Last modified 2 years ago

JAWS not reading the Selected List item as Selected

Reported by: satya Owned by:
Priority: Normal Milestone:
Component: Accessibility Version: 3.2
Keywords: IBM Cc: damo, joek

Description

To reproduce the defect

  1. Open Ajax Sample.
  1. Type some text and apply Heading 1 format to the text
  1. Keep the cursor on the same line and navigate back to the Paragraph Format drop down list in the Tool bar.
  1. Activate the Paragraph Format drop down list by pressing Space bar.
  1. Focus goes to the Heading 1 Option and JAWS reads that option 2 times but it is not reading it as Selected.

We are getting the same behaviour on all the List boxes(Font Name,Font Size,Styles)

This is happening only on FF 3.6.2

This looks similar to the defect http://dev.fckeditor.net/ticket/5366

Change History

comment:1 Changed 4 years ago by garry.yao

  • Keywords Confirmed added

It's a different issue than #5366 for me.
MSAA is properly reporting the list item as selected, FF since 3.6 announces Not Selected state while doesn't care of 'Selected' state, we need JAWS to give a clue here.

comment:2 Changed 4 years ago by garry.yao

  • Milestone changed from CKEditor 3.3 to CKEditor 3.4

comment:3 Changed 4 years ago by fredck

  • Status changed from confirmed to pending
  • Milestone CKEditor 3.4 deleted

We need some feedback from Freedom Scientific on this one.

comment:4 follow-up: ↓ 5 Changed 3 years ago by damo

  • Cc changed from damo,joek to damo, joek

When using a "single-select" listbox, the currently focused option in the listbox is the selected item. So, there is no need for the AT to read that the option is selected. It is possible to have "multi-select" listboxes, that would use the aria-selected attribute on options to indicate that the options are part of the whole selected group.

The listboxes in the editor drop-downs behave as "single-select" listboxes as far as I can tell, i.e. it is not possible to use Space to select more than one option at a time, since selecting the option actions it. In fact, the listboxes behave more like menus...

The drop-down lists could be implemented as menus with menuitems. For those drop-downs that can have multiple items pre-selected, e.g. the styles drop-down, we would use menuitemradio and aria-checked="true" for the pre-selected options. For drop-downs with a single pre-selected value e.g. font, we would use menuitemcheckbox with aria-checked="true". An example page with this implementation can be found here: http://www.oaa-accessibility.org/example/25/

See WAI-ARIA spec for details: http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menuitemcheckbox and http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#menuitemradio

An alternative might be to just use aria-checked="true" on the listbox options, since role="option" can support aria-checked.

Last edited 3 years ago by damo (previous) (diff)

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 3 years ago by fredck

Replying to damo:

When using a "single-select" listbox, the currently focused option in the listbox is the selected item. So, there is no need for the AT to read that the option is selected.

This means that we're ok with the Format, Font and Font Size combos. Those are, in fact, single-select lists. Even if the aria-select is used for them, it's ok for the AT to not read it.

---

It is possible to have "multi-select" listboxes, that would use the aria-selected attribute on options to indicate that the options are part of the whole selected group.

This case applies to the Styles combo.

The fact is that the editor is properly setting aria-multiselectable="true" to the styles list. It's also properly setting aria-selected="true" for active styles.

In this case, JAWS is not announcing the "selected" thing. Here, it seems that we have a JAWS issue and the right thing would be having FS giving their opinion to it.

---

Based on the above, I don't think we should change the way we handle it. Using aria-checked works around the problem, but it looks wrong, in a semantic point of view. This would be right just for a list of checkboxes or radio buttons.

I would wait for FS position before anything else.

comment:6 in reply to: ↑ 5 Changed 3 years ago by damo

The questions have been forwarded to FS.

Replying to fredck:

This means that we're ok with the Format, Font and Font Size combos. Those are, in fact, single-select lists. Even if the aria-select is used for them, it's ok for the AT to not read it.

Note, that this usage of single select lists where focus isn't changing the current selection is not a typical use case. See point 1. here: http://www.w3.org/TR/wai-aria/states_and_properties#aria-selected , especially the note that "The selection normally follows the focus, and is managed by the user agent".

---

The fact is that the editor is properly setting aria-multiselectable="true" to the styles list. It's also properly setting aria-selected="true" for active styles.

In this case, JAWS is not announcing the "selected" thing. Here, it seems that we have a JAWS issue and the right thing would be having FS giving their opinion to it.

There seems to be a problem with the usage of aria-activedescendant on the Styles combo. It never changes when moving up/down the list. This could be affecting the screenreader. If aria-activedescendant is used, it should be used to indicate the currently focused item in the list. See http://www.w3.org/TR/wai-aria/states_and_properties#aria-activedescendant for more details. In this current implementation, it doesn't seem like aria-activedescendant is actually required.

---

I would wait for FS position before anything else.

We're waiting on feedback from FS now.

comment:7 Changed 3 years ago by damo

This has been partially addressed in JAWS 12.0.1167.

It works for the styles combo but not the others. FS is still looking into this.

comment:8 Changed 3 years ago by j.swiderski

Reading the comments here and in #8001 it looks to me like those two are related.

comment:9 Changed 2 years ago by satya

Fixed in JAWS 13 & FF7.0

comment:10 Changed 2 years ago by j.swiderski

  • Status changed from pending to closed
  • Resolution set to fixed

Yes it's working fine in Firefox 7 and JAWS 13.

Note: See TracTickets for help on using tickets.
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy