I think visually it’s okay, because you are assuming, and probably can assume, that users realise the extra help text is only referring to the BCC part (right? now I’m not sure).
In my extended-label example (the second one with spans and stuff), you could place the text mostly where you wanted, while semantically putting it where you think the right place is.
Yeah, you can stuff any kind of inline into an inline label, pretty much anywhere. However what I’ve done so far regarding help text and labels is, the main “label” part I’ve put first: both visual users and screen reader users, once they’re comfortable with computers, tend to skim. Nobody likes actually reading web content so I put the actual label stuff first. like
<label for=“foo”>First name: <span>any special hints/help about the first-name input</span></label>
A skimmer gets the first-name part. People are more likely to skim if they’ve filled out the form once before… someone filling it in again doesn’t have to listen to the help text first before being certain that this is the first-name field for example.
But that’s not any hard or fast rule. You’re pretty free to do what works best with your content.
But isn’t that somewhat misleading, since those instructions would technically apple to both my “To:” and “Bcc:” fields? (I left the “Bcc:” field out until I get the “To:” field styled right and my back-end code working right.)[/quote]
Does the full instruction belong to both? You could explicitly state that, and have the aria association with the first one, since logically people should hit that one first.
Aria-describedby is not limited to a single recipient.
<p id=“someID”>This is help text</p>
and more than one input may refer to it
<input type=“text” aria-describedby=“someID”>
<input type=“checkbox” aria-describedby=“someID”>
This works, though long text may cause annoyance
Another note on aria-describedby, since Marco Zehe reminded me of it: this is something that, in SR’s with a virtual buffer, only get activated/read out when the userr focusses on the thingie with aria-describedby. Not before, and not if you hang it on a non-focusable.
So if using aria-describedby, that help text only gets announced if the user focusses on the input. Now usually this is what happens with labels (when you focus on an input, the label gets read out, along with input type and sometimes other things), but a label can be accessed separately if someone wants to.
They’re solutions with HTML/HTML5.
The first rule of ARIA is, use proper HTML elements and no ARIA, if possible
ARIA exists because we simply build things that don’t have a good HTML representation, and might never. Widgets and stuff. ARIA attempts to make that stuff as accessible as the base HTML elements. But in any case, they must work together.
<label for=“foo”>This button Does Stuff!</label>
<button id=“foo”>Press me!</button>
is better than
<h2 id=“heading”>This button Does Stuff!</h2>
<span role=“button” tabindex=“0” aria-labelledby=“heading”>Press me!</span>