Search topics
Form field help only on a help page or on hover
A returns form asks for an order number and doesn't say where to find it: the answer is in the help centre, or in a ? that only a mouse pointer can open.
The problem
People who don't know where their order number is have to leave the form to find out, and keyboard and screen reader users never get the help a mouse pointer can open.
A clothes shop's returns page, Start a return, asks for two things: the order number and the email used for the order, then Find my order. The form is drawn clean, a label over each box and nothing else, and to the shop the first label is plain: every order has a number, and the number is on everything the shop sends.
A visitor wants to send back a scarf they bought three weeks ago. They know their email. The order number they have never needed: it might be on a slip in the parcel, which went out with the packaging, or in an email somewhere. Nothing on the form says where it is or what one looks like. The only help on the page is the Help link in the site's header, which opens the help centre's front page: a search box and a list of common questions. "Where is my order number?" is the third. It says the number is in the subject line of the order confirmation email and on the packing slip, and gives an example, HL-482130. To read it, the visitor has left the form, and the article's Start a return link takes them back to it empty.
A second build of the same form puts that answer in a small ? beside the label, shown in a dark box while the mouse pointer rests on it. With a mouse, the help is one hover away. Tab goes from the order number box to the email box and never stops on the ?, and a screen reader reads the field as "Order number, edit text", with nothing after it.
Success criterion 3.3.5 Help is level AAA. It asks that context-sensitive help is available: W3C's Understanding page says such help lets people find out how to do something "without losing track of what they are doing", that people should be able to tell it exists, and that they should be able to get it "whenever they require it". It is needed only where the label doesn't say enough. "Order number" says what to enter, but not where to find it, and many shops answer that question in help centre articles of their own.
The header's Help link isn't help with this form. W3C's technique for a help link, G71, asks for a link on the page to help about filling in that page's form, or a link beside each field to help about that field. The help centre's front page is neither: getting the answer from it takes a search or a scan of the list, another page, and a way back to the form. The form gives no instructions at its start either, another of the techniques W3C lists for forms that ask for text (G184).
The ? puts the right words beside the field, but only for a resting mouse pointer. It is a span, which takes no keyboard focus; the CSS shows its text on :hover and nowhere else; and while its text is hidden with visibility: hidden, screen readers leave it out. To anyone using a keyboard or a screen reader, the field has no help, so they can't get it whenever they need it. W3C lists help in a title attribute only as an advisory technique for 3.3.5, not a sufficient one; form field labels and hints only in a title tooltip shows why a tooltip of that kind fails the same people.
The help matters most where a form asks for something people keep elsewhere: an order, account, policy or membership number, a reference from a letter, a code from an email. Those are also the forms people fill in when something has gone wrong, a return, a claim or a missed delivery, when patience is short. On a phone, leaving the form for the help centre means a new page on a small screen, and the way back is the browser's Back button or a link that starts the form again.
3 of 10 groups affected
- No vision (affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited language, cognitive and learning abilities People with memory, attention or reading difficulties are the ones the help is for. Sent to a help centre to search, they lose their place in the return, and some never come back to the form.
- Limited manipulation Keyboard and switch users can't reach the ?, because it takes no focus, and every page in the help centre costs them more presses than it costs a mouse user.
- Without vision Moving by Tab, a screen reader skips the ?, and its text stays hidden until a pointer rests on it, so the field is "Order number, edit text" and nothing more.
Each field has a label tied to it, and the Help link has a name, so axe, ANDI and every label check pass the form. Whether a field needs help depends on what people know and keep, and no rule can tell that. The EaseWeb audit hovers over the tooltips it finds to check how they behave (1.4.13). It also hovers over each small icon beside a form field that the keyboard can't reach and that holds hidden text, and when the hover shows that text and focus on the field doesn't, it sends it to a person as a lead: whether the field needs that help, and whether the page gives it some other way, takes a person to judge. A tooltip that a script adds to the page on hover isn't looked for. Nothing finds the help centre form of the failure, because no scan can tell that an article two pages away answers the form's question. Asked to add help to a field, a code assistant can reach for a tooltip on an icon, which is the second Before when the icon is a span.
Try it
Return a scarf: find out where its order number is, without leaving the form.
Broken 1: nothing beside the field says where the order number is. Type your email, find the answer through Help in the header, then come back with the answer’s Start a return link. What happened to your email?
Broken 2: rest the mouse pointer on the ? to read the answer. Then put the mouse aside and Tab through the form: does focus ever stop on the ?, and what does a screen reader hear on the field?
Apply a fix. Look for the answer again, with the mouse and then with Tab alone: is it beside the field, and what does a screen reader hear?
The fix
Put the help beside the field it is for.
The help only in the help centre
<header> <a href="/">Hollis</a> <a href="/help">Help</a></header><main> <h1>Start a return</h1> <form method="post" action="/returns"> <label for="order">Order number</label> <input id="order" name="order" type="text"> <label for="email">Email used for the order</label> <input id="email" name="email" type="email" autocomplete="email"> <button type="submit">Find my order</button> </form></main>What is wrong3 points
- Nothing beside Order number says where to find it or what one looks like.
- The only help is the Help link in the header, which opens the help centre's front page.
- Reading the answer there means leaving the form.
A hint under the label
<header> <a href="/">Hollis</a> <a href="/help">Help</a></header><main> <h1>Start a return</h1> <form method="post" action="/returns"> <label for="order">Order number</label> <p id="order-hint" class="hint">It's in the subject line of your order confirmation email, and on your packing slip, for example HL-482130.</p> <input id="order" name="order" type="text" aria-describedby="order-hint"> <label for="email">Email used for the order</label> <input id="email" name="email" type="email" autocomplete="email"> <button type="submit">Find my order</button> </form></main>How it is fixed3 steps
- Print the help under the label, in the words of the help centre's answer: where the number is, and what one looks like.
- Tie it to the field with
aria-describedby, so a screen reader reads it after the field's name and role. - Take out the ?, if there was one: the help is on screen for everyone now.
This fixes both Befores and passes 3.3.5. The hint is in the shop's grey, #4a5560, at 7.61:1 on white. Keep it to a line or two: a screen reader reads all of it each time focus lands on the field.
All three pass 3.3.5. Use the hint when the help is a line or two, as here: it is on screen with nothing to open, and read with the field. Use the details element when the help is longer, or only some people need it, so the form stays short for everyone else. Use the link only when the help can't be cut down to fit the form, such as a long article other pages link to as well, and print the one line people need beside the field too when you can.
If the design keeps a ? beside the label, make it a button that opens the help and closes it again, never a span that shows it on hover. Tooltips that vanish on approach and can't be dismissed builds one as a toggletip. Each such button is a stop of its own in the Tab order, and people hear the help only if they open it, so for help most people may need, a hint printed on screen is simpler.
Accept the order number the way people copy it: with or without HL-, a #, or spaces. Then the example in the help shows what to look for, not a rule to follow. When a field does accept only one format, say so on screen, in the label or the hint: that is 3.3.2 Labels or Instructions, at level A, and form field labels and hints only in a title tooltip covers it.
Write the help once and use it in both places. When the hint and the help centre's answer come from the same piece of content, they stay in step when the confirmation email or the order number changes.
A placeholder is no place for help. It disappears as soon as people start typing, which is when they want to compare what they typed with the example. When the number isn't found, the error message beside the field can say again where to look; see form errors that don't say how to fix them.
The site's own Help link still matters for everything the form doesn't answer. Keep it in the same place on every page, as help links that move from page to page explains.
Design ideas
Help can sit quietly beside a field, as long as everyone can reach it.
Four more ways to draw the help for the order number. Try each with the mouse, then with Tab and the keyboard alone: two keep the help in reach, and two take it away just when it is needed.
In the design file
- Write the help under each field that needs it, in the words people will read, saying where the value is and what it looks like.
- If the help sits behind a button, draw the button’s focus ring, and the help open, pushing the field down rather than covering it.
- Draw the help on a 390-pixel phone screen, under its field, not in a column beside the form.
- Write the help text’s contrast beside it, 4.5:1 or more against its background, such as 7.61:1 for the grey on white.
Passes
Look for it in the subject line of your order confirmation email:
Hollis Your order HL-482130 is confirmed
A drawing of where the number is A line drawn like the email itself, the sender in bold and the number on a soft yellow highlight (12.65:1), shows what to look for in the inbox. The sentence above it says the same, in #4a5560 at 7.61:1, so the drawing is never the only way to the answer.It's in the subject line of your order confirmation email, for example HL-482130.
A ? that opens the help in place The round ? keeps the label line clean, but it is a button: Tab stops on it, and Enter or a click opens the help under the label, on the cream #f6f1ea at 6.77:1, pushing the field down instead of covering it. A second press, or Escape, closes it again.
Fails
- The help as the placeholderWCAG 3.3.5 Grey words inside the box look tidy and say the right thing, but they are gone at the first key press, just when people check what they typed against the example.
Need a hand? Visit our Help Centre →
A friendly card that links to the help centreWCAG 3.3.5 A warm card with a life ring looks helpful, but its link opens the help centre’s front page, where the answer is a search away and the form is left behind. It is help with the site, not with this field.
Verify the fix
4 checks, no mouse.
Test with: Keyboard, Screen reader, Zoom
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat when fields are added, and when what people are asked for, such as the order number's format, changes.
How screen readers handle aria-describedby
Limits
This is a starting pattern, not a guarantee for every application. 3.3.5 is level AAA, beyond the A and AA levels that EN 301 549 and Section 508 require, but W3C's Understanding page names the people such help serves: people with writing, reading and intellectual disabilities, and older people who find typing hard. This guide covers help with one field: not the label itself (vague form labels that don't say what to enter), not how a tooltip behaves once it opens (tooltips that vanish on approach and can't be dismissed), and not where the site's help link sits from page to page (help links that move from page to page). Which fields need help depends on the people who fill in the form and what they have to hand, so test it with them.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
EaseWeb service
Fixed it? Keep it from coming back.
I turn guides like this one into rules your coding agents follow and checks your CI runs. Then I retest by hand with a keyboard and screen readers, periodically.