When you configure a form label to be hidden via the webform component UI, the label tag is hidden. However, no "title" attribute exists on the form field itself making it difficult for users using screen readers to determine what the field is actually for.

The WCAG 2.0 guidelines at http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/H65.html recommends the use of the "title" attribute to label form controls when the visual design cannot accommodate the label.

Attached patch fixes this issue for Drupal 6.

I'll provide a patch for Drupal 7 version later today hopefully.

Comments

Version:6.x-3.x-dev» 7.x-3.x-dev
StatusFileSize
new1.51 KB

Here's a D7 version too. This one can one step further and still print the label tag but with the new D7 "element-invisible" class.

Status:Needs review» Needs work

Thanks stella, I haven't had time to look at this patch so it got buried in the Webform queue. The D6 patch looks pretty good.

In the D7 patch, this doesn't seem to make any sense, why would you run check_plain() on a property that doesn't exist? Even if the logic is inverted, what's this providing?

+  if (empty($component['extra']['attributes']['title'])) {
+    $component['extra']['attributes']['title'] = check_plain($component['name']);
+  }

It'd probably be better to move this bit of code up above the setting of the $element variable.

+  // If #title_display is none, set it to invisible instead - none only used if
+  // we have no title at all to use.
+  if ($element['#title_display'] == 'none') {
+    $variables['element']['#title_display'] = 'invisible';
+    $element['#title_display'] = 'invisible';
+  }

In the D7 patch, this doesn't seem to make any sense, why would you run check_plain() on a property that doesn't exist? Even if the logic is inverted, what's this providing?
+  if (empty($component['extra']['attributes']['title'])) {
+    $component['extra']['attributes']['title'] = check_plain($component['name']);
+  }

Now I'm confused. Does $component['name'] not exist here?

The code is essentially the same as the D6 version, which says if there is no value set for $component['extra']['attributes']['title'], then use the sanitized $component['name'].

Maybe I'm missing something here, but I don't see how it differs from the D6 patch you approved.

Oh, for some reason I thought the code was this, just setting the property to itself:

+ if (empty($component['extra']['attributes']['title'])) {
+ $component['extra']['attributes']['title'] = check_plain($component['extra']['attributes']['title']);
+ }

I'm just being crazy apparently. I'll take another look at this.

Status:Needs work» Needs review

Hi Nate, did you have a chance to review this again? Fixing status.

Issue tags:+accessibility

The title attribute is certainly a good way to do this. In D7 you can also just add '#title_display' => 'invisible', when defining the form element and it will be hidden to the display, but also accessible to screen readers. It doesn't use the title attribute, but it still meets WCAG 2.0 AA guidelines.

Version:7.x-3.x-dev» 7.x-4.x-dev
StatusFileSize
new1.4 KB

Reroll.

Status:Needs review» Reviewed & tested by the community
StatusFileSize
new207.79 KB

That works well. I spun up an instance with SimplyTest.me and grabbed this screenshot:
Screen Shot of patch #7 with the label hidden.

Thanks for pushing this ahead Liam.

Title:webform field label accessibilityUse invisible instead of non-existent field labels for accessibility

Status:Reviewed & tested by the community» Closed (fixed)

Thanks Liam and stella, this is committed to the 7.x-4.x branch.

Thanks!

This patch introduced a Notice error when creating components: #2020705: Notice: Undefined index: name in webform_component_defaults().

Version:7.x-4.x-dev» 7.x-3.x-dev
Status:Closed (fixed)» Needs review
StatusFileSize
new1.71 KB

Re-rolling for people still using 7.x-3.x (the patches above no longer apply).

Are backports to 7.x-3.x still being considered?

Sure @andrewmacpherson, I think this would be valid for backporting. Thanks for the reroll. I'm not updating the 7.x-3.x as frequently as the 7.x-4.x branch, but I'll make sure this gets in next time I'm reviewing patches.

Did this get in 7.x-4.0-beta1?

Yes.

Issue summary:View changes
Status:Needs review» Needs work

The 4.x patch was causing PHP notices apparently. This patch was revised in #2020705: Notice: Undefined index: name in webform_component_defaults() to work in a more graceful manner. The 3.x backport no longer applies and should use the same approach used in that fix. Really I'd prefer to just say, "use 4.x", but if this patch is rerolled for 3.x it'll get in eventually.