Form field help text placement
Hi there,
We have a HTML form with numerous fields and field types. I'm wondering what the best placement for field help text would be.
I.E. For a "Date of Birth" field, the help text "Please enter your date of birth (dd/mm/yyy)" would pop up in a little box to the right of the field for visual users. But for blind users using a screen reader, should I place the text underneath the actual field (forcing the user to read each one I guess???) or keep all help text at the bottom of the form/page (so the user to choose whether they read it or not.)
Many thanks,
Jonathan
Share: 
Take a look at http://www.accessifyforum.com/viewtopic.php?t=14018
There may well be other useful threads if you search.
Web Developer at Big Lottery Fund
Share:
| jonthomas83 wrote: |
|
I.E. For a "Date of Birth" field, the help text "Please enter your date of birth (dd/mm/yyy)" would pop up in a little box to the right of the field for visual users. But for blind users using a screen reader, should I place the text underneath the actual field (forcing the user to read each one I guess???) or keep all help text at the bottom of the form/page (so the user to choose whether they read it or not.) |
Why would you want to have 'Please enter your date of birth' when that's already patently obvious? That's not help that's clutter. Keep it simple and don't go for information overload.
Design, development and marketing for the web.
Edge Three Sixty Ltd: Web Design Liverpool
Share:
| philsmears wrote: | ||
Why would you want to have 'Please enter your date of birth' when that's already patently obvious? That's not help that's clutter. Keep it simple and don't go for information overload. |
Really?!?!
Honestly, I never thought anyone would mention that! lol. It was just an example. I know we'd never use that in a real world scenario, it was the easiest thing to think of when writing the post!
Share:
| jonthomas83 wrote: |
|
Honestly, I never thought anyone would mention that! lol. It was just an example. I know we'd never use that in a real world scenario, it was the easiest thing to think of when writing the post! |
Are you going to provide an example of when you think the help text would be useful and the label inadequate? My point is that some people think that accessibility is about going to great lengths adding attributes and code to make something more accessible when quite often it's unecessary and the reverse is the case.
Design, development and marketing for the web.
Edge Three Sixty Ltd: Web Design Liverpool
Share:
Phil, your point is an excellent one but I do have an example where another solution was necessary.
A client had a User form and one of the fields was for a password. Like any other system, there were password complexity rules that the original form displayed in a list before the field and label. I think the list might have had 6-8 bullets, far too much information for a label. We went with the link-within-the-label solution so the user had the option of jumping to the help text. At the end of the help text we had another link to jump back to the input field.
That form also had password reset question and answer fields and the client wanted a list of example questions. Same solution, link in the label to a block outside the form, another link back to the field.
One could argue that maybe those fields should have been moved to another page (sometimes a change like that is out of scope). Or that the help text should be placed before the form (but then the user has to remember all the information until he reaches the fields in question).
Of course, all that was a while ago and maybe there is a simpler solution I didn't think of!
Share:
I remember life without passwords...
I wonder how screen readers handle links within a label. Anyone?
Design, development and marketing for the web.
Edge Three Sixty Ltd: Web Design Liverpool
Share:
Given:
| Code: |
|
<label for="fname">First Name (<a href="#h">help</a>)</label <input id="fname".../> ... <div id="h">Some text <a href="#fname">back</a></div> |
In NVDA the experience isn't perfect but it works. When the help link is focused it reads "first name help label help link" but doesn't announce that it's for a field (since the field isn't yet focused). The link can be activated, the help text is read, and the Back link returns focus to the field. When returning to the field, the label is not announced but I would hope that given the sequence of events the user would understand what control they're now on.
Not perfect, I know. I have a hard time figuring out how else I'd do it so that the help text is still optional for every user. That pretty much means it can't reside in the LABEL. Maybe JS/ARIA would work.
Share:
I always thought you shouldn't use hyperlinks within a label? As it interferes with users clicking on a label to select a field, which might be very useful for those with motor coordination difficulties or who can't see the screen very well. Probably most critical with a checkbox, as the checkbox itself is awfully small compared to label. Then sticking a hyperlink in it could take the user away from where they want to be.
Do people think this could be a problem?
Could you perhaps have "as described above" in the label, and then have text immediately preceding the field with the explanation, and perhaps even contain link to a pop up?
Share:
If you wrapped the entire label text in a link, then yes I'm sure it could cause problems. Here, the link is only a portion of the label text. Sighted users still have plenty to click on to focus the field. SR users get an extra tab stop for the link.
It works, but admittedly it's not perfect. And used excessively it's sure to degrade the user experience. But if there's actually guidance discouraging links inside labels I'd be interested to see it.
Could you post a code sample of your suggestion? The problem with text immediately preceeding the field that isn't inside a label is that it will likely get skipped by screen readers. Though now I'm wondering if using TABINDEX=0 on that info would get around that. I don't have time to test that right now but will post back if I do.
Share:
Sorry for the late reply. I consulted a friendly screen reader user, and she tells me while she can tab to a label, she can't tab to a hyperlink inside a label... she uses JAWS 10, I believe.
Has anyone else tested this with a screen reader?
Share:
This is something like how I've coded a help link in the past
| Code: |
|
<div id="Terms" class="form-section"> <p> By completing this form, you agree to comply with our <a href="/Communications/uat/XmleFormTests/Pages/TandC.aspx" target="_blank">Terms and Conditions (new window)</a>. </p> <p class="check-box"> <input type="checkbox" id="MustTick" name="MustTick" value="Agree" aria-required="true" /> <label id="label_MustTick" for="MustTick" onclick="">* I agree with the Terms and Conditions described above</label> </p><!-- onclick makes labels clickable on iPhone --> </div> |
Share:
Hi Rachael,
Are you sure about Jaws 10 not being able to click on links inside labels?
I'm certain I had that checked a few years ago and it worked but was dependant upon what mode the user is in.
Nice tip on making labels clickable on iphones.
mike foskett
<marquee><blink><work> webSemantics </work><rest> 2kool2 </rest> & <play> bangers & mashed </play></marquee></blink>
Share:
Rachael,
Your friend's account of JAWS' behavior is confusing to me. First, labels aren't in the tab order, fields are. You tab to the field and the SR announces the associated label. Adding a link to the label should add a focusable tab stop. Forgetting screen readers, pressing tab should shift focus to every focusable element on the page. This is how the browser works.
That said, I don't have JAWS to test with anymore but I can't imagine it would interfere with tab order.
Share:
Would placing the title attribute with help text within the input field be acceptable here?
For example:
<label for="date">Date</label>
<input title="Date - Please enter date as mm/dd/yyyy" name="date" id="date" type="text" />
Using JAWS, when I tab to the field it reads the info in the title attribute. If this is acceptable, then you could visually put the mm/dd/yyyy help text wherever it looks best visually.
I've been away from accessibility for a little while now, but I seem to recall that you can use the title attribute this way within forms in some cases. However, I also believe JAWS has a user setting that determines whether or not it reads what's in the title attribute.
Here's a reference: http://www.w3.org/TR/WCAG20-TECHS/H65.html
Yes, I understand that the rule is written as "Using the title attribute to identify form controls when the label element cannot be used", and in this case it can be used. However, if it is an acceptable solution in some cases, maybe it could be leveraged in cases like help text. Just an idea.
FYI - placing the title attribute in the label tag does not appear to work.
Share: