I just tested this and confirmed that there is an accessibility issue with how the labels are presented, see:
http://drupal.org/node/210614#comment-1190365
There's a bigger issue with accessibility for radio buttons and check boxes, but I'm going to submit a patch for that shortly:
http://drupal.org/node/152098
Comment | File | Size | Author |
---|---|---|---|
#14 | drupal-search_module_for_label-356359-14.patch | 741 bytes | Agileware |
#11 | drupal-search_module_for_label-356359-11-d6.patch | 741 bytes | Agileware |
#3 | search.module_for_label2.patch | 875 bytes | mgifford |
Comments
Comment #1
mgiffordThe changes that were accepted to the checkboxes & radio buttons should help this, but thought it worth noting that http://fae.cita.uiuc.edu/ gives the search page a fail for the search page's accessibility:
Fail: 83% (out of 18 controls, 6 are associated with label elements via their id attributes, and 9 are nested within label elements).
I think many of these will be fixed when the patch I contributed gets backported for the radio buttons & check boxes, however the "WARNING: Orphaned Form Label" error from the default search page - /search in two places - isn't going to go away.
I think the label is separated from the input type in Drupal 6.8. It is presently:
And probably just needs to be changed to:
These were just pulled from my example which I included in the first link.
Comment #2
nfreear CreditAttribution: nfreear commentedHi Mike,
I'm quite certain that the first example from your January 26 comment would work with the addition of a "for" attribute in the label, explicitly relating to the input "id":
http://w3.org/TR/html401/interact/forms.html#h-17.9 - label, HTML 4.01 (XHTML 1.0/1.1).
Its important to remember the "id" attribute in the form control ("name" doesn't work) - the implicit-nested example at the link above doesn't work in MSIE 6 (or 7 maybe?) - it still requires an ID and FOR.
(Note, this helps mouse users without fine motor control, people who prefer a keyboard, and screen reader users.)
I hope this helps move this issue forward. Speak soon. Yours
Nick
Comment #3
mgiffordRight.. Not sure how I missed that.. Head must have been somewhere else.. But of course it's that it was missing the "for" attribute.
Thanks Nick. And yes, I do expect that this will help move this forward.
Mike
Comment #4
johnbarclay CreditAttribution: johnbarclay commentedIgnore this comment. I commented on the wrong patch. John
I think it needs a t() around it for i18n:
t('Enter your keywords:');
Comment #5
mgiffordThis patch is just associating the label with the form. No text is involved. It's just adding this text:
, '#id' => 'edit-keys'
So that there isn't an orphaned label on the search page.
Comment #6
mgiffordComment #7
bowersox CreditAttribution: bowersox commentedThis patch works great! With WAVE this resolved the error and now the /search page passes ('WAVE has detected no accessibility errors'). With FAE this resolved the failure and now the /search page has a 0% fail rate. The same applies to /search/user/ and /search/node/.
This is a very important patch for accessibility of D7. Without this patch, we would all need to continue making manual changes on every single drupal site to make it accessible.
P.S. This solution you have chosen using an ID is the best, IMHO. I'm glad we didn't re-order and nest the div and label tags because that could break themes and CSS. Let me know how else I can help to get this committed.
Brandon
Comment #8
johnbarclay CreditAttribution: johnbarclay commentedSimple problem. Simple fix. Works for me. No more hook form alters to fix this one.
Comment #9
webchickExcellent work!
Committed to HEAD. :)
Comment #11
Agileware CreditAttribution: Agileware commentedAny chance of getting this committed to D6 so we can have our accessibility there too?
Here is the patch.
Comment #12
mgiffordtagging
Comment #13
jhodgdon- When you upload a patch, please do not put a -D# suffix on the name (see help under the Attachments field).
- What change does this make in the markup of the search form? I see that it is pretty much the same patch as was committed for Drupal 7, and it looks like it might be harmless as far as being something that contributed and custom themes/modules would need to deal with... but does it accomplish the same markup revision for accessibility in Drupal 6 as it does in Drupal 7?
Comment #14
Agileware CreditAttribution: Agileware commentedSorry, here is one that should trigger the tester.
In my testing, before applying the patch the "Enter your keywords" label had no for attribute and after the testing it has a for attribute of 'edit-keys'
Comment #15
mgiffordI applied it to the latest release and tested that it resolves the accessibility problem originally identified. Thanks Agileware!
Comment #16
Damien Tournoud CreditAttribution: Damien Tournoud commentedComment #17
Gábor HojtsyThanks, committed to Drupal 6.