Make position of #description configurable

Tagging so it's identified to the usability team

Not convinced either. I'm not really seeing a reason *why* you want to do this.

You are putting more text in front of the user before you let them at the actual task of filling in the field. Drupal already has a (bad) habit of showing help text *before* functionality (see the block admin page for an extreme example), the way I see it you are proposing to replicate that same behaviour on a per-field basis. I don't think that will make for more productive forms.

I completely agree with emmajane. IF you have a textarea field that is 20 rows high, and you want to supply help text, it's not until you get to the end you actually see what you were "supposed" to put in the field. In addition if you have 10 or 20 check boxes you also have the same problem. I am creating a funding application form for a client in D6 and its imperitive on a number of the items that the user gets the instructions before setting out to answer the question.

These forms will be filled out by the general public and they need the information in a logical way, which to me would be Label, Help text, input.

Just as a side note and would hope for a PM - not to be answered on this thread but emmajane if you had a method to do this in D6 for your clients I'm in dire need of finding one and would really appreciate if you could help me out!!

My 2 pennies :) Adam

I would prefer to see this solved in contrib, not in core. I can see the use case but overall still looks like an edge case. The proposal is to make this a per-field option? That would mean mean an extra checkbox for each field in your content type. Overkill for core imo.

Let's not :). Although I understand the need for this, Drupal descriptions are not ready yet.

btw: the code used in my previous patch can be done also in your theme by overriding theme_form_element() (as I do on every of my sites).
Its just a simplification and changing of default behavior.

+1... on my site users specifically told me that they were very confused by the descriptions being below form elements, especially text areas, so I themed it such that descriptions always appear above the field (just below the label). This looks very good IMHO as long as a label is present. However, for fields that don't have labels this becomes confusing and looks awkward. A good solution for me would be to place descriptions between the label and the field if a label exists, and below the field if there is no label.

Edit: I achieved this by adding a conditional to my theme's template.php that outputs the description prior to the field if a title is present and after the field otherwise

http://www.smashingmagazine.com/2009/09/24/10-useful-usability-findings-...

"A study by UX Matters found that the ideal position for labels in forms is above the fields. On many forms, labels are put to the left of the fields, creating a two-column layout; while this looks good, it’s not the easiest layout to use. Why is that? Because forms are generally vertically oriented; i.e. users fill the form from top to bottom. Users scan the form downwards as they go along. And following the label to the field below is easier than finding the field to the right of the label."

Thanks for the multiple patches / snippets to fix this. While I agree an option per each field in core is overkill, descriptions above the input and below the label are essential for most of my client work. Consider a wysiwyg textarea that by default fills the screen (i.e. CKeditor), or an unlimited field, or a field collection (multigroup). In each instance the user will not see the help until they scroll, in last case sometimes for a screen or two. This is compounded when a user is editing content that has already been created in unlimited fields or field collections case.

In my opinion help text that gives a user information essential to completing a field must be visible to the user before they begin to fill out that field. It's a clear usability pass/fail.

Some core descriptions are long, multiple lines including allowed html tags and the like. I can see them being distracting above the field. Possible solutions seem to be:

• Invite some copy specialists rethink and edit down long core descriptions, then place all descriptions on top.
• Creating a new, secondary description field and defining the purpose of one as essential help text, one as additional, non essential information (analogous to link or img title text in html).
• Global option for all field descriptions on the Drupal installation.
• A more complex module that offers choices by content type or UI area. This might be a good project for D7 to gauge interest in the alteration for D8.

If I had to choose one or the other for my whole installation, I would choose top no questions. Lots of text above the field can be a usability speed bump, but not having access to instructions or an essential piece of help text is a usability failure.

Thanks. What would argue against this though, is that too many of our descriptions are still way too long. Increasing distance between label and form field by more than one line would look silly and I assume be counter-productive too.

#17, @mgifford, that quote refers to labels, not descriptions. Drupal form labels are already on top by default.

Titles & Labels are both valid ways to identify form controls. In Drupal 7 & FAPI we weren't able to get both elements into the API. In Drupal 8 I am hoping that FAPI gets rewritten so that the concerns expressed about including a title element. The invisible label was a work-around.

I'm updating the link here to the final (rather than 2008 draft) of WCAG 2.0 - http://www.w3.org/TR/WCAG-TECHS/H65.html

The usability team has done some great work on encouraging the community to think more closely about the language that we use. So much of the time it isn't clear enough. Having a one line description would usually be sufficient.

I don't think it's a huge issue, but do think it would be great if there were a default setting where one could switch the location of the description to either above or below the field. Heck, maybe even stuff it into a tooltip type of functionality like http://hanshillen.github.com/aegisdemo/

IMO, not a WCAG 2.0 requirement, should anyone disagree please provide SC that we are currently not passing.

I agree that it could be useful for fapi, if not field api to provide this option.

In fapi we could add a new property:

This is a theme setting, and might not be appropriate as a fapi property, however, the options are:

1. Do nothing

* Keep things as we have them now and individuals can solve this themselves with theme overrides (sometimes very complicated if you only want this to apply to certain elements).

2. Use #description_before #description_after

* This would require refactoring of every Core / Contrib module that uses #description. It would also not be semantic and would cause some accessibility problems. There is a 1 - 1 relationship between element and description semantically (elements do not have two descriptions), and in accessibility APIs there is a 1 - 1 UI control - description relationship.

3. Allow for a fapi property to indicate if the description should be rendered before or after the element, and modify theme_form_element() to use this. Field API could then possibly leverage this (in core or contrib) as an additional setting when creating a field.

penyaskito: attach your patch here to continue the discussion. I marked the other issue as a duplicate of this. Thanks for checking in here :)

New patch using #description_position instead of #description_display.

Thanks for catching it and pointing to me to the right direction, @Lis Lem.

However, if I edit that function the description will be print before the Body label. I'm looking at field_multiple_value_form to see if I find where to put it just after the Body label.

Hi kaare. Didn't know about your sandbox. I had a look and the feature is the same than in this patch, but the unsolved problem here is with text with summaries and with formatted text areas, that have changed a lot once fields are included in core since D7.

Thanks anyway for sharing!