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

Files: 
CommentFileSizeAuthor
#14 drupal-search_module_for_label-356359-14.patch741 bytesAgileware
PASSED: [[SimpleTest]]: [MySQL] 190 pass(es).
[ View ]
#11 drupal-search_module_for_label-356359-11-d6.patch741 bytesAgileware
#3 search.module_for_label2.patch875 bytesmgifford
Passed: 10585 passes, 0 fails, 0 exceptions
[ View ]

Comments

Title:Search Form has Accessibility Issues According to WAVESearch Form has Accessibility Issues According to WAVE & FAE

The 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:

<label>Enter your keywords: </label>
<div class="container-inline"><div class="form-item" id="edit-keys-wrapper">
<input type="text" maxlength="255" name="keys" id="edit-keys" size="40" value="" class="form-text" />

And probably just needs to be changed to:

<div class="container-inline"><div class="form-item" id="edit-keys-wrapper">
<label>Enter your keywords: </label>
<input type="text" maxlength="255" name="keys" id="edit-keys" size="40" value="" class="form-text" />

These were just pulled from my example which I included in the first link.

Hi 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":

<label for="edit-keys">Enter your keywords: </label>
<div class="container-inline"><div class="form-item" id="edit-keys-wrapper">
<input type="text" maxlength="255" name="keys" id="edit-keys" size="40" value="" class="form-text" />

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

Version:6.8» 7.x-dev
Status:Active» Needs review
StatusFileSize
new875 bytes
Passed: 10585 passes, 0 fails, 0 exceptions
[ View ]

Right.. 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

Issue tags:-Quick fix, -accessibility

Ignore this comment. I commented on the wrong patch. John

I think it needs a t() around it for i18n:

<?php
t
('Enter your keywords:');
?>

This 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.

Issue tags:+Quick fix, +accessibility

Status:Needs review» Reviewed & tested by the community
Issue tags:+Quick fix, +accessibility

This 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

Simple problem. Simple fix. Works for me. No more hook form alters to fix this one.

Status:Reviewed & tested by the community» Fixed

Excellent work!

Committed to HEAD. :)

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Version:7.x-dev» 6.x-dev
Status:Closed (fixed)» Needs review
StatusFileSize
new741 bytes

Any chance of getting this committed to D6 so we can have our accessibility there too?

Here is the patch.

Issue tags:+needs backport to D6

tagging

- 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?

StatusFileSize
new741 bytes
PASSED: [[SimpleTest]]: [MySQL] 190 pass(es).
[ View ]

Sorry, 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'

Version:6.x-dev» 6.22
Status:Needs review» Reviewed & tested by the community

I applied it to the latest release and tested that it resolves the accessibility problem originally identified. Thanks Agileware!

Version:6.22» 6.x-dev

Status:Reviewed & tested by the community» Fixed

Thanks, committed to Drupal 6.

Status:Fixed» Closed (fixed)
Issue tags:-needs backport to D6, -Quick fix, -accessibility

Automatically closed -- issue fixed for 2 weeks with no activity.