When #form_element_skip_title is set 'true', some input fields end up not having a title associated with them. This is because the #title property for the field is set to null. This can cause problems for some assistive technology users, where a properly associated label, or title attribute, communicates the purpose of the input field.
For example, theme_checkbox checks the #title property to see if it is null, if the #title property is null no title is associated with the input field.
Recommendations
1. (Recommended) Replace #form_element_skip_title with #form_element_title_position, and allow it to have one of the properties ('left', 'right', 'attribute'). 'left' will tell the theming engine to display titles to the left of the input field, 'right' will tell the theming engine to display titles to the right of the input field, and 'attribute' will tell the theming engine to set the title as the title attribute of the input field. By default the title will be displayed to the right of the input field.
2. Remove the functionality that checks #form_element_skip_title and sets #title to null, then correct any theming functions which check the #title property !isnull() and have them check #form_element_skip_title, and if #form_element_skip_title is 'true' set the title as the title attribute of the input field.
Resources
theme_checkbox() - http://api.drupal.org/api/function/theme_checkbox/7
A function that does not output a input field title if the #title property is set to null.
H44: Using label elements to associate text labels with form controls | Techniques for WCAG 2.0 - http://www.w3.org/TR/WCAG-TECHS/H44.html
Explaining how the proper use of labels and / or title attributes make input fields accessible to users of assistive technology.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | issue-522772.patch | 3.1 KB | Everett Zufelt |
Comments
Comment #1
Everett Zufelt commentedComment #2
Everett Zufelt commentedThis issue blocks #501444: Administer > Modules pages make improper use of form labels
Comment #3
Everett Zufelt commentedThe following output is from grep run from the root of Drupal 7 head
$ grep -irn '#form_element_skip_title' *
includes/form.inc:2649: if (!empty($element['#title']) && empty($element['#form_element_skip_title'])) {
modules/system/system.module:354: '#form_element_skip_title' => TRUE,
modules/system/system.module:371: '#form_element_skip_title' => TRUE,
The first occurrence (includes/form.inc) is from theme_form_element(). It tests to see if #form_element_skip_title has been set. If it has been set then the title of the element is not set.
The second and third occurrences (modules/system/system.module) is from system_elements(). This function sets #form_element_skip_title to true for the radio and checkbox element type.
Comment #4
Everett Zufelt commentedThis patch:
1. Renames #form_element_skip_title to #skip_label. This keeps the property name more inline with other element property names (without the preceeding form_element_, and gives a better description of what the property does, causes theme_form_element() to not output a label.
2. Fixes logic in theme_radio and theme_checkbox.
a. switches the !isnull check of #title with !empty, to make sure that empty strings are not used as labels.
b. Instead of displaying the #title to the right of the radio / checkbox, places it as the title attribute for the input element. This functinality can be changed if we make the #skip_label property a trinary operand providing for right, left, attribute.
Comment #6
Everett Zufelt commentedWorking on a new approach which includes creating a new property for the radio and checkbox system element types.
Property: #title_show
Default: TRUE
If true, theme_radio and theme_checkbox will show #title to the right of the checkbox input element.
If FALSE, theme_radio and theme_checkbox will include #title as the title attribute of the checkbox input element.
Also considering #title_position, with values of left, right, and attribute.
Any suggestions on which is preferred, #title_show or #title_position?
Comment #7
Everett Zufelt commentedHere is my proposal for a new approach:
1. Add two new properties to the system_elements() types for radio and checkbox
#title_position
default: right (to maintain consistency with the current functionality of theme_radio and theme_checkbox)
right: outputs #title to the right of the input element
left: outputs #title to the left of the input element
attribute: sets the title attribute of the input element to #title
#skip_label
default: false
true: theme_radio and theme_checkbox do not wrap the input element in a label. useful if the developer wishes to implement their own label.
false: theme_radio and theme_checkbox do wrap the input element in a label.
Reasoning
Radio and checkbox elements are the only element theme_ functions that handle their own labels, all other elements have their labels handled by theme_form_element. These properties and the necessary changes to theme_radio and theme_checkbox will provide developers with added functionality, while doing the best possible job of ensuring that the elements are accessible to users of assistive technology.
Comment #8
bowersox commented@Everett
In your latest proposal (#7) if skip_label is true, can we make the label non-visible so it still appears for screenreaders?
One use case is the /admin/user/permissions form, which is a huge table of checkboxes. Here is what one checkbox looks like in D6:
That title attribute provides a tooltip for sighted users in some browsers, but users with assistive technology are lost in a sea of indistinguishable checkboxes.
Here is what I would add within the label element to make it work using assistive technology without cluttering up the screen with visible labels for sighted users:
(P.S. Another thing to make this particular admin page better would be an h2 header on each section header within the table. Each module has its own section of the table, eg "menu module". If those were headers, screenreader users could navigate through the sea of checkboxes to find the area they wanted to change.)
Comment #9
mgiffordSo should we mark this as a duplicate of:
#558928: Form element labeling is inconsistent, inflexible and bad for accessibility
Comment #10
bowersox commentedI agree with marking this as duplicate of #558928: Form element labeling is inconsistent, inflexible and bad for accessibility. I look forward to more active dialogue to resolve that issue in D7 core.
Comment #11
Everett Zufelt commentedMarking as postponed to see what happens with #558928: Form element labeling is inconsistent, inflexible and bad for accessibility.
Comment #12
mgiffordThis needs to be tested to verify that it works as described in D7 before closing this issue.
Comment #13
mgiffordFixed last year in #558928: Form element labeling is inconsistent, inflexible and bad for accessibility
Comment #14
liam morland