Form validation and error messages
Help users to avoid making errors, and to understand and fix them when filling out forms or input components.
On this page
Overview
What you need to do
When user input is validated and detects errors, clearly identify which fields or inputs have problems and provide specific suggestions for fixing them. Error messages must be available to screen readers and other assistive technologies, not just shown visually.
Also check out our guidance on Form labels and instructions — Knowledge Area: Mobile applications.
Meeting the Web Accessibility Standard
When a form automatically detects an input error, identifies which field has the error and describes the error in text, it meets WCAG 2 Success Criterion 3.3.1 Error Identification (Level A).
When a form detects an input error, can suggest how to fix it, and those suggestions are shown to the user (unless showing them would be a security risk), it meets the WCAG 2 Success Criterion 3.3.3 Error Suggestion (Level AA).
Why this matters
Form errors are among the most frustrating barriers for people using assistive technologies. When validation messages aren’t properly communicated, users can’t understand what went wrong or how to fix it, preventing them from completing essential tasks like applying for services, making purchases, or accessing information.
When this applies
When you need error identification
- Buttons and controls: All tappable elements including icon buttons
- Form elements: Input fields, checkboxes, radio buttons, toggles
- Interactive images: Clickable photos, thumbnails, image buttons
When you need error suggestions:
- Format errors: Provide the correct format (e.g., “Enter phone as (04) 123-4567”)
- Required fields: Explain what information is needed
- Invalid entries: Suggest valid alternatives when possible
When suggestions are not needed:
- Security fields: Password requirements that would reveal security information
- Sensitive data: Where suggestions might compromise privacy
Design
Checklist for accessible form validation
- Use clear, specific error text (not just “Invalid”).
- Combine colour with icons or text indicators.
- Position error messages near the relevant field.
- Ensure errors remain visible at device’s highest zoom setting.
- Use consistent error styling throughout the app.
- Provide progress indicators for multi-step forms.
- Include success confirmations when errors are fixed.
- Consider whether inline error validation or validation on submit, or both, is best.
Design resources
For web-oriented guidance on designing accessible form validation and error messages that’s also applicable to mobile, read:
- Errors and Validation — Best Practices For Mobile Form Design — Smashing Magazine
- Provide easily identifiable feedback — Designing for Web Accessibility — W3C
- Recover from validation errors — GOV.UK Design System.
Development
iOS implementation
For technical documentation on implementing accessible error messages and announcements that meet WCAG, read:
- Success Criterion 3.3.1 Error Identification — Appt
- Success Criterion 3.3.3 Error Suggestion — Appt.
For sample code to notify users with spoken announcements, see Accessibility Notifications — iOS SwiftUI Accessibility Techniques — CVS Health — GitHub.
For complete guides on iOS accessibility from Apple Developer Documentation, read:
Android implementation
For technical documentation on implementing accessible error messages and announcements that meet WCAG, read:
- Success Criterion 3.3.1 Error Identification — Appt
- Success Criterion 3.3.3 Error Suggestion — Appt.
For a complete guide on Android app accessibility, see Make apps more accessible — Android Developers.
Testing
Quick test
These quick steps will help you verify that form error messages are identified visually and programmatically, and provide helpful guidance on how to correct the errors.
- Turn on your device’s screen reader (VoiceOver on iOS, TalkBack on Android).
- Navigate and submit the form without entering any data — are required fields identified?
- Fill out a form with invalid data — are errors regarding expected input values or formats announced clearly?
- Check error message content — do they explain what’s wrong and how to fix it?
- Test error timing — are errors announced when they appear? If the user tries to fix an error but makes a new one, is the new error announced?
- Verify error clearing — are users notified when errors are fixed?
- Test with external keyboard — are errors raised as keyboard users navigate through the form compared with touch users?
Testing resources
These tools and guides help you validate form accessibility across different platforms and assistive technologies.
- iOS — Accessibillity Inspector — Apple Developer Documentation
- Android — Accessibility Scanner — Android Accessibility Help
- Android — axe Accessibility Analyzer — Deque Systems — Google Play.
How to use a keyboard and switch with iOS
- Keyboard Access for iOS — Appt
- Intro to Switch Control on iPhone — Apple Support
- Switch Control for iOS — Appt