#4537 closed defect (fixed)
FilteringSelect and ComboBox: screen readers not annoucing "n of m" information
Reported by: | ptbrunet | Owned by: | Becky Gibson |
---|---|---|---|
Priority: | high | Milestone: | 1.2 |
Component: | Dijit - Form | Version: | 0.9 |
Keywords: | Cc: | [email protected]…, [email protected]… | |
Blocked By: | Blocking: |
Description (last modified by )
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.
Attachments (1)
Change History (24)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
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.
comment:3 Changed 13 years ago by
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.
comment:4 Changed 13 years ago by
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".
comment:5 Changed 13 years ago by
Please ignore my last comment. FilteringSelect is not a readonly widget (like select) so it should not say "read only".
comment:6 Changed 13 years ago by
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.
comment:7 Changed 13 years ago by
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.
comment:8 Changed 13 years ago by
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.
comment:9 Changed 13 years ago by
Summary: | Filtering Select: when list appears there is an empty value at the start of the list → FilteringSelect: when list appears there is an empty value at the start of the list |
---|
Changed 13 years ago by
Attachment: | 4537.patch added |
---|
comment:10 Changed 13 years ago by
Cc: | [email protected]… added |
---|
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.
comment:11 Changed 13 years ago by
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.
comment:12 Changed 13 years ago by
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.
comment:13 Changed 13 years ago by
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?
comment:14 Changed 13 years ago by
Mark, Please attach your latest patch so I can look into why nothing changed as a result.
comment:15 Changed 13 years ago by
Milestone: | 1.0 → 1.1 |
---|
comment:16 Changed 13 years ago by
Description: | modified (diff) |
---|---|
Summary: | FilteringSelect: when list appears there is an empty value at the start of the list → FilteringSelect: screen readers not annoucing "n of m" information for the list |
comment:17 Changed 13 years ago by
Description: | modified (diff) |
---|---|
Summary: | FilteringSelect: screen readers not annoucing "n of m" information for the list → FilteringSelect and ComboBox: screen readers not annoucing "n of m" information for the list |
comment:18 Changed 13 years ago by
Description: | modified (diff) |
---|---|
Summary: | FilteringSelect and ComboBox: screen readers not annoucing "n of m" information for the list → FilteringSelect and ComboBox: screen readers not annoucing "n of m" information |
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.
comment:19 Changed 13 years ago by
Owner: | changed from haysmark to becka11y |
---|
I think is mostly a screen reader work item.
comment:20 Changed 13 years ago by
Owner: | changed from becka11y to Becky Gibson |
---|
comment:21 Changed 13 years ago by
Milestone: | 1.1 → 1.2 |
---|
comment:22 Changed 13 years ago by
Description: | modified (diff) |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:23 Changed 10 years ago by
Component: | Dijit → Dijit - Form |
---|
IIRC the blank entry is so
How do native controls work w.r.t. that situation?