Add missing form element titles for accessibility

If there is no label or name (see resource below) for these controls then this issue should be marked as a critical bug.

Resource:

Name, Role, Value: WCAG 2.0 success criteria 4.1.2 priority A
http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html

Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

@mgifford

I don't want to assume that something can be brought into core after 7 is released without documentation. Marking as critical for now. Would be happy to set back to normal if confirmation can be provided by someone that this change can be made after release.

Strange is this in CCK then too?

sub

this could be fixed while beta stage

del

@mgifford we need native english speaker for wording of labels

Yes, for most of those fields we don't display a label, because visually the label is the table column header. Adding actual labels above the form elements would add to much cruft.

However, for accessibility reasons, those labels should be set as #title in the form element, and simply hidden with '#title_display' => 'invisible',.
This is what was done for all 'weight' elements used for tabledrag, in #448292: Drag and Drop for table rows is not accessible to screen-reader users. However, the Field UI screens has other form elements without a label, which need to receive the same treatment.

Has been on my TODO for a while, will try to come up with a patch soon.

Depending on what is easier, it is just as useful to set the title attribute on the form field.

Well, #448292: Drag and Drop for table rows is not accessible to screen-reader users went with #title + #title_display, we should stay consistent with that.

+++ modules/field_ui/field_ui.admin.inc	15 Aug 2010 19:06:54 -0000
@@ -339,6 +339,8 @@ function field_ui_field_overview_form($f
+        '#title_display' => 'invisible', ¶

aha, whitespace, you love them mike - pita but must go :)

Powered by Dreditor.

Thks for stepping in, mgifford.

The labels that were added by #448292: Drag and Drop for table rows is not accessible to screen-reader users include the field label :
'#title' => t('Weight for @row', array('@row' => $extra_field['label'])),
The logic is that, if you depend on a screen reader reading out input labels to navigate in a form, just reading 'Weight' gives you the column where you are in the table, but not the row, leaving you equally lost.

Also : in each row, the 'parent' form element should also get a hidden title.

Well, the important thing is consistency. I personnally don't have a strong nor well-informed preference, but if the 300+ comment-long #448292: Drag and Drop for table rows is not accessible to screen-reader users settled on #title + #title_dislpay = 'invisible', we should not take a different route on a whim - neither revive the lengthy debate here...

Also, the 'Manage display' screen has its own form elements without labels on *all* rows, so consistency wrt including the row name in the hidden label will be needed there too.

@yched

Just to clarify, the issue you point to had almost nothing to do with labeling form fields. I doubt there was ever a debate on the topic. I'm just saying there is not point in having labels. If it is easier or if you think it is more desireable for consistency then great. I personally would use the title attribute.

Consistency :
- '@' or '!' ?
- 'row' or 'title' ?

Typo : Dat*a* - Actually, the common terminology is 'Field type' here.

Terminology : 'Widget type'

Let's not suddenly switch to 'imperative verb' formulation.
+ Terminology
--> Should rather be : 'Label display for !title' (or @row or whatever :-)

'Formatter for !title'

'Visibility for !title'

All in all, since these labels are hidden by nature, it would possibly help to post screenshots of those 2 screens, annotated with the proposed 'hidden' labels ;-)

+ Odd display artifacts on 'Manage Fields' screen, 'add existing field' row :
[edited out : those visual bugs are present in current HEAD. Never mind the attached picture. Odd]

Your saying screen shots of hidden stuff? :D I am looking forward to those.

Created #888438: Field UI "Manage fields' visual glitch for the visual bugs mentioned in #22.

+ Setting patch back to CNW

re @Bojhan #23 : I'm saying *annotated* screenshots :-p. If they were just regular labels, checking the consistency and relevance of the newly added labels would be easily done just looking at the page. But since we're talking about hidden labels, we currently need to browse the code or expand the various parts of the DOM in Firebug.

Absolutely not joking about screenshots : how else do you get a fair overview of the UI changes addeed here ?

However, figured out that we don't need to manually annotate a screenshot : playing with the element-invisible class in firebug to unhide the labels and paint them red does the trick. Screenshots attached.

Which shows :

"Manage fields" screen :
- we don't distinguish enough the labels between 'add new' and 'add existing' rows. Figure a blind user trying to guess where he's tabbed himself into.
- 'Form element' on 'add existing field' row needs to be 'Widget type'

"Manage display" screen :
- "Select options for [row]" needs to be "Label display for [row]"

Other feedback from UX folks welcome.

Looks good, I dont know wheter screenreaders dont cross link column titles. Dont want to repeat to much.

Looks good.

Where placeholder is user input can you please use @placeholder instead of !placeholder?

Thanks.

#30: field_ui_label_v6.patch queued for re-testing.

+1 from me. This is a pretty long patch so I'd love another person to review and RTBC.

Perhaps someone more familiar with the inner workings of Field UI will take a look.

This line looks broken - results in invalid PHP :

-        '#attributes' => array('class' => array('field-weight')),
++        '#title' => t('Weight for @title', array('@title' => $extra_field['label'])),

On http://drupal.org/files/issues/screen-capture-2_3.png :
- "New field type" / "New widget type" / "Existing widget type" are wrong.
Should be :
"Type of new field" / "Widget for new field" / "Widget for existing field"
- The titles should use $instance['label'] (i.e "Image"), not $instance['field_name'] (i.e "field_image")

On http://drupal.org/files/issues/screen-capture-4_3.png :
- "Select options for [label]" should be "Label display for [label]"

Looks good to me. Pinging UX folks for string review.

@mgifford I think he just wanted someone to do a text review. I just reviewed it - there seem to be some inconsistencies in sequencing of words but that seems rather minor.

Agreed we need documentation. My goal for this afternoon is to document #title_display in the D7 FAPI documentation. Once we have that done we can at least have a reference for how to hide titles. ad can build out more explanatory docs from there.

Great work on all this labeling!

oh why oh why do I hit yet another one of this...

+++ modules/field_ui/field_ui.admin.inc	21 Sep 2010 13:00:13 -0000
@@ -330,12 +330,16 @@ function field_ui_field_overview_form($f
+        '#title' => t('Weight for @title', array('@title' => $instance['label'])),
...
+          '#title' => t('Parent for @title', array('@title' => $instance['label'])),

@@ -394,14 +398,16 @@ function field_ui_field_overview_form($f
+        '#title' => t('Weight for @title', array('@title' => $extra_field['label'])),
...
+          '#title' => t('Parent for @title', array('@title' => $extra_field['label'])),

@@ -883,6 +907,8 @@ function field_ui_display_overview_form(
+        '#title' => t('Weight for @title', array('@title' => check_plain($instance['label']))),

@@ -890,6 +916,8 @@ function field_ui_display_overview_form(
+          '#title' => t('Label display for @title', array('@title' => check_plain($instance['label']))),

@@ -901,6 +929,8 @@ function field_ui_display_overview_form(
+        '#title' => t('Label display for @title', array('@title' => check_plain($instance['label']))),

@@ -914,6 +944,8 @@ function field_ui_display_overview_form(
+        '#title' => t('Formatter for @title', array('@title' => check_plain($instance['label']))),

@@ -1037,6 +1069,8 @@ function field_ui_display_overview_form(
+        '#title' => t('Weight for @title', array('@title' => check_plain($extra_field['label']))),

@@ -1044,6 +1078,8 @@ function field_ui_display_overview_form(
+          '#title' => t('Parents for @title', array('@title' => check_plain($extra_field['label']))),

@@ -1062,6 +1098,8 @@ function field_ui_display_overview_form(
+          '#title' => t('Visibility for @title', array('@title' => check_plain($extra_field['label']))),

@-placeholders already perform a check_plain(). Please CAREFULLY read http://api.drupal.org/api/function/t/7 - thanks.

Powered by Dreditor.

@sun,

The top 4 lines in your code snippet look right to me, it is just the bottom 7 lines that need the check_plain() removed.

For example, this:

'#title' => t('Weight for @title', array('@title' => check_plain($instance['label']))),

should become:

'#title' => t('Weight for @title', array('@title' => $instance['label'])),

Is that correct? (Or is there anything that should change about the top 4 lines too?)

Please merge in the patches from

#883850: Missing Labels with User Administration (Select & Checkbox)
#885930: Labels missing for simpletest page
#883816: Label missing for checkbox in menu's overview table
#885876: Label needed to create new actions
#851174: Update options checkbox doesn't include labels
#884932: Labels missing for search admin pages
#883822: Labels missing from Trigger Admin Forms
#885946: Image file upload lacks labels

And also

#827906: Adds #title and #title_display to the weight columns of all tabledrag elements in core

<webchick> And yes, I agree with one mega patch. Easier to review and commit.

Setting critical as per @webchick on irc.

We're reaching a point where we need to seriously ask ourselves whether patches like this are truly critical, or whether they can wait to D8. While important, I'm not convinced that this patch should be an absolute release blocker.

Well, the reason I feel it's critical is because it affects our WCAG compliance, which was given a huge push in D7. There are people actively prevented from using forms in Drupal atm because of this issue, which seems wrong to me. Drupal 7 should be for everyone, and Mike, Everett, Cliff, and the rest of the accessibility team have put in tremendous strides to see that happen.

This differentiates this particular patch from something like #925844: Tabledrag 'Show row weights' link needs to be larger in Seven in my mind, which is one user using one program having trouble finding one link. The patch that actually added that link on the page though was a critlcal accessibility bug fix. That's where the boundary is in my mind.

However, you could make the argument that several accessibility tests have been performed "in the field" with people without this issue being fixed and them not having a problem (or at least a documented one) getting around, and that draw conclusions from that that full WCAG compliance is an academic exercise we could push to D8.

I don't feel expert enough to make a call either way, so I deferred to the a11y team who've said this is important. Obviously, your call to make, Dries.

The reason that we rely on WCAG 2.0 priority levels is so that we do not have to make a determination for each issue as to how it might impact potential users. WCAG 2.0 states that all form fields must have an accessible name, provided normally through a programmatically associated label or a title attribute, this is a priority A success criteria.

I can tell you that for some screen-reader users it is very difficult to use forms when accessible names are not provided for form fields. It can also be more difficult for voice command users to use forms when there are no accessible names (I witnessed this last night when a user of Dragon Naturally Speaking was using the D7 admin interface).

Can I give an example where any of the above issues would make any particular functionality completely impossible for any particular set of users, no. Do I trust that the time and effort that went into preparing WCAG 2.0 means that we should trust the expert guidance of that document, yes. Meeting level AAA success criteria might sometimes be an "academic exercise", possibly even level AA, but the level A criteria are the most fundamental and important to accessibility, as determined by the W3c.

*****

The Success Criteria were assigned to one of the three levels of conformance by the working group after taking into consideration a wide range of interacting
issues. Some of the common factors evaluated when setting the level included:

• whether the Success Criterion is essential (in other words, if the Success Criterion isn't met, then even assistive technology can't make content accessible)

• whether it is possible to satisfy the Success Criterion for all Web sites and types of content that the Success Criteria would apply to (e.g., different
topics, types of content, types of Web technology)

• whether the Success Criterion requires skills that could reasonably be achieved by the content creators (that is, the knowledge and skill to meet the
Success Criteria could be acquired in a week's training or less)

• whether the Success Criterion would impose limits on the "look & feel" and/or function of the Web page. (limits on function, presentation, freedom of
expression, design or aesthetic that the Success Criteria might place on authors)

• whether there are no workarounds if the Success Criteria is not met

This patch is a reroll of #43 with the check_plain issue dealt with (from #51)

Additionally, this combines all the patches listed in #56 & #57 (except for #885946: Image file upload lacks labels because there is no patch there and #884932: Labels missing for search admin pages because it appears the patch there has been committed somewhere along the line)

Accessibility is obviously important and I'm both happy and proud that we made so many accessibility improvements in Drupal 7. I care about accessibility.

The reason I'm not convinced this is critical is because the form is most likely still usable without those labels -- it is just harder to use. Many parts of Drupal are hard to use -- we have a lot of usability and accessibility work to do. The point is that we're beyond the point where we should treat usability problems as critical bugs.

@dries

Almost everyone in the accessibility community understands WCAG A success criteria as critical as 'must' criteria. But, you are the boss. I am incredibly disappointed in the community for this decision.

I'm a developer to whom accessibility is incredibly important, and a vital issue on some of the sites I work on. I have to agree with everett, simply put we should make the level A criteria.
not meeting accessibility criteria for such basic UI such as forms should not be acceptable. I feel that this should be critical, and be done now. How much better for it be for Drupal to be able to say that it meets such criteria out of the box?

@Dries wrote:

The reason I'm not convinced this is critical is because the form is most likely still usable without those labels -- it is just harder to use. Many parts
of Drupal are hard to use -- we have a lot of usability and accessibility work to do. The point is that we're beyond the point where we should treat usability
problems as critical bugs.

---

I don't necessarily disagree with this, but the differentiation we can make is that some UIs are poorly usable for all (sucky but that's the way it is for now), accessibility is an attempt to make sure the UIs don't suck any extra for those with disabilities than they do for everyone else. Creating an unnecessary barrier to access for a certain segment of users is, IMO, not acceptable, and is not in alignment with our community's ideals and values.

I can see both points of view, however at some point we have to concede that D7 is as good as we can get it. There are many bugs and issues in all software and while we can strive for perfection, its simply not attainable. For example there are many sucky things for sighted users also - and we're talking major wtf experiences that are not considered critical - for example Overlay can fail to load in many situations (path and domain prefix for languages, or even just using Garland will cause Overlay to fail in many instances).

So while it does suck we can't get everything fixed right now, we do have to take a deep breath and say enough is enough, lets fix things in D8 (with renewed energy and enthusiasm). D7 has been a huge learning curve for all of us I believe, and certainly for D8 we'll go into it much better organized, with a much clearer vision of what needs to be achieved.

@Jeff

Can you provide one example of a sucky thing where persons without disabilities have a worse experience than those with disabilities

I can't do that Everett because I am not physically disabled, therefor I can never fully empathize with an individuals personal physical challenges or their experience using Drupal. What I do know is that there are significant challenges for all users, at many different levels and not all of these will be addressed in Drupal 7.

That said Everett, yes I can actually provide multiple examples - Bartiks broken header can render menu items invisible (but accessible via keyboard), Vertical tabs in RTL are totally unusable for sighted users, Toolbar in RTL provides significant challenges for the sighted - I can go on and on Everett. Only the Vertical tabs in RTL is a critical issue because Drupal is unusable, however there are many other issues that simply make Drupal harder to use that are not deemed critical.

Well, I guess my big question is if this is a WCAG level A compliance thing, why on earth is it surfacing August/September 2010 and not a year ago when making these kinds of invasive changes would've been easier to sell?

I can answer #72 quite easily - mainly because we're few in the accessibility team and we attacked the big hard issues first, which took a long time to fix. Also in the beginning we were not as well organized as we are now - so it was all a bit ad hoc rather than a clear list of issues we needed to address. In short we were learning Drupal accessibility as we went. I think for D8 we will be much better organized and have a very clear list of goals and how to execute them.

This patch can be easily and happily backported at a later point in time, as the element labels are not visible. However, the proper fix for D8 is to additionally require a non-empty #title for all form elements via form_builder(), throwing an exception or error message if one without is encountered, so as to ensure that every form is accessible.

EDIT: That is, because Form API is not able to throw a form validation error for a form element without #title. You simply see the same form, without any error message.

@Sun

1. Please let's allow Dries to make the call on this issue being D7 critical or not.

2. Your suggestion for throwing an error on a missing #title property is great, and should be a separate issue from this issue.

I vote for D7. There is not much down-side to committing this patch. It is very low-risk. There are no UI or strings changes. All the form label changes are set to '#title_display' => 'invisible'. There is little risk but a lot to gain for a subset of users who need these labels to use Drupal.

The burden falls on the a11y team rolling this mega-patch to review and test until we have a solid patch. If we can do that before D7 is released, I think it's reasonable to commit this patch.

@brandon

Not to be 'that guy', but the burden should be on the UI developers who developed the broken UIs in the first place, not the accessibility folk to go in and clean up afterward.

I'll make a stab at getting the tests to pass.

I have no idea if my fixes a) solve any accessibility problems, or b) will make the tests pass. But here they are anyway.

+++ includes/form.inc
@@ -3024,9 +3024,17 @@ function form_process_tableselect($element) {
+          if (isset($element['#options'][$key]['title']['data']['#title']) && !empty($element['#options'][$key]['title']['data']['#title'])) {
+            $title_display = 'invisible';
+            $title = t('Select update options for @row', array('@row' => $element['#options'][$key]['title']['data']['#title']));
+          } else {
+            $title_display = '';
+            $title = '';
+          }
           $element[$key] = array(
             '#type' => 'checkbox',
-            '#title' => '',
+            '#title_display' => $title_display,
+            '#title' => $title,

1) #title_display should unconditionally default to 'invisible'.

2) !empty() is sufficient as condition for $title.

3) else doesn't adhere to coding standards. Could also be omitted by defining $title = ''; before the if.

+++ modules/book/book.admin.inc
@@ -174,7 +174,7 @@ function _book_admin_table($node, &$form) {
-function _book_admin_table_tree($tree, &$form) {
+ function _book_admin_table_tree($tree, &$form) {

mmm

+++ modules/book/book.admin.inc
@@ -191,11 +191,12 @@ function _book_admin_table_tree($tree, &$form) {
+        '#title' => t('Weight for @row', array('@row' => $data['link']['title'])),

+++ modules/field/field.form.inc
@@ -176,6 +176,8 @@ function field_multiple_value_form($field, $instance, $langcode, $items, &$form,
+            '#title' => t('Weight for row @row', array('@row' => $delta)),

+++ modules/field_ui/field_ui.admin.inc
@@ -330,13 +330,19 @@ function field_ui_field_overview_form($form, &$form_state, $entity_type, $bundle
+        '#title' => t('Weight for @title', array('@title' => $instance['label'])),

@@ -1046,6 +1080,8 @@ function field_ui_display_overview_form($form, &$form_state, $entity_type, $bund
+        '#title' => t('Weight for @title', array('@title' => $extra_field['label'])),

(and elsewhere) For translation's sake, we should standardize on "Weight for @title".

+++ modules/field_ui/field_ui.admin.inc
@@ -330,13 +330,19 @@ function field_ui_field_overview_form($form, &$form_state, $entity_type, $bundle
+        '#title_display' => 'invisible',
         '#attributes' => array('class' => array('field-weight')),
+        '#title_display' => 'invisible',
+        '#title' => t('Weight for @row', array('@row' => $instance['label'])),

Duplicate definition.

+++ modules/field_ui/field_ui.admin.inc
@@ -395,15 +401,17 @@ function field_ui_field_overview_form($form, &$form_state, $entity_type, $bundle
-        '#attributes' => array('class' => array('field-weight')),
+        '#title' => t('Weight for @title', array('@title' => $extra_field['label'])),
         '#title_display' => 'invisible',
-        '#title' => t('Weight for @row', array('@row' => $extra_field['label'])),
+        '#attributes' => array('class' => array('field-weight')),

@@ -450,8 +460,8 @@ function field_ui_field_overview_form($form, &$form_state, $entity_type, $bundle
-        '#title_display' => 'invisible',
         '#title' => t('Weight for new field'),
+        '#title_display' => 'invisible',

Please revert any unnecessary changes from this patch (like moving #attributes and #title_display in these examples)

+++ modules/filter/filter.admin.inc
@@ -34,7 +34,12 @@ function filter_admin_overview($form) {
+      '#type' => 'weight', ¶

(and elsewhere) Trailing white-space.

Powered by Dreditor.

I am rerolling this tonight and will have it tomorrow.

This includes all of sun's feedback, I think. Let's see if it passes.

Oops - that was a git formatted patch. Try this one.

I think this is a major bug, not a critical bug. It would be a shame not to fix this before Drupal 7.0 is released, but at the end of the day, it shouldn't hold back the Drupal 7.0 release. As sun wrote, this patch can be easily and happily backported at a later point in time. If you keep working on it, it should land long before Drupal 7.0 is released. I promise to keep it on my radar.

Did some of these tests fail when these were individual patches rather than one mega-patch?

If so, looking at those shorter test results might help us identify which changes caused which failures.

Who is taking a stab at this?

Agreed. I am not familiar enough with simpletest to try to whack this many failures. I was investigating some of the smaller issues prior to their closure.

A meta issue like this may be easier to review, but certainly is not easier to resolve, at least for me.

Re-rolled against HEAD.

I don't see why this shouldn't pass.

We only want to do this patch once, so here comes the hard core check.

Sorry, forgot some.

Yes, that is in purpose. I've temporarily added an explicit PHP user warning to form_builder() whenever it encounters a form element that does not have a #title. We only want to do this patch once for D7. Of course, we'll remove that PHP user warning from this patch later on, but the goal is to make this patch pass - with the code that triggers explicit warnings.

@mgifford: Please note that it also makes patch reviews harder for people who have to review and sign off a patch -- which has to happen before Dries or webchick will even notice. By splitting issues, every patch reviewer would have to familiarize with each individual issue at hand, and double-check that the proposed changes are actually in line with what we want to do. Therefore, it only makes sense to merge these changes into a single patch, and get that one done right. Fixing those remaining failures should be doable within no time.

Let me take another crack at it.

This should get rid of a lot of the test failures. Some of them are spurious - the check in #99 catches all missing labels, even in places where we don't want them (such as the column of checkboxes on the permissions page, which is already labeled correctly and doesn't need another overall label for the group). But there are probably some real ones left.

Wow, this appears to be getting very close.

Can someone please give me a brief explanation of the difference between a test failing and there being an exception?

This means that @ksenzee fixed all previously existing test failures. All remaining exceptions are caused by form elements that do not define a #title.

Note that you can skip the exceptions for #type 'machine_name'. Form elements of this #type automatically get a default #title set, if no custom #title was specified.

The exception message was crafted in a way that it exposes the originating form_id + the element #type, so by looking at the test results, you should be able to identify the forms and form elements that still need to be fixed.

(To hide #type 'machine_name' from the exceptions, the corresponding condition in form.inc [in this patch] would need a quick fix.)

Yep, what @sun said. I'm fixing the remaining exceptions now, and I'll tweak the form.inc error condition to exclude some of the stuff we know is okay.

Another round of fixes.

I've run out of time for the evening, so I'll unassign myself in case anyone else has time to finish up. The remaining exceptions are for form elements without titles in field_ui_field_edit_form and user_profile_form, plus a couple of test-only forms that don't matter.

"elements without titles in field_ui_field_edit_form"

They are declared in image_field_instance_settings_form() - instance settings for image fields.

OK, fixed the missing elements pointed by the test exceptions
- a couple elements in image_field_instance_settings_form() - some others in there were properly handled already.
- a couple test forms
- expanded #type = 'date' FAPI elements - form_process_date()

+++ includes/form.inc
@@ -1623,6 +1623,16 @@ function form_builder($form_id, &$element, &$form_state) {
+    $titleless = array(
+      'submit', 'button', 'image_button', 'hidden', 'token', 'value',
+      'tableselect', 'password_confirm', 'machine_name',
+    );
+    $exceptions = array(
+      'user_admin_permissions', '_form_test_disabled_elements', 'form_label_test_form', 'form_test_limit_validation_errors_form',
+    );
+    if (!isset($element['#title']) && !in_array($element['#type'], $titleless) && !in_array($form_id, $exceptions)) {
+      trigger_error("{$form_id}: Missing title for #type {$element['#type']}, #id {$element['#id']}", E_USER_WARNING);
+    }

Of course, this has to be removed now.

+++ includes/form.inc
@@ -2998,9 +3013,16 @@ function form_process_tableselect($element) {
+            $title = t('Select update options for @title', array(
...
             '#type' => 'checkbox',
-            '#title' => '',
+            '#title' => $title,

This label sounds a bit odd. It's for a checkbox in a table, allowing to toggle whether something should be done with an item. Shortened that into "Update @title"

+++ modules/comment/comment.admin.inc
@@ -50,6 +50,8 @@ function comment_admin_overview($form, &$form_state, $arg) {
   $form['options']['operation'] = array(
     '#type' => 'select',
+    '#title' => t('Bulk update options'),

Same here, changed into "Operation".

+++ modules/file/file.field.inc
@@ -674,8 +674,11 @@ function file_field_widget_process_multiple($element, &$form_state, $form) {
+        //'#title_display' => 'invisible',

Removed stale comment.

+++ modules/locale/locale.admin.inc
@@ -35,11 +37,17 @@ function locale_languages_overview_form() {
+  $form['enabled'] = array(
+    '#type' => 'checkboxes',
+    '#title' => 'Enabled',

Missing t() and odd label. Changed into "Enabled languages".

+++ modules/locale/locale.admin.inc
@@ -35,11 +37,17 @@ function locale_languages_overview_form() {
+  $form['site_default'] = array(
+    '#type' => 'radios',
+    '#title' => t('Default'),

Same here. Changed into "Default language".

+++ modules/locale/locale.admin.inc
@@ -545,13 +553,20 @@ function _locale_languages_configure_form_language_table(&$form, $type) {
+        '#type' => 'checkbox',
+        '#title' => t('Enable @title language provider', array('@title' => $provider['name'])),

Removed the "Enable" prefix.

+++ modules/poll/poll.module
@@ -390,6 +390,8 @@ function _poll_choice_form($key, $chid = NULL, $value = '', $votes = 0, $weight
   $form['chtext'] = array(
     '#type' => 'textfield',
+    '#title' => t('Choice @number', array('@number' => $chid)),
+    '#title_display' => 'invisible',
     '#default_value' => $value,

@@ -397,6 +399,8 @@ function _poll_choice_form($key, $chid = NULL, $value = '', $votes = 0, $weight
+    '#title' => t('Vote count for choice @number', array('@number' => $chid)),

@@ -405,6 +409,8 @@ function _poll_choice_form($key, $chid = NULL, $value = '', $votes = 0, $weight
+    '#title' => t('Weight for choice @number', array('@number' => $chid)),

Don't think that the internal choice ID should appear anywhere in the UI. Changed all of those.

+++ modules/shortcut/shortcut.admin.inc
@@ -72,6 +72,8 @@ function shortcut_set_switch($form, &$form_state, $account = NULL) {
+      '#title' => t('Name for the new shortcut set'),

Shortened to "Name". We don't use such lengthy labels anywhere else.

+++ modules/simpletest/tests/batch_test.module
--- modules/simpletest/tests/form_test.module
+++ modules/simpletest/tests/form_test.module

Removed all testing module changes.

+++ modules/system/system.admin.inc
@@ -2930,6 +2932,8 @@ function system_actions_manage_form($form, &$form_state, $options = array()) {
+    '#title' => t('Create action'),

Shortened to "Action".

+++ modules/taxonomy/taxonomy.admin.inc
@@ -664,6 +670,7 @@ function taxonomy_form_term($form, &$form_state, $edit = array(), $vocabulary =
   $form['vocabulary_machine_name'] = array(
     '#type' => 'textfield',
+    '#title' => t('Machine name'),
     '#access' => FALSE,

Reverted this and fixed it properly: should be #type 'value', which is already used elsewhere for the same field in taxonomy.admin.inc.

Powered by Dreditor.

Committed to CVS HEAD. Thanks!