How to use this checklist
Print this page and work through every form on your site. Test with keyboard only and a screen reader if possible. This checklist is a practical review tool, not a legal compliance or WCAG conformance audit.
Labels and accessible names
- Every input, select, and textarea has a persistent visible label
- Labels are programmatically connected (for/id, wrapping label, or aria-labelledby)
- No field relies on placeholder text as its only label
- Icon-only buttons and inputs have clear accessible names (aria-label)
- No element has an empty or broken aria-label
Required field indicators
- Required fields are clearly marked (text, asterisk with aria-hidden, or both)
- Required indicator is not colour-only
- An instruction near the form explains what the required indicator means
- Required fields use the required attribute or aria-required for assistive tech
Error messages
- Error messages are visible and appear next to the relevant field
- Error fields use aria-invalid and aria-describedby pointing to the error text
- Errors are announced by screen readers on submission
- Error text explains what went wrong and how to fix it in plain language
- Focus moves to the first error field or a summary of errors after validation fails
Fieldset and legend for groups
- Related radio buttons are inside a fieldset with a legend
- Related checkboxes are inside a fieldset with a legend when they share a purpose
- Screen reader testing confirms the group label is announced correctly
Autocomplete hints
- Name fields have autocomplete hints (name, given-name, family-name)
- Email fields have autocomplete="email"
- Phone fields have autocomplete="tel"
- Address fields have appropriate autocomplete values (street-address, postal-code, etc.)
Keyboard and focus
- Every form field, button, and interactive element is reachable by Tab
- Focus order follows the visual layout
- Focus indicator is clearly visible on every field and button
- No keyboard trap — can Tab into and out of every component
- Submit button is clearly labeled with an action description
- Form can be submitted with the Enter key
Screen reader testing
- Each field label is announced correctly when the field receives focus
- Required state is announced
- Error messages are announced after validation failure
- Group labels (fieldset legends) are announced with the grouped fields
- Instructions and hints are announced appropriately
CAPTCHA and spam protection
- CAPTCHA is not visual-only; audio alternatives or fallback methods exist
- Invisible or non-visual spam protection is considered (honeypot, time check, rate limit)
- If spam filter is used, alternative contact methods are provided
Alternative contact methods
- Email address is visible on the page as a mailto link
- Phone number is visible and linked for mobile dialling
- Physical or mailing address is visible if relevant
- Business hours are noted if phone or in-person contact is offered
Third-party form widgets
- Iframe embed has a descriptive title attribute
- Tab through the embedded form confirms all fields are reachable
- Error messages inside the widget are announced by screen readers
- A fallback contact method is visible if the widget is unreliable
Submit button and form action
- Submit button text describes the action (“Send message,” “Start application”)
- Button is not empty, hidden-only, or CSS-background-only
- Confirmation message is announced to screen readers after successful submission
Print-friendly layout
- Form is still understandable when printed (labels, instructions visible)
- Submitted data format is clear in printed confirmation or receipt
Run the website accessibility checker with the “Contact page” preset for automated detection of unlabeled controls, placeholder-only labels, missing error associations, and more.