An accessible settings page helps people understand, change, and confirm account, privacy, and security choices without relying on vision, precise pointer movement, or a particular input device. This WCAG-focused checklist covers information architecture, labels, toggles, keyboard behavior, validation, announcements, contrast, motion, and mobile interaction, with a repeatable audit workflow you can use before every settings release.
Overview
Settings screens are often treated as low-traffic utility pages, but they contain high-consequence controls: password changes, authentication methods, data-sharing choices, notification preferences, and account deletion. Accessibility problems in these areas can prevent users from protecting their account or expressing a preference.
Build accessibility into the settings page design rather than adding it during final QA. Start with a clear settings information architecture, use native HTML controls where possible, and make every state perceivable through text, structure, and programmatic relationships. A control should be understandable before interaction, operable with a keyboard or assistive technology, and followed by clear confirmation after a change.
Use this article alongside your product’s accessibility requirements and an appropriate conformance review. WCAG success criteria are useful checkpoints, but passing an automated scan alone does not establish that a privacy settings page or security settings UI works for real users.
For broader organization patterns, compare this checklist with the settings page information architecture guide and the privacy and security preferences center checklist.
What to track
1. Headings, landmarks, and navigation
Give the page one clear h1, such as “Account settings,” and use heading levels to identify major groups. Typical sections might include Profile, Notifications, Privacy, Security, and Billing. Do not use visual font size alone to communicate hierarchy.
Long settings pages benefit from a navigation landmark, such as a sidebar or tab list, but the navigation must remain understandable on small screens. Make the current section identifiable, and ensure the same information is available without relying only on color or position. If a tab changes content in place, implement the tab pattern consistently; if links load separate pages, use links instead of simulating tabs.
- Check that landmarks have useful accessible names when more than one landmark of the same type exists.
- Check that focus moves predictably when navigation changes the visible content.
- Check that the mobile layout preserves section names and does not hide essential controls behind an unlabeled menu.
2. Labels, descriptions, and group relationships
Every form control needs a programmatic label. A visible label is preferable to placeholder text because it remains available after the user enters a value. Supporting text should explain the consequence of a choice, not merely repeat its name.
For related controls, use a grouping structure. A set of radio buttons for “Who can see my profile?” should have a group label and an explanation. A group of notification checkboxes should identify the category and, where useful, explain delivery timing or scope.
<fieldset>
<legend>Profile visibility</legend>
<p id="visibility-help">Choose who can view your profile details.</p>
<label>
<input type="radio" name="visibility" value="private" aria-describedby="visibility-help">
Only me
</label>
<label>
<input type="radio" name="visibility" value="team" aria-describedby="visibility-help">
People in my workspace
</label>
</fieldset>3. Choose the right control pattern
The control should match the decision. A toggle is appropriate for an immediate on-or-off setting, while a checkbox is often better when several independent options can be selected. Radio buttons work when the user must choose one option from a small, visible set. Use a select menu when space is limited or the option list is longer. Do not use a toggle for a choice that requires a follow-up step without making that consequence explicit.
| Decision | Suitable pattern | Accessibility checks |
|---|---|---|
| Enable or disable one feature | Checkbox or switch | Expose its name and current state; explain whether the change saves immediately. |
| Choose one of several options | Radio group | Provide a group label, keyboard operation, and a clearly selected option. |
| Choose several independent options | Checkbox group | Label each option and identify any group-level explanation or error. |
| Choose from a long list | Select or searchable combobox | Make the input, expanded state, results, and selected value available to assistive technology. |
4. Accessible toggle settings UI
A switch must communicate three things: what it controls, whether it is on or off, and what happens when it changes. Do not rely on a green or gray track alone. If the setting has a meaningful security or privacy effect, place a short explanation beside it and state whether the change is immediate.
Native checkboxes are often the simplest implementation. If a custom switch is required, follow the appropriate ARIA pattern, expose its state with aria-checked, and support keyboard interaction without changing expected focus behavior. A custom control that looks like a switch but is announced only as “button” creates unnecessary uncertainty.
5. Keyboard focus and pointer alternatives
Tab through the complete account settings page using only a keyboard. Every interactive element should receive visible focus, and the focus indicator should remain distinguishable against the background. Avoid removing the browser’s outline unless a replacement is at least as clear.
Check for keyboard traps in dialogs, custom dropdowns, date pickers, and confirmation flows. When a modal opens, move focus into it, keep focus within it while it is active, and return focus to a sensible trigger after it closes. A user should be able to reach privacy controls and save or cancel actions without dragging, hovering, or using a mouse.
6. Errors, saving, and status messages
Settings forms need a clear model for saving. If changes are saved automatically, announce successful updates without interrupting unrelated work. If the page uses a Save button, keep the action easy to find and tell users whether the submission succeeded.
Errors should identify the affected field, describe what needs to change, and remain associated with that field. Put an overall error summary near the top when several fields are invalid, with links that move focus to each problem. Do not communicate an error only through a red border or an icon.
<label for="email">Recovery email</label>
<input id="email" name="email" aria-invalid="true" aria-describedby="email-error">
<p id="email-error" role="alert">Enter a valid recovery email address.</p>Use live regions carefully. A concise “Notification preferences saved” message may be useful after an asynchronous update, while announcing every keystroke can become disruptive. Test announcements with the screen readers and browsers used by your audience.
7. Contrast, text, and touch targets
Review text, icons, borders, focus indicators, disabled states, and selected states against their backgrounds. A control should remain understandable when color vision differs or when the display is viewed in high contrast or forced-colors modes. Pair status colors with text, icons, or structure.
On mobile, make controls comfortably tappable and keep labels close to their associated inputs. Do not require precise tapping on a tiny icon to reveal a security setting. Test zoom and text resizing: content should not overlap, disappear, or force users to scroll in two directions just to read a label.
8. Motion and authentication flows
Animated expansion, confirmation banners, and navigation transitions should respect a reduced-motion preference. Motion should not be the only cue that a section opened or a setting changed.
Security settings deserve an additional review. Password fields, one-time-code inputs, passkey prompts, device lists, and session-revocation dialogs should have clear instructions, labels, error recovery, and a keyboard path. Avoid making an accessible alternative weaker or less informative than the default flow.
Cadence and checkpoints
Run a lightweight accessibility check during every settings release and a deeper review on a monthly or quarterly cadence, depending on how often the area changes and how sensitive its controls are. Keep a small audit log so recurring checks reveal patterns rather than producing isolated bug reports.
Before each release
- Test the changed controls with keyboard navigation.
- Confirm labels, descriptions, states, and errors in the accessibility tree.
- Check focus after saving, validation, route changes, dialogs, and toast messages.
- Review mobile layout, zoom, orientation, and touch interaction.
- Run automated checks, then manually verify every reported issue and important path.
Monthly or quarterly review
- Walk through profile, notification, privacy, and security settings from a new-user state.
- Test at least one desktop browser and one mobile browser with a commonly used screen reader in your support matrix.
- Review new design-system components, custom controls, and third-party widgets.
- Recheck WCAG guidance, browser behavior, assistive-technology notes, and your product’s supported environments when they change.
Record the date, tested route, browser and assistive technology, control pattern, result, and any known limitation. This makes accessibility part of release evidence rather than an informal final opinion.
How to interpret changes
Not every accessibility change is a visual redesign. A small implementation change can alter the accessible name, focus order, announcement timing, or state exposed to assistive technology. Compare the user’s task, not just the screenshot.
When an audit finds an issue, classify it by impact and recovery. A missing label on a password or privacy control is more urgent than a minor spacing inconsistency because the user may not know what action is being taken. A focus loss after an auto-save may affect every update even if the setting itself appears correct.
Look for repeated causes:
- Pattern issue: several switches lack state announcements, suggesting a shared component problem.
- Content issue: labels are technically present but do not explain the consequence of a privacy choice.
- Flow issue: saving works, but the user receives no confirmation or is returned to an unexpected location.
- Environment issue: behavior differs across browsers, screen readers, zoom levels, or forced-colors settings.
Fix shared components and templates before making one-off page adjustments. A design system should include accessible versions of labels, help text, errors, switches, radio groups, dialogs, status messages, and focus states. For implementation patterns, the React settings page tutorial can complement this audit by showing how form state and validation are organized.
When to revisit
Revisit this checklist whenever you add a privacy choice, change authentication, introduce a custom settings component, alter auto-save behavior, or reorganize settings navigation. Schedule a broader review monthly or quarterly so dormant pages do not fall behind the rest of the product.
Start each review with three real tasks: change a notification preference, update a security control, and modify a privacy setting. Complete each task by keyboard, at a mobile viewport, with zoom or text enlargement, and with a screen reader where available. Confirm that the user can identify the control, understand its current state, make the change, recover from an error, and verify that the change was saved.
Finally, update the audit log when browser support, assistive-technology behavior, WCAG guidance, or your product’s settings architecture changes. An accessible settings page is not a one-time deliverable; it is a maintained part of account safety and user control. For a reusable starting point, pair this checklist with the settings page template and component checklist.
