On my forms below the actual label for text boxes, I want to add smaller descriptive text of what each field is. So something like Name < br /> Enter your username to access the site, and then to the right have the text box for the username.

The p could be a span if your hint is really more of a fragment or you want your label-input pairs to sit next to an inline element.

Don't confuse aria-describedby with aria-labelledby (and note the spelling for that... that's TWO l's). Aria-labelledby will override your real label, which you generally don't want. You merely want your hint to be associated with the input.

Anyway, this method is not preferred over the text-in-the-label method above, which works with older browsers and Accessibility Technology (though I would have a space character between the label text and span text there, or you'll get "NameEnter your username..." read out), but having the hint text separate does allow you a bit more freedom in positioning, if you wanted the hint text right above or below the input, which is something I see commonly (also error messages).

Usually sites put the message under the input rather than the label which although removes it from the label does make it easier to see but of course is not quite so good for accessibility as having it in the label itself.

As Ralph said you really only want message when the input is not clear. I've added messages to the following example which was constructed for a previous thread as an example of something

Nice links, Paul I've just been looking at form design, with a list off error messages and links to the offending fields. One thing I notice is that clicking those error links doesn't lead to the label or input that needs to be changed gaining focus. I'm sure Ive read how to do that ... must look it up again. @Stomme_poes; Are you going to resurrect your form pages on your site?

Nice links, Paul I've just been looking at form design, with a list off error messages and links to the offending fields. One thing I notice is that clicking those error links doesn't lead to the label or input that needs to be changed gaining focus. I'm sure Ive read how to do that ... must look it up again. @Stomme_poes; Are you going to resurrect your form pages on your site?

You can use target to highlight the input but you will need js to put the focus in there.

Nice work, Paul. It would be nice if it could work without JS. I was hoping you could go to the form element, fill it in, and press the back button to go to the next error. Seems this can't be done with HTML alone.

I've been reading up, and it seems a viable alternative is to use PHP to refresh the page with only the form elements that need to be corrected, the correct answers already stored. Seems a good alternative. Presumably the user can press the Back button to see the whole form instead. (I'm about to test out this theory.)

Yeah. Still working on it; one of my last pages to redo partially because of all the new ARIA stuff coming out In the meantime, Marco Zehe has some "ARIA-tips" on his English blog that are really great. Also some good ARIA stuff on Paciello Group's blog, mostly written by Steve Faulkner.

Ralph said:

One thing I notice is that clicking those error links doesn't lead to the label or input that needs to be changed gaining focus. I'm sure Ive read how to do that ...

I have had the generated error page add in anchors as destinations right above the label. You can't know if a screen reader will read out the label when there is focus brought to the input; some do, some don't. So I try to use something before the input when building a skip list. I think Paul's idea could be an option, but mostly because we'd be assuming the user was on a list link which described the error and field in the first place.

Paul said:

The back button seems to break most forms or you end up paying for something twice.

I have had the generated error page add in anchors as destinations right above the label.

Unless I'm missing something, when I click links like that and then start tabbing, the tabbing starts from the original link, rather than the spot where I've jumped to on the page. Can the focus move to the element that's jumped to?

Ralph: what you're experiencing is a webkit bug from at least since 2008. All other browsers will move the keyboard focus to the skip area like they should Of course, Hixie claims exactly the opposite (that most browsers don't move the keyboard focus), which completely contradicts reality as usual. Also, I know Joanmarie Diggs had filed a similar bug when investigating moving Orca functionality from Gecko-based programs (Firefox, Thunderbird) to webkit-based programs (increasingly more on Gnome, such as Epiphany browser) which might have been flagged as duplicate by the webkit bot but not sure.

This does mean VoiceOver users need to use something else to get their focus directly to the inputs. The only good thing I can say is that VoiceOver users (who are pretty much stuck with Safari unless very recent versions have started working with Firefox/Mac) have always dealt with this in whatever way they do, and having the skip list above the form won't add any additional confusion for them. Also, VO users on iThings have some kind of web page rotor something-something... you probably know what it is, it lets iThing users jump around pages... which is accessible to everyone and VO works with it as well. VO users such as Marco Zehe have commented on the usefulness of it, and likely would be used by experienced iThing users to jump to the form itself, if not the particular input in question.