Orphaned form labels

Can someone do patch for this?
We need form labels on username and search box. The WAVE toolbar in FF can show you exactly what you need to know.

**Moving this to the Drupalorg customizations project, as part of closing down the Redesign project.

I think I can fix this but I don't know where to look. Can you provide guidance on where this code can be found? Will I need a local clone of this d.o 6.x-3.x dev site in order to forensically find the code with the devel module?

The offending <label> code on this page - http://drupal.org/profile, is within a block, and I've downloaded and grepped this git repository - http://drupal.org/project/drupalorg/git-instructions, for anything related to "profile, username, form, label, block, search, community, *.tpl.php files, etc", and poked at all the files and directories for the past hour, but I cannot find this <label> form code anywhere.

There are a few other Novice issues I would like to tackle, but I need a little guidance on where to start... maybe I should have participated in a contrib module issue queue rather than the d.o redesign project to start with? I'm comfortable with git, patching, etc... I just can't find the dang code for this issue, so I feel like I'm getting started on the wrong foot :/ Can anyone kindly point me in the right direction?

Thank you,
--Tony

Thanks drupleg for trying to take a crack at this. However, I'm also confused. ;) http://drupal.org/profile now has a "Username:" form label on the user search box, and I don't see anything about a "Mailing list" form label anywhere in the page source at all. Seems like this issue should just be marked fixed with no additional work, but perhaps I misunderstand the original bug report.

Hi, thanks for the quick feedback, it's encouraging to know there are helpful eyes watching these issues.

As I understood the issue as reported - the error is within the <label> code itself. While the "Username:" text is there for sighted users, the <label> is not helpful for screen readers. Attached are screenshots taken with the WAVE Accessibility toolbar report showing the errors. The current code is:

<div class="form-item">
 <label>Username: </label>

Accessibility guidelines recommend this label should be coded with something such as <label for="username search">Username: </label>. There are a few issues like this around the queue that I think I can fix if I can just locate the code. Thank you for your guidance.

After reviewing further the Accessibility guidelines - the code is supposed to be for="input-id-name". So the appropriate label for this would be <label for="edit-keys">, however this is still rather unhelpful to someone with a screenreader as "edit-keys" and "edit-submit" don't really mean anything to a blind person using the site :/

 <label>Username: </label>
 <div class="container-inline"><div id="edit-keys-wrapper" class="form-item">
 <input type="text" class="form-text" value="" size="40" id="edit-keys" name="keys" maxlength="255">
</div>
<input type="submit" class="form-submit" value="Search" id="edit-submit" name="op">

@drupleg

Just to clarify lable @for attribute. The @for attribute creates a programmatic link between the label text and the input field to which the @for refers. When there is a label specified for an input field in this way browsers will expose the text of the label element as the accessibleName property of the input control in the accessibility tree exposed to assistive technology.

So, you are correct, the @for of the label should have the same value as the @id of the input field.

Tracking.

Well, that's definitely more information -- thanks! :) Setting this back to active.

However, I don't know why this one particular form label wouldn't have the right @for property set. Presumably, that's something handled directly by Drupal's Form API, and I have no idea why it wouldn't be working here.

Seems like this isn't really a novice issue at all, but requires someone with a pretty solid understanding of the Form API and willingness to navigate the complicated web of code that powers drupal.org (spread across a lot of different projects) to figure out what's going on here.

I've learned how to start contributing by reading the info here - http://drupal.org/make-drupalorg-awesome and submitted my request for access here - http://drupal.org/node/1293832

Thanks!

I agree it's no longer a Novice issue. If it was just some html it would be, but as I kept digging I just couldn't find the end to see where this was coming from, such as the form API as you mention. I'll peek at a few more issues to see if I can still start helping somewhere.

If I were looking I would look at:

theme_form_element() (and any overrides), and at the form array in which the element is generated.

There's another similar issue - http://drupal.org/node/958700 which also appears to stem from whatever the fix will be for this issue, can these issues be combined?

And two more <label> issues, all seem to be the same problem. All of these relate to form labels.

http://drupal.org/node/958694 - QA: Mailing Lists[Accessibility]

http://drupal.org/node/958704 - QA: Search Page[Accessibility]

@drupleg: Great work consolidating these issues, thanks!

FYI: when referring to another issue, if you just type #958700: QA: Module Issue Search Box[Accessibility] you get this nice automated thing that includes the number, title, color-coded by current status, etc:

#958700: QA: Module Issue Search Box[Accessibility]

Adding description of related issue that was marked as a duplicate. Also verifying that this is still an issue in D7.

I can't find the Profile link under either https://drupal.org/support or https://drupal.org/community

So that seems to be a null point unless we can get a new URL.

There is a user search here:
https://drupal.org/search/user/search

But there are no label problems with that.

The mailing list however seems to be a book content type:
https://drupal.org/mailing-lists

I'm not sure how it was constructed, but essentially that list of checkboxes needs to be in a fieldset. There is no single ID for: <label for="edit-item">Mailing lists </label> to point to.

For more information, see #504962: Provide a compound form element with accessible labels

We have migrated all of our mailing lists except security-announcements to MailChimp. This bug report is no longer applicable.