Core form descriptions shouldn't use a label when not associated with a form

good to know it doesn't bug screen readers. WebAIM's WAVE didn't like it and ya it should be fixed.

Thanks @sun - friggin trailing colon. Sorry. The title should be clearer too I hope.

Good suggestion. That's much more straight forward.

S#!t, like where are all of these spaces coming from anyways.. cut & paste errors suck..

Thanks sun.

@Everett, via twitter @webaxe said "Besides poor code, orphaned labels may mislead user; expected functionality broken such as clicking to activate a form field", although he followed up by saying "It ain't a show stopper."

So would be good to fix it, but not critical.

Ok, I visually reviewed this patch in another editor. Not sure how that space was missed using vi......

For accessibility headings help to break of the navigation of a site & allow screen readers to have an alternate way to skip through the content looking for chunks of relevant text.

Generally navigation is done either by reading out the text of the site chronologically or either skipping through the links or through the headings. Although DIVs won't break the hierarchical document structure they don't add anything either.

It's better to use a DIV than a LABEL in this instance, as a LABEL is just bad HTML, however headings provide a structure that can be navigated. I think that these two 456 Berea Street articles Heading & Document Structure & Headings & Heading Hierarchy sum it up pretty nicely.

* Use headings for anything that looks or “feels” like a heading.
* Use headings to identify what WCAG 2.0 calls “sections of content”, i.e. headings in the main content area, different navigational sections, etc.

There isn't right now a nice way to deal with this. Hopefully this will change with HTML5.

If it was just this patch it would be quick. However there are a few places where I know this has been done. Not sure how to best find them though.

There's is a great deal of disagreement about how to use heading tags in HTML4. This doesn't need to wait till HTML5 or for that matter adoption of WAI-ARIA.

I'll see if I can get some second opinions about this.

Ok, I'm going to concede on the on heading issue and run with the div after discussing this this with @BrandonOJC.

We're going to also need to re-roll to be either a .label or a div.label:

.form-label {
  display: block;
  font-weight: bold;
}

from http://drupal.org/node/884846#comment-3347986

Hope this helps move this issue forward.

EDIT: Ultimately I suppose it comes down to what users expect. Headings within forms isn't standard even if a group of form elements is essentially the same as a paragraph or two.

@sun can we get this RTBC'd so that we can then build against it when modifying #884846: Orphaned Labels Being Generated for Radios, Checkboxes & Items to use:

<div class="label"></div>

Ok, I've re-rolled that patch & submitted it.

#19: filter_label_use_v6.patch queued for re-testing.

Hey Brandon, It's in this patch here http://drupal.org/node/884846#comment-3499784

But yes, I don't think we can get rid of the .form-item label as we want the labels to be defined to look the same. The patch I rolled didn't include a change to the system.css

mike@dev:/home/dm7$ grep -ir form-item modules/system/* | grep label
modules/system/system.admin.css:.exposed-filters .form-item label {
modules/system/system.admin-rtl.css:.exposed-filters .form-item label {

This is the relevant code:

.exposed-filters .form-item label {
  float: left; /* LTR */
  font-weight: normal;
  width: 10em;
}

It looks like div.label should be applied there too.

#19: filter_label_use_v6.patch queued for re-testing.

Ok, so how do we get these in for consideration in D8. They are pretty trivial accessibility enhancements.

This isn't an accessibility issue as such, but it does cause confusion as it isn't actually a label.

Would be a lost opportunity too to remove this as we're going through & verifying HTML5 coding standards.

A grep for '' in D8 just produced:

core/modules/field/field.form.inc:        'data' => '<label>' . t('!title: !required', array('!title' => $element['#title'], '!required' => $required)) . "</label>",
core/modules/field/modules/text/text.js:          $fullLabel = $('<label></label>').prependTo($full);
core/modules/locale/locale.admin.inc:    $title = '<label>' . $form[$type]['#title'] . '</label>';

The instance has since been removed from:
/core/modules/filter/filter.module

Good point.. Hopefully this moves it ahead a bit.

Oh ya, I also hit up the following files.

filter/filter.module field/field.module locale/locale.admin.inc system/system.admin.css

Needs before/after screenshot and UX review.

I had forgotten why we had removed <h3> until stumbling down to comment #15.

Any suggestions on dealing with the DIV? Should we just make it larger in the CSS?

#40: filter_label_use_v8-882666-40.patch queued for re-testing.

@Bojhan, in the screenshots in #41 div.label looks less bold than the <label> tag. I can't see why that is, but think that's why it needed a usability review.

What was the markup bug? Would like to get this marked RTBC.

@droplet see @sun's comment here - http://drupal.org/node/882666#comment-3402358

It's worth also noting that this doesn't fix the same problem with radios & checkboxes.

This is just on the page creating new users.

Edit: I don't think #884846: Orphaned Labels Being Generated for Radios, Checkboxes & Items has a solution that we can work with easily to get rid of these headings.

#51: filter_label_use_v8-882666-51b.patch queued for re-testing.

This is a simple fix.

@droplet it might be more semantic to change this to a heading, but essentially this issue was opened because it was just a markup bug for an inappropriate use of a label element.

I'm fine with someone else verifying that indeed it is appropriate for it to be a heading & making it so, but I'd really like that to either be another issue or to to have someone else champion it.

This addresses the original concern I raised in 2010 and I'm marking it RTBC as it's really a trivial markup change that shouldn't take 2 years to solve.

I'm going to drop this down to needs work until I understand how your other patch is going to interact here.

In your patch does it become just a heading or is it a label that is styled to look like a heading?

Here's a screenshot from FF in Ubuntu.

Thanks @sun.

That's great, thanks!