FilteringSelect: Accessibility Issue

[KGith]

I have been working on making a website accessible. I have been using the JAWS software, which is a screen reader (​http://www.freedomscientific.com/products/fs/jaws-product-page.asp)

When I go into Form Mode (insert + f5 while using JAWS). All widgets I am using except the FilteringSelect? work just fine. However, the FilteringSelect? appears as "unlabelled<x> Edit Combo" where x is a counter. I have tried adding several attributes (i.e. aria-label, aria-labelledby, name, title) and using a <label> for the <select>.

[KGith]

I attached two files to give more context. FormsMode? is what is displayed in JAWs Form Mode, and FilteringWidget_Inspection is what the FilterSelect? looks like in Firefox using Firebug's inspection feature.

[bill]

Mike, do you reproduce this?

(Presumably the reporter is talking about dijit.form.FilteringSelect since there is no dojo or dojox FilteringSelect.)

Kgith - it's always best to attach a test case. Since you didn't, we'll just test on our standard test page and if FilteringSelect works there then we'll close this ticket.

[mikeb]

I was able to reproduce the "unlabelled" message, but only on 1.6 and 1.7. It happens when there is not a <label> associated with the FilteringSelect? - I fixed it by adding the <label> tag. It can be applied to <input> or <select> elements too. Kgith, maybe you forgot to add the "for" attribute or are giving it a non-unique id? You can see in the source of the test page how <label> is used: ​http://archive.dojotoolkit.org/nightly/checkout/dijit/tests/form/_autoComplete.html?testWidget=dijit.form.FilteringSelectl

What is odd is that this problem does not occur in the nightly builds, even though the test page is the same. When an associated <label> can't be found, it seems Jaws uses the leading text as the "label" (it doesn't create a dom node or anything.) You can see an example of the same unlabeled FilteringSelect? being parsed two different ways on the test page:
1.7 - "unlabelled<X> edit combo"
nightly - "Created programmatically with an initial query. (Limits list to items with type = country.) edit"

I think this is new expected behavior...? FilteringSelect? works as before, even "better", since we are now more forgiving. Even if developers forget the <label> and Jaws uses the last paragraph instead, hearing the paragraph read out every time is still probably more accessible than hearing "unlabeled edit combo."

[Douglas Hays]

Probably fixed by [28238].

[[email protected]…]

FilteringSelect? widget inspection (clientSel example)

[[email protected]…]

Hello,

I'm doing some accessibility changes in a portal that I'm working with and I'm facing this issue. I'm not sure but I think this issue is not fixed, I'm using the 1.9 release. I added the "for" attribute to link the label with the FilteringSelect? component:

dojo.create("label", {"for": "clientSel" , innerHTML: "*<front:frontendTag key="clientName" />: "}, td84);

var clientOptionsStoreData = {

identifier: 'value', label: 'desc', items : clientList,

};

clientNameOption = new dijit.form.FilteringSelect?({

id: "clientSel",

store: clientOptionsifr, searchAttr: 'desc', name: 'clients1', required: 'true', style: 'width: 430px;', value: data[0].chsportal.request_main.clientId@value, onChange: function() { . . .

The "for" attribute is linking the label to the "textbox" component inside the FilteringSelect? component and not the Filitering component.. So when I inspect the fields component in the form by using JAWS (ins + F5 key combination) I'm getting the unlabeled1 edit combo..

Please see the images I attached regarding this example.

[[email protected]…]

FilteringSelect? (clientSel) form view

[bill]

*<front:frontendTag key="clientName" />: " is not valid HTML. I also don't know what you mean by "the Filitering component". If you can attach a simple test case that fails we could investigate.