Who this is for

This guide is for anyone who manages a contact page: small business owners, web teams, agency developers, nonprofit staff, and municipal workers. If your site has a contact form, email address, or phone number, this checklist helps you catch common accessibility issues.

Form labels

Every input, select, textarea, and interactive form control needs a visible label that is programmatically connected. Without labels, screen reader users may not know what information goes where.

  • Use persistent visible labels: Always show the label outside the field. Do not rely on placeholder text alone — placeholder disappears when typing and is often poorly announced.
  • Connect labels programmatically: Use for and id, wrap the control in a <label>, or connect via aria-labelledby when a visible label already exists elsewhere.
  • Test with automation: Run the website accessibility checker with the Contact page preset. It detects unlabeled controls and placeholder-only fields.

See concrete examples: form label examples and the issue pages for unlabeled form controls and placeholder-only label risk.

Required fields

  • Mark required fields visibly: Use text such as "required" or an asterisk. Add aria-hidden="true" to visual-only asterisks so screen readers do not repeat the symbol.
  • Supplement with programmatic cues: Use required attribute or aria-required so assistive technology can announce the required state.
  • Explain the indicator: Add a short instruction near the form such as "Fields marked * are required."
  • Do not rely only on colour: A red outline or red asterisk alone is insufficient if colour is the only way someone knows the field is required.

See the required field indication issue page for detailed fix guidance.

Error messages

  • Make errors visible and clear: Show error messages next to the field that needs attention, in plain language. Explain what went wrong and how to fix it.
  • Associate errors programmatically: Use aria-invalid="true" on the field and aria-describedby pointing to the error message element so assistive technology can announce the error.
  • Test with a screen reader: Trigger validation errors and confirm the screen reader announces which field has the error and what the message says.
  • Consider an error summary: For longer forms, a summary of errors at the top with links to each problem field can help keyboard and screen reader users.

Learn more: error message association issue page.

Keyboard navigation and focus visibility

  • Tab through the full form: Every field, button, and interactive element should be reachable by Tab. Check that focus order matches the visual layout.
  • Visible focus indicator: Make sure the keyboard focus outline is clearly visible on every field and button. Do not remove focus outlines with outline: none unless you provide a better visible alternative.
  • No keyboard traps: You should be able to Tab into and out of every component including third-party widgets, date pickers, and autocomplete suggestions.
  • Focus after error: When a validation error occurs, move focus to the first error field or a summary of errors so keyboard users do not have to hunt for the problem.

Accessible names on submit buttons

  • Descriptive button text: Use "Send message," "Start application," or "Request callback" instead of generic "Submit" or "Click here." The button text should describe the action.
  • Icon-only buttons: If the submit button is an icon, use aria-label with a clear action description.
  • Avoid empty buttons: Check for <button aria-label=""> patterns that produce an empty accessible name.

See the button without accessible name issue page and button accessibility examples.

CAPTCHA and spam protection

  • Avoid visual-only CAPTCHAs: Image selection challenges, distorted text, and visual puzzles are inaccessible to many users. If you must use a CAPTCHA, provide an audio alternative or an accessible fallback.
  • Consider invisible approaches: Honeypot fields, time-based checks, rate limiting, and server-side spam detection can reduce spam without blocking real people.
  • Be transparent: If you use a spam filter, tell users what you do and provide an alternative contact method if the form fails.

Alternative contact methods

Not everyone can or will use your form. Provide alternatives visible on the page:

  • Email address: A visible email link that works with mail clients.
  • Phone number: A phone link that works with mobile and desktop calling.
  • Physical address or mailing address: Especially important for service-based organizations.
  • Business hours: If you offer phone support, include the hours of availability.

Third-party form widgets

Embedded contact forms from services like HubSpot, Mailchimp, JotForm, or Typeform often arrive with their own markup and behaviour:

  • Test the widget separately: Tab through the embedded form. Check that labels, errors, and keyboard focus work inside the iframe or injected widget.
  • Add a title to iframes: If the form is in an <iframe>, add a title attribute that describes its purpose, such as "Contact form."
  • Confirm error handling: Third-party widgets may not associate errors with fields or announce them to screen readers. Test this before launch.
  • Have a fallback: If the widget is unreliable, include a direct email link or phone number as a backup.

Using the contact page preset and developer tickets

SiteCheck Canada includes a Contact page preset that adds contact-specific review reminders to every scan report:

  1. Open the website accessibility checker.
  2. Select Contact page from the page type selector.
  3. Run the scan. The report will flag unlabeled controls, placeholder-only fields, missing error associations, missing autocomplete hints, and unnamed buttons.
  4. Switch to the Developer tickets view to see each finding as a ticket card with acceptance criteria, suggested owner, and effort hints.
  5. Copy or download the tickets and share them with your developer or team.

See the how to use your accessibility report guide for more on sharing and acting on findings.

What automated checks can help with

The SiteCheck Canada scanner detects code-level form issues including unlabeled controls, placeholder-only labels, empty button names, empty aria-labels, duplicate IDs, missing autocomplete hints, error fields without programmatic associations, missing fieldset legends, and required fields without visible cues. These checks give you a fast first pass, but they do not test the full interaction.

Use the website accessibility checker with the Contact page preset for automated detection. Browse the accessibility issue library for practical fix steps for each finding.

What still needs human review

Automated checks cannot verify whether your CAPTCHA is accessible, whether error messages are actually helpful, whether the keyboard focus order makes sense, whether the form works with your specific third-party widget, or whether labels, instructions, and error text are understandable to real users. Test these areas manually with a keyboard and screen reader.

For a broader understanding of what automation misses, read the what automated accessibility checkers miss guide.

Suggested workflow for contact page review

  1. Run the website accessibility checker with the Contact page preset.
  2. Fix any unlabeled form controls, placeholder-only labels, empty buttons, missing fieldset legends, and missing error associations.
  3. Confirm required fields are visible and not colour-only.
  4. Test the form with only a keyboard: Tab through every field, submit with errors, and confirm focus is visible.
  5. Test the form with a screen reader to confirm labels, instructions, and errors are announced.
  6. Check your CAPTCHA or spam protection for accessibility.
  7. Confirm alternative contact methods (phone, email, mailing address) are visible on the page.
  8. If you use a third-party widget, test the embedded form independently.
  9. Export developer tickets or the client summary and share with your team.

Related resources

Recommended next steps

Run the checker Scan your contact page with the contact page preset. Browse form examples See good and bad form label patterns. Print the checklist Work through every form field. Browse the issue library Fix unlabeled controls and form issues. Read what automation misses Know what still needs manual review.