Added create method for sending email to specific users
user login: remove blank label (confuses Orca Screen Reader)

This was already omitted in themes/default/parts/modal_login.php.

Blank label doesn't contribute to text, layout
(it's a float in the margin of a normal block),
or anything else.  Blank elements are generally deprecated.

On the negative side, the blank label confuses Orca Screen Reader,
which reads "Remember me for two weeks" twice.

I've filed it on the GNOME bugzilla as well, but a11y is generally
lacking love.  So we shouldn't go out of our way to confuse
people who have reading disabilities.
Remove empty label elements

Many reference non-existent ids, which shows up in conformance checkers.
Some have inconsistent identation in the source code.

Likely some will confuse screen readers like Orca,
and there's just no reason for them.
(See previous commit message).
Fix missing ids referred to by form labels

w3c-validator points out:
  "The for attribute of the label element must refer to a form control."

Specifically, the _id_ of a form control.  The _name_ doesn't count :).
timezone_menu() needs an id so the control can be labelled

We're using <label for="timezones">, so we need
id="timezones" on the form control.

flagged up by w3c-validator:
  The for attribute of the label element must refer to a form control.
  <label class="control-label" for="timezones">Timezone</label>
roles module: associate dangling label with the correct form control

Tested using the Orca Screen Reader in Firefox (Ubuntu 12.04).
Remove <div class="inputs-list> (previous version of bootstrap)

'Up to v1.4, Bootstrap required extra markup around checkboxes and
radios to stack them. Now, it's a simple matter of repeating the
<label class="checkbox"> that wraps the <input type="checkbox">'

http://twitter.github.com/bootstrap/base-css.html
fix three labels supposed to be associated with groups of radio-/checkboxes

(Reminder: <label for="can_delete"> targets the element with _id_
"can_delete", not all the form elements with a _name_ of "can_delete").

Replacing the label with <legend> (and the enclosing div with <fieldset>)
would be best for screen-readers (nested fieldsets are perfectly legal).
However bootstrap's CSS doesn't support that usage.

Fall back to WAI-ARIA.  Tested with Orca Screen Reader.  Both e.g.
"Removable?" and "Yes" are read, but only after disabling CSS -
reported as Orca bug <https://bugzilla.gnome.org/show_bug.cgi?id=680249>.

The behaviour is not well-specified.  We don't want to use role=radiogroup
because it's not compatible with the normal html radio buttons (and yet it
"SHOULD" be present for *all* radio buttons).  The only bright side is
that there's been at least two large test suites which rely on the same
behaviour as we do here.

Disclaimers
 - Screen readers will still miss the longer help-inline when tabbing
   through the form.

 - The behaviour differs from <label for="x"> used in the rest of the form
   in that this label is not clickable.  Par for the course IMO
   (label click targets incorrectly include large white spaces;
    clicking on the field names on the left hand side will toggle
    a checkbox field...)  Someone could smooth it over in JS if they like.

 - modulebuilder still generates (invalid) labels like the ones we've
   just fixed.
user settings: fix missing label on "user meta" dropdown fields
activities report: fix form controls with no associated label

 - mark up the label text for <select> by wrapping both together
   in a <label>

 - bootstrap <select> defaults to block, so this change would alter the
   design (for the worse).  Use .form-inline to keep everything on
   one line.  Doing this the right way pays dividends: as a side effect,
   this improves the vertical alignment of the <select> with the label
   text.
activities reports: make delete "buttons" keyboard-accessible
Revert "timezone_menu() needs an id so the control can be labelled"

This reverts commit e8b65220180d0302a8325cc11cd34e20fa317625.

I didn't notice I was editing an upstream CodeIgniter file.
CodeIgniter/develop actually has different fix for timezone_menu(),
which is not compatible.

Note that merging the upstream fix won't do anything on its own;
each caller of timezone_menu() will have to set a new parameter,
to get an id which can then be associated with a label.
translate editor: associate form controls with the corresponding labels
Make all label associations explicit - required by some screen readers

(and hence by some accessibility guidelines, such as W3C WAI's WCAG)

"JAWS 7.10 was tested on Windows XP with Internet Explorer 6.0
and Firefox 1.5... In forms mode it does not read the label for implicit
labels on checkboxes and radio fields...

Window-Eyes 5.5 was tested on Windows XP with Internet Explorer 6.0
and Firefox 1.5... It does not speak the label for the implicitly labelled
form control in browse on mode."

 - http://www.w3.org/TR/WCAG-TECHS/H44

"in JAWS 8, XP, IE7 implicit labelling appears to work unless the label is
not placed where it is expected to be (eg to left for inputs, to right for
checboxes and radio buttons)... this suggests that JAWS ignores the
implicit labelling and relys on its own heauristics to decide what to
announce unless the label is explicitly associated."

 - http://lists.w3.org/Archives/Public/public-html/2007Aug/0376.html
Make more label associations explicit - required by screen readers

Some labels that were missed the first time round.

(Some modulebuilder label fixes are elsewhere.
modulebuilder output hasn't been touched either).
Merge branch 'valid-2-validity-v2' into valid-3-accessible-slightly

Resolves conflicts with develop,
so this can still be merged automatically by github.
Merge branch 'modulebuilder-fixes' into valid-3-merge-modulebuilder-fixes

Conflicts:
	bonfire/application/core_modules/modulebuilder/views/developer/modulebuilder_form.php
Merge branch 'valid-2-validity-v2' into valid-3-accessible-slightly

Resolves conflicts with develop,
so this can still be merged automatically by github.
Merge branch 'modulebuilder-fixes' into valid-3-merge-modulebuilder-fixes

Conflicts:
	bonfire/application/core_modules/roles/assets/js/settings.js
	bonfire/application/helpers/application_helper.php
Merge branch 'valid-3-merge-modulebuilder-fixes' into valid-3-accessible-slightly

Resolves conflicts with develop,
so this can still be merged automatically by github