<p><input type=“checkbox”> Please send me a ton of email</p>
Apologies, but I am getting confused here.
The code example passes 1.3.1 Info and Relationships because the content is grouped by the <p> element and passes 3.3.2 Labels or Instructions as the control has a visible prompt, but fails 1.1.1 Non-text Content and 4.1.2 Name, Role, Value as the control does not have a name.
This may or may not pass 1.3.1 and 4.1.2/1.1.1 as a result of the implied relationship and the assistive technology support for that relationship. It is impossible to say that it passes or fails without that additional information. If I pick assistive technologies and browsers that read the accessibility name correctly from that undesirable markup then I would pass 4.1.2/1.1.1 as it has a programmatically determinable name and for the same reason I’d pass 1.3.1. If the name doesn’t get read, then it not only doesn’t have a programmatically determinable name but since the text that is used for the 3.3.2 label is right there the fact that it wasn’t recognized is a sign that the relationship isn’t programmatically determinable either.
As a developer, this is just how you don’t want to do this. You want to pick a technique that provides greater rigor and predictability, but for WCAG 2.0 this will not always fail.
There are a number of possible methods to resolve the failure state including:
via label
<p><label><input type=“checkbox”> Please send me a ton of email</label></p>
AWK: This (or with the for/id attributes) is what WCAG techniques promote in the examples. Clearly the best, most native way.
via aria-label or title attribute
<p><input type=“checkbox” aria-label="Please send me a ton of email"> Please send me a ton of email</p>
AWK: This also works. Some people on the list have disagreed saying that this fails 1.3.1.
or via aria-labelledby
<p id="label"><input type=“checkbox” aria-labelledby="label"> Please send me a ton of email</p>
AWK: yep, also good.
Does that help clarify at all Steve, or just mess it up further?
AWK