Set the for attribute on the labeled-radio-button

[poteto]

This PR is to allow the checking of a radio input by clicking on the
label that has its input id as its for attribute.

[poteto]

Apologies for the failed builds and rebases. I believe the issue is with Travis being on Phantom 1.9, and there being an existing bug with clicking on labels not triggering their for inputs – see ariya/phantomjs#12032.

The tests pass fine locally on PhantomJS 2.0. I'll try and investigate to figure out a workaround...

[raycohen]

I was under the impression that we did not need to put the for attribute on the label because by wrapping the input in the label they are implicitly associated. Does a unit test that triggers click on the label without these changes not work?

[poteto]

I updated Travis to use PhantomJS 2 – see travis-ci/travis-ci#3225

@raycohen The change is primarily so we can pass the id to the radio-button-input from both the labeled-radio-button and radio-button component. In our use case, we have it so the input is not nested inside of the label, and this PR allows that to work.

Having the for attribute on the label is also a requirement for accessibility.

[raycohen]

Can we add an id to the nested input and still use the implicit association to bypass adding the for? That should allow associating non-wrapping label elements.

[poteto]

I'm curious why you would prefer not to have it on the label, explicitly adding the for attribute is recommended for accessibility, and we don't really lose anything by adding it. The id is being passed into the input in this PR.

[raycohen]

This convinced me that the use of for is not always redundant (in our wrapped usage):

some assistive technologies do not correctly handle implicit labels

http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H44.html

Thanks!