I need to place a small note beneath an Input Box on a Form to help Users properly complete the Form.
<label for="msgTo">To:</label>
<input id="msgTo" name="msgTo" type="text" maxlength="30"
value="<?php echo (isset($msgTo) ? str2htmlentities($msgTo) : ''); ?>" /><!-- Sticky Field -->
<sometag>Please do the following...</sometag>
What is the proper markup to use?
<div> ?
<p> ?
<span> ?
Other?
Sincerely,
Debbie
If the message relates to the input above, I would do it as part of the label. Otherwise, you are assuming the user can see the screen. (Best to have the “watch your step” warning before the step, rather than after. 
)
Well, here is a screen-shot of what I’m trying to create…
Besides liking the look of that, my Form is set up to display Error Messages to the right of each Form Control when there is a data-entry error. And I don’t plan on changing that, so the location of “You may send your message…” seems to be the best location.
Sincerely,
Debbie
I’m thinking a simple <p> would do…
Debbie
You missed the point of what I was saying. If you really want to do this properly, don’t just think of it in visual terms, but also semantic terms. I never like to have instructions come after the point of action. I would place the instructions before the input, under the label, probably as part of the label (perhaps a span within the label set to display block so that it sits beneath the label, and styled differently).
How about this… (Disregard the “To” and “Bcc” code as I haven’t updated the ID’s and Names yet)
<!-- SEND PRIVATE MESSAGE FORM -->
<form id="sendPM" action="" method="post">
<fieldset>
<legend>Send Private Message (PM)</legend>
<div id="multipleUsers">
**You may message to up to 5 people at a time.<br />
Separate usernames with a semicolon. (;)</div>
<!-- PM To -->
<label class="recipients for="pmRecipient">To:</label>
<!-- Sticky Field -->
<?php
echo '<textarea id="pmRecipient" name="pmRecipient" cols="35" rows="2">';
echo (isset($pmRecipient) ? str2htmlentities($pmRecipient) : '');
echo "</textarea>";
if (!empty($errors['pmRecipient'])){
echo '<span class="error">' . $errors['pmRecipient'] . '</span>';
}
?>
<!-- PM BCC -->
<label class="recipients" for="pmRecipient">Bcc:</label>
<!-- Sticky Field -->
<?php
echo '<textarea id="pmRecipient" name="pmRecipient" cols="35" rows="2">';
echo (isset($pmRecipient) ? str2htmlentities($pmRecipient) : '');
echo "</textarea>";
if (!empty($errors['pmRecipient'])){
echo '<span class="error">' . $errors['pmRecipient'] . '</span>';
}
?>
Is that more accessible?
Here is what it looks like…
Sincerely,
Debbie
It’s a more logical order, I think. In certain modes, screen readers may or may not skip the div text, though. But @Stomme_poes is better placed to advise on such things.
I’ve been using p’s + aria-describedby, but not sure it matters.
A screen reader in forms mode would ignore the div/p/whatever, but not all readers have a virtual buffer that only looks at form controls. So a good order may help, though our e-commerce help text tends to be underneath (I think because the error text goes there as well).
<label for=“foo”>Foo? </label>
<input type=“text” id=“foo” name=“bar” aria-describledby=“multipleUsers”>
<p id=“multipleUsers”>
**You may message to up to 5 people at a time.<br >
Separate usernames with a semicolon. (;)</p>
If you use this version, be sure to use aria-describedby. It looks similar to aria-labelledby, but the latter is for things without any label, and so will override any actual label you have. You don’t want that.
What ralph is talking about is an extended label. They look like this:
<label for=“foo”>Foo? <span><b> **You may message to up to 5 people at a time.</b>
Separate usernames with a semicolon. (;)</span></label>
<input type=“text” id=“foo” name=“bar”>
where the label is position: relative and the span can be placed pretty much anywhere. The b is just some random sandbag so you can have a break by making it display: block. Could be another span instead. Screen readers don’t get any semantics from <b> that I know of, so it’s a nice throwaway tag, because for everyone else you can font-weight: normal it.
The benefit of the second method is it doesn’t rely on aria-stuff. Because the instruction is in the label, it’s pretty much available to everyone.
Thanks poes. ARIA is cool. Much better than HTML5 elements, IMHO.
I have no clue what that is…
What do you think about the screenshot in Post #6?
That is more in line with what Ralph suggested, and I think it looks pretty good.
If I want things to look just like the screenshot above, can I move the <span> before “Foo?” in your example?
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.)
Sincerely,
Debbie
poes gave you a code example:
<label for="foo">Foo? </label>
<input type="text" id="foo" name="bar" [COLOR="#FF0000"]aria-describledby="multipleUsers"[/COLOR]>
<p [COLOR="#FF0000"]id="multipleUsers"[/COLOR]>**You may message to up to 5 people at a time.<br >
Separate usernames with a semicolon. (;)</p>
The aria-describedby attribute serves to tie the input with the <p>, kind of like associating a label with its input.
Right, but WHEN and WHERE did that come from?!
I have never heard of that aria thingy up until now…
Is that like HTML5 or CSS3 or some other new language thing I don’t use yet?! 
Debbie
The latter.
It’s been around a while, and is a better solution to accessibility than many of the new HTML5 elements, IMHO.
There are simple attributes you can add to elements to make them more semantically meaningful, such as role="navigation" on a navigation <ul>. This has theoretically been taken over by <nav>, although I’m not sure how many devices actually recognize the semantics of <nav> yet, while role=“navigation” is well understood by assistive technologies.
Thanks for the Accessibility “heads up”! 
Debbie
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>
I still think that it would be easier to create lots of attributes that associate one element with another, or describe an element’s role, than just getting a piddly few new elements whose meaning is vague at best anyway. Call it ARIA is you will, or something else, but it’s a more flexible system.
You might mean the upcoming Web Components, and ARIA will be important there.
Users are allowed to have up to 5 total Recipients for a Message. (That includes “To:” and “Bcc:”)
Not sure if that changes how you’d approach things?
Sincerely,
Debbie
I haven’t really grasped what they are all about yet. One of the reasonings for the new document outline for HTML5 is that it’s clearer what goes with what, but I think ARIA roles might have handled situations like that better than what they came up with—as shown by your example of aria-describedby.
Unless something brings it back, document outline is a zombie still wandering the WHATWG spec. If browsers ever start implementing it though, it may well Lazarus.
Web Components is basically, make-your-own-tag, like XML but without the XML.
like <x-mytag> lawlz </x-mytag>
where their scope remains solely within your application, so there’s nothing like a DTD for it. It’s mostly for your Javascript to have more DOMmy stuff to nom on, if I understand it right.
I’m personally using fake <template> tags currently, to hold a chunk of DOM instead of constantly building DocumentFragments and holding them in memory all the time.
<script type=“text/x-template” class=“someClassForJS”>
HTML here
</script>
Script is used simply because they by default aren’t exposted to users directly via the browser. <template> will do that. Great for modals or tacking on repeated lists of things.
Nah, same approaches, I’d just have the message, even if it only appeared on the first input, be clear that it’s total, in whatever way you usually do for your clients.