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).
Revert "Escape '&' in anchor hrefs" - missed escaping '"'

This reverts commit c90f92600716ef7bf3c9efa9344d475586aa32a4.
Escape anchor hrefs ('&', '"', ' ', etc.)

'&' and '"' need to be escaped as '&amp;' and '&quot;' in html attributes.

' ' needs to be escaped as '+' or %20 in query string parameters.
Escape form input values by fixing usage of set_value()

Double quotes and so on need to be escaped inside attribute values.
In most cases set_value() does this for us, but that doesn't work
when we bypass it :).

It looks like this also fixes a bug in these forms.
Now, if you enter an invalid value and hit submit,
you'll get _your_ value back, so you can edit it
and try again.  Previously, the value would have
been reset to the original from the database,
which could be a bit frustrating.
Escape variables that need it

I.e. variables loaded from the database.
(Also module details in the modulebuilder index).

We can't rely on xss_clean() to prevent XSS attacks.
It's broken at the moment, and has been broken twice before.

https://github.com/EllisLab/CodeIgniter/issues/1705#issuecomment-7723346=
http://blog.kotowicz.net/2012/07/codeigniter-210-xssclean-cross-site.html
http://blog.astrumfutura.com/2011/05/codeigniter-2-0-2-cross-site-scripting-xss-fixes-and-recommendations/

If you don't want users to be able to insert rich markup
(Bonfire doesn't, at least outside the emailer class)
xss_clean is trying to do way more than you need anyway.
So if we work towards rooting it out, we could be more
confident in our security _and_ performance.
gravatar_link(): escape alt and title

These are set to the user's email, or display name.

When testing the escaping in user_form.php,
gravatar_link() also let unescaped HTML through.
Luckily this happened to result in invalid html,
which showed up in the html validator.