#15298 closed defect (fixed)
FilteringSelect: Accessibility Issue
Reported by: | KGith | Owned by: | Douglas Hays |
---|---|---|---|
Priority: | undecided | Milestone: | 1.8 |
Component: | Accessibility | Version: | 1.6.1 |
Keywords: | Cc: | mikeb | |
Blocked By: | Blocking: |
Description
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>.
Attachments (4)
Change History (10)
Changed 9 years ago by
Attachment: | FormsMode.png added |
---|
Changed 9 years ago by
Attachment: | FilteringWidget_Inspection.png added |
---|
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
Cc: | mikeb added |
---|---|
Component: | DojoX Widgets → Dijit - Form |
Owner: | changed from dante to Douglas Hays |
Summary: | Dojo.Form.FilteringSelect Accessibility Issue → FilteringSelect: Accessibility Issue |
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.
comment:3 Changed 9 years ago by
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."
comment:4 Changed 9 years ago by
Component: | Dijit - Form → Accessibility |
---|---|
Milestone: | tbd → 1.8 |
Resolution: | → fixed |
Status: | new → closed |
Probably fixed by [28238].
Changed 7 years ago by
Attachment: | filteringSelectClientSel.jpg added |
---|
FilteringSelect? widget inspection (clientSel example)
comment:5 Changed 7 years ago by
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.
Changed 7 years ago by
Attachment: | filteringSelectClientSel2.jpg added |
---|
FilteringSelect? (clientSel) form view
comment:6 Changed 7 years ago by
*<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.
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.