Accessible onboarding: a checklist for signup and error recovery
Review labels, keyboard focus, dialogs, authentication, and error recovery with a practical onboarding checklist grounded in W3C guidance.
In this article
Review accessible onboarding across the whole task: entering information, moving between steps, authenticating, correcting errors, and recognizing success. Test keyboard operation and relevant assistive technologies on both successful and failed attempts. The checklist below turns those paths into specific checks, with prompts for recording the environment, observed barrier, and repair to verify.
A signup form can have labeled fields and a visible submit button, then become unusable the moment someone makes a mistake. The error appears outside the current view. Keyboard focus disappears. Correct answers are cleared. A screen reader announces nothing.
Reviewing only the empty form misses the part where the user most needs help.
Begin with the controls people actually operate
Use real form controls where they fit the task. Each input needs a label that communicates its purpose and is associated with it in code. W3C’s labeling tutorial explains the relationship between the label’s for attribute and the input’s id, along with other labeling approaches. Text that happens to sit near a field is not necessarily its accessible label.
Keep the visible label available after typing. A placeholder that disappears takes context away just when someone may want to check their answer. For a field with a specific format, show the requirement before submission. “Workspace address” needs more explanation than “Workspace name” if the first accepts only certain characters or becomes a public URL.
W3C’s form instructions guidance recommends identifying required inputs and explaining expected formats. Put a short constraint beside the relevant field and associate it programmatically where needed. Do not hide a necessary instruction in a hover-only tooltip.
Copy is part of this work. “Invalid input” gives someone little to act on. “Use letters, numbers, or hyphens in the workspace address” tells them how to repair the answer. Match that advice to the actual validation rules so the interface does not send them through repeated guesses.
Follow focus past the first page
Set the mouse aside and complete the flow using the keyboard. Can you reach every required action, see where focus is, and operate the control? Test backward movement too. A journey that only works in the intended forward order may strand someone who needs to edit an earlier answer.
WCAG’s Keyboard criterion requires functionality to be operable through a keyboard interface, with an exception for functions that depend on the path of movement. For ordinary signup controls, file-selection buttons, and setup choices, keyboard operation should be part of the implementation from the start.
Being reachable is only one check. A sticky footer can cover the focused button. A cookie notice can obscure a field as the page scrolls it into view. WCAG 2.2’s Focus Not Obscured (Minimum) requires that a focused component not be entirely hidden by author-created content. Keeping it fully visible is a stronger design target and easier for people to use.
After navigation or a dynamic update, verify where focus goes. Avoid moving it merely because the user selected an option. Where a new step replaces the old one, provide enough orientation to understand the new content. Screen-reader testing is necessary here: looking at the screen cannot tell you what was announced.
Treat the welcome tour as another interface to test
An accessible main form does not excuse an inaccessible overlay covering it. If you add a modal, it acquires its own keyboard and focus responsibilities.
The W3C modal dialog pattern describes moving focus inside when the dialog opens, keeping keyboard focus within the modal while it is active, and usually returning focus to the invoking element when it closes. Escape closes the dialog in the pattern. Its accessible name and visible close control also need attention.
Test the actual interaction. Can someone dismiss the welcome tour without completing it? Does focus return to useful content, or to an element that no longer exists? Is the page behind the modal genuinely unavailable while the modal is active? Adding an ARIA attribute alone does not implement those behaviors.
For simple instructions, inline text may remove the need for a dialog altogether. Put the explanation next to the task if that gives users enough help. Fewer overlays mean fewer transitions to get right.
Make failure discoverable, then make repair possible
Submit the form with missing and malformed answers. Watch for two separate outcomes: whether the person can discover that submission failed, and whether they can reach and correct each problem.
W3C’s user notification guidance covers error summaries, associations between errors and controls, and notifications for dynamic updates. A summary can orient the user across several errors; a specific message beside the field explains the repair. Neither should rely on red borders alone.
Retain valid answers when submission fails. If the workspace address is taken, the person’s name and other correct details should not disappear. Preserve the offending value too when that helps them edit it. Re-entering a whole form makes an error much more expensive for anyone using slower input methods.
WCAG 2.2’s Redundant Entry criterion requires information already entered or supplied within the same process to be auto-populated or available to select, with exceptions for essential re-entry, security, and information that is no longer valid. It does not itself require saving information across separate sessions. Persistent drafts can still be a useful product decision, but keep that distinct from what this criterion requires.
Include the login challenge in the journey
A usable signup form can lead straight to a verification step that demands manual transcription. Test password-manager filling, pasting a password, and pasting a complete verification code. If the code is displayed as separate boxes, check that a paste fills the code correctly rather than just the first digit.
W3C’s Accessible Authentication (Minimum) explanation describes how assistance such as password managers and copy-and-paste can avoid forced recall or transcription. The criterion applies to authenticating existing users; creating a username or initiating an account is outside its scope. The same support for password managers and pasting is still useful during signup. Each step in a multi-step authentication process must meet the criterion. An accessible password field does not compensate for an inaccessible second factor.
Inspect recovery as well: an expired link, an incorrect code, or a changed email address. Error messages should distinguish what can be retried from what requires a new challenge. Preserve the intended destination after successful authentication so the person can continue the task they came to do.
Finish the review with a real result
For a workspace signup, continue until the participant can identify that the workspace exists and use it. Account creation, email verification, and readiness to work can be different states. The confirmation should describe the state actually reached.
Run the journey with relevant assistive technologies and with people who use them. Automated checks can find some markup issues; they cannot establish that the whole task is understandable and operable. Record the specific environment and path you tested rather than declaring the product universally accessible after one pass.
The repair worth shipping may be small: a persistent label, a useful error summary, a corrected focus return, or a code field that accepts paste. Its significance is concrete. Someone who was stopped can continue.
Checklist: follow one onboarding task through success and failure
Choose a realistic destination, such as creating a workspace and opening its first project. Record the starting account state, device, browser, assistive technology, and date. Work through the relevant checks below and mark each works in the tested path, barrier found, not tested, or not applicable. Explain any item you skip.
| Check | Try this | Record what happened |
|---|---|---|
| Labels | Navigate through inputs with a screen reader, then type into them. Compare the announced names with the visible labels. See W3C’s labeling guidance. | Which control was unclear, and what name did it announce? |
| Instructions | Attempt a field with a format restriction and one optional field. Check the explanation before submission. See form instructions. | Could you find the rule and continue without supplying optional information? |
| Keyboard operation | Complete the task using the keyboard, including backward navigation, file selection, and custom controls. See the Keyboard criterion. | Where, if anywhere, did progress require a pointer? |
| Visible focus | Move through the flow with its sticky header, footer, and notices present. See Focus Not Obscured. | Could you locate the focused control, and did another element cover it? |
| Optional dialogs | Open and dismiss any welcome modal using the keyboard. Check its accessible name, focus containment, Escape behavior, and return destination against the modal dialog pattern. | Could you leave the lesson and resume the task at a sensible place? |
| Errors | Submit missing and malformed answers. Find the failure message, reach each affected control, and repair it. See user notifications. | What was announced, which repair was explained, and could you complete it? |
| Preserved answers | Correct one failed field and continue through later steps. Check whether valid information remains available. See Redundant Entry. | Which answers had to be entered again, and was there a necessary reason? |
| Authentication | Use a password manager and paste a password or complete verification code where those methods apply. Test every authentication step. See Accessible Authentication. | Which step required avoidable recall or transcription, or blocked the assistance being used? |
| Recovery | Follow an expired sign-in link or enter an incorrect code, then request the supported recovery option. | Could you understand the problem, retry safely, and retain the intended destination? |
| Success | Finish the task and inspect its confirmation using the same assistive technology. W3C’s notification guidance covers success feedback as well as errors. | Could you identify what was completed and reach the resulting workspace or project? |
The linked guidance defines the relevant requirements and patterns. This checklist also includes practical task checks; it is not a complete WCAG conformance assessment. In particular, the Redundant Entry criterion concerns information within the same process, and Accessible Authentication concerns authentication rather than initial account creation. The earlier sections explain those boundaries.
Turn a barrier into a repair someone can verify
Copy these prompts for each problem:
- Task and starting point: What was the person trying to accomplish, and what state was the account in?
- Environment: Which device, browser, input method, and assistive technology were used?
- Action and observed result: What did the person do, and what happened or was announced?
- Consequence: Could they continue independently, recover with extra work, or not continue?
- Proposed repair and owner: What behavior needs to change, and who will make that change?
- Follow-up check: Which exact path will you repeat, and what observable result will show the repair worked?
An illustrative finding might read: “After submitting a workspace name that is already taken, focus remains on the submit button and the new error is not announced in the tested browser and screen reader. The participant cannot identify why the page has stayed still.” A useful follow-up repeats that submission and verifies that the failure can be discovered, the named field can be reached, and correcting it allows the task to finish with valid answers preserved.
Use the record alongside sessions with people who use the relevant assistive technologies. A completed checklist documents the paths examined; the next product change can introduce a new barrier, so repeat the affected journey when its controls, messages, or navigation change.
For boards and visual builders, review alternatives to dragging in the first task alongside the keyboard and focus checks above.
Sources
- W3C WAI: Labeling Controls.
- W3C WAI: Form Instructions.
- W3C WAI: User Notification.
- W3C: Understanding Keyboard.
- W3C: Understanding Focus Not Obscured (Minimum).
- W3C WAI: Modal Dialog Pattern.
- W3C: Understanding Redundant Entry.
- W3C: Understanding Accessible Authentication (Minimum).
