FilteringSelect and ComboBox: screen readers not annoucing "n of m" information

[ptbrunet]

Go to ​http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_FilteringSelect.html and tab down to a FilteringSelect widget. When the widget gets focus the screen reader should announce the n of m information, e.g. "2 of 50" if the value of the combo box is Alaska and the combo box has 50 possible values. The same behavior would be expected of a ComboBox.

If you have a screen reader you can see this behavior by going to the combo box in the Start, Run dialog.

The combo box in the Start, Run dialog conveys this information to the screen reader because of its MSAA hierarchical structure, i.e. the combo box has three children: the text box, the list, and the push button. When focus first lands on the text box of the combo box the screen reader senses that it's in a combo box because there is a parent with role combobox. It then can analyze the list (sibling of the text box) and know the size of the list from list's child count and which item is selected by iterating through the list items until it finds which list item has a state of selected.

In order for dojo to let the screen reader provide this valuable information to the screen reader the DOM will have to be structured such that a text object gets focus and it has a parent of wairole combobox and a sibling of wairole list (with children of wairole listitem).

Note: This ticket was originally about a blank item at the start of the list. That issue is now covered by #4923.

[bill]

IIRC the blank entry is so

1. when the form is initially displayed it shows a blank value for the state (because the user hasn't selected a state yet)...
2. if user picks a state but then decides he doesn't want to put in anything for that field, he can revert it to a blank value

How do native controls work w.r.t. that situation?

[haysmark]

A native select is extra special. When you arrow down the menu, the screen reader announces the option and then tells you where the option is in the list. For example, if Alabama is first in the list of 50 states it will say "Alabama, 1 of 50." If the first item is blank it says something like " 1 of 50."

I think it would be nice to have the ComboBox? telling the user what index the selection is at. Basically we need a waiRole that leverages that native select behavior, or else we need to add the wai.setAttr code back to ComboBox? so we can manually append the descriptive index to that wai value. That way the user knows that the blank option is there.

[ptbrunet]

When JAWS reads a native select you hear, "combo box read only Volvo 1 of 4". You can use ​http://www.w3schools.com/tags/tag_select.asp for an example. When JAWS reads a FilteringSelect you hear, "combo box Volvo".

To understand the behavior, you can use MSAA's inspect tool to look at the accessible hierarchy that FF creates. For a select, FF creates a combobox object with a child list object and several grandchild listitem objects. However, for our FilteringSelect there is only a combobox object object with no children. The current DOM structure is table - tbody - td - tr - input. That input has wairole of combobox. If the DOM could be structured so that the menu div that is currently at the bottom was placed below the input (the one with wairole combobox) and the menu div was given a wairole of listbox and each child div a wairole of listitem, then the select behavior might just be replicated in the FilteringSelect.

A related issue is the fact that words "read only" are missing. I'll add a separate comment for that in a bit once I do some more research.

[ptbrunet]

A select has an MSAA state of readonly while a FilteringSelect doesn't so adding a waistate of readonly on the combobox will probably result in hearing the missing "read only".

[ptbrunet]

Please ignore my last comment. FilteringSelect is not a readonly widget (like select) so it should not say "read only".

[haysmark]

I added the list and list item attributes and it's now reading the item from the menu. In particular, if you select More choices it will read the next item in the list on the callback. The callback announcement works great now.

But unfortunately if you are just arrowing through you get the double announcement bug again.

[haysmark]

Also how do I set the description of a node? In that Inspect tool it says there is no description so I figure I have to set that myself.

[ptbrunet]

Mark, Regarding your first comment (comment 6) I think that's due to fix 4311 (changeset 10675 on ComboBox.js). The double speak is pending a fix from JAWS. Regarding the next comment (comment 7) the description (n of m) would be set by the browser so the hope is/was that if FF2 (or FF3) recognizes a DOM structure that looks like a select, i.e. the list below the combobox, then it would add the description information.

[haysmark]

Fixes #4537. When you arrow over an item, ComboBox? speaks the position of the item in the list like a native select.

[haysmark]

Pete, Becky, here is an a11y patch for your consideration. It makes ComboBox? speak the position of the list elements like a native select. In particular, the blank value this ticket is about says "1 of 31" just like native select does.

[ptbrunet]

Mark, The dojo code shouldn't be forcing the n of m info as you do in lines 641, 655, 662. That's the browser's job. Dojo should create something that looks like a combo box and the browser should act correctly, i.e. focus should land on a text field and it should have a parent object of role combobox. This is what Aaron is now doing for the address bar in FF3.

The DOM structure currently is:

table - wairole:presentation
  tbody
    tr
      td
        input - wairole:combobox

I think the fix should be to give the td a wairole:combobox and the input a wairole:textfield. (Actually since it's already an input tag you might not need to do that.)

When the list is opened and the arrows are used, focus should move between list items. Contrary to what I said before, based on the FF3 address bar implementation, it appears that this list doesn't have to be a child of the combobox object. I think if the list items all have wairole:listitem and the list itself has wairole:list then the browser will do the right thing regarding the presentation of a11y info through the a11y api to the screen reader.

By the way, #4710 is related.

[haysmark]

Pete, I can't get your waiRole assignments to work. Check my waiRoles: I set the menu waiRole to list, the td to combobox, the input to textfield, and the menu items to listitem, and nothing special happens. I think the real problem is that I can't give the menu and menu items focus like you say because focus has to stay on the textbox so the user can edit it.

[haysmark]

What if we changed the valuenow code in our wai to convert "" to "blank" or "no value"? Wouldn't that be a lot easier to implement?

[ptbrunet]

Mark, Please attach your latest patch so I can look into why nothing changed as a result.

[ptbrunet]

Regarding what I said in comment 11, i.e. that the address bars in FF and IE don't have their lists as children of the combo box this should not be a reason to not try to fix this ticket. The address bars should be considered to be defective. Standard combo boxes like the one on the Start, Run dialog do have the associated list as a child of the combo box and the screen reader reads the n of m information. The n of m info is important to convey to the user when the combo box gets focus. BTW, The n of m info is not conveyed by a screen reader when moving through the list, therefore the problem description I originally provided was wrong. I updated it.

Mark, regarding your comment 13, the issue about a blank item is now ticket #4923 so please make that comment over there.

[Douglas Hays]

I think is mostly a screen reader work item.

[Becky Gibson]

This was fixed with changes made in [12985], [12555] and [12281] and now works in Firefox 3. I am closing since it would take a re-architect of the widget to get this working in FF2.