Accessibility Checklist for Contact Forms

Ensure your contact forms are usable by everyone, including people using assistive technology.

Why Accessibility Matters

Legal Requirements

Many jurisdictions require websites to be accessible:

• ADA (Americans with Disabilities Act)
• WCAG 2.1 Level AA compliance
• Section 508 (US federal agencies)
• European Accessibility Act

Moral Imperative

15% of the world's population has some form of disability. Making your contact form inaccessible means:

• Lost business opportunities
• Excluded potential customers
• Reduced reach
• Poor user experience for many

Business Benefits

Accessible forms provide better UX for everyone:

• Clearer labels help all users
• Better error messages reduce frustration
• Keyboard navigation helps power users
• Mobile-friendly benefits all devices

Core Accessibility Requirements

1. Labels and Form Fields

Requirement: Every input must have a visible, associated label.

Good:

<label for="name">Your Name:</label>
<input type="text" id="name" name="name" required>

Bad:

<!-- No label -->
<input type="text" name="name" placeholder="Your Name">

<!-- Label not associated -->
<label>Your Name:</label>
<input type="text" name="name">

Why it matters:

• Screen readers announce the label
• Users know what to enter
• Clicking label focuses input
• Clear purpose for each field

How SupportRetriever handles this:

• All fields have proper labels
• Labels are visible (not hidden)
• ID/for attributes properly linked
• No placeholder-only fields

2. Required Field Indicators

Requirement: Clearly mark required vs optional fields.

Good:

<label for="email">
  Email Address <span aria-label="required">*</span>
</label>
<input type="email" id="email" name="email" required aria-required="true">

<label for="phone">
  Phone Number <span>(optional)</span>
</label>
<input type="tel" id="phone" name="phone">

Bad:

<!-- No indication if required -->
<label for="email">Email</label>
<input type="email" id="email" name="email" required>

Why it matters:

• Users know what's mandatory
• Reduces form abandonment
• Screen readers announce requirements
• Prevents submission errors

How SupportRetriever handles this:

• Required fields marked with asterisk
• aria-required="true" attribute
• Optional fields explicitly labeled
• Consistent styling for required fields

3. Error Messages

Requirement: Errors must be clear, specific, and programmatically associated with fields.

Good:

<label for="email">Email Address</label>
<input 
  type="email" 
  id="email" 
  name="email" 
  aria-invalid="true"
  aria-describedby="email-error"
>
<span id="email-error" role="alert">
  Please enter a valid email address (e.g., name@example.com)
</span>

Bad:

<!-- Generic error at top of form -->
<div>Please fix errors</div>

<!-- Field turns red but no explanation -->
<input type="email" style="border-color: red;">

Why it matters:

• Users know exactly what's wrong
• Screen readers announce specific errors
• Reduces frustration
• Faster error recovery

How SupportRetriever handles this:

• Errors appear next to fields
• Specific error messages
• aria-invalid and aria-describedby
• Visual and programmatic error indication

4. Error Summary

Requirement: Provide summary of all errors at form submission.

Good:

<div role="alert" class="error-summary" tabindex="-1">
  <h2>Please fix the following errors:</h2>
  <ul>
    <li><a href="#name">Name is required</a></li>
    <li><a href="#email">Email address is invalid</a></li>
  </ul>
</div>

Why it matters:

• Overview of all issues
• Screen readers announce summary
• Links jump to problem fields
• Reduces cognitive load

5. Focus Management

Requirement: Logical focus order and visible focus indicators.

Good:

/* Visible focus indicator */
input:focus,
textarea:focus,
button:focus {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

Bad:

/* Removing focus indicators */
*:focus {
  outline: none; /* Never do this */
}

Why it matters:

• Keyboard users can see where they are
• Tab order is logical
• No focus traps
• Clear visual feedback

How SupportRetriever handles this:

• Clear focus indicators on all interactive elements
• Logical tab order
• Focus moves to error summary on submission failure
• No invisible focused elements

6. Keyboard Navigation

Requirement: All form functionality accessible via keyboard only.

Test checklist:

• Can reach all fields with Tab key
• Can submit with Enter key
• Can activate buttons with Space/Enter
• Can exit all fields with Tab/Shift+Tab
• Tab order matches visual order
• No keyboard traps

How SupportRetriever handles this:

• All interactive elements keyboard-accessible
• Standard keyboard behavior
• No custom keyboard controls that break expectations
• Tab order follows visual layout

7. Color Contrast

Requirement: Sufficient contrast between text and background.

WCAG 2.1 Level AA requirements:

• Normal text: 4.5:1 contrast ratio
• Large text (18pt+): 3:1 contrast ratio
• UI elements: 3:1 contrast ratio

Good:

/* Sufficient contrast */
label { color: #333333; background: #ffffff; } /* 12.6:1 */
button { color: #ffffff; background: #0066cc; } /* 7.5:1 */

Bad:

/* Insufficient contrast */
label { color: #cccccc; background: #ffffff; } /* 1.6:1 - fails */
button { color: var(--color-border-secondary)ddd; background: #ffffff; } /* 1.2:1 - fails */

How SupportRetriever handles this:

• All text meets AA contrast requirements
• Form fields have clear boundaries
• Error messages use sufficient contrast
• Focus indicators clearly visible

8. Input Types

Requirement: Use appropriate input types for better accessibility.

Good:

<input type="email" autocomplete="email">
<input type="tel" autocomplete="tel">
<input type="url">
<input type="number">

Why it matters:

• Mobile keyboards adapt to input type
• Browser validation
• Autocomplete works better
• Screen readers provide context

How SupportRetriever handles this:

• Proper input types for email, phone, URL
• Autocomplete attributes where appropriate
• No generic text inputs for specific data types

Anti-Spam That Won't Block Humans

What NOT to Do

Bad approaches:

• ✗ Difficult CAPTCHAs (image selection, math problems)
• ✗ Audio CAPTCHAs (often incomprehensible)
• ✗ Time limits (punishes slow users)
• ✗ Mouse-movement tracking (excludes keyboard users)
• ✗ Required fields that aren't necessary

Accessible Anti-Spam Techniques

Good approaches:

1. Cloudflare Turnstile

• Usually invisible
• No user interaction needed
• Respects accessibility
• WCAG compliant

2. Honeypot Fields

<!-- Hidden field bots fill but humans don't see -->
<input 
  type="text" 
  name="website" 
  tabindex="-1" 
  autocomplete="off"
  aria-hidden="true"
  style="position: absolute; left: -9999px;"
>

• Invisible to humans
• Removed from tab order
• No impact on legitimate users

3. Rate Limiting

• Backend throttling
• No user-facing impact
• Prevents automated floods

4. Email Validation

• Format checking
• Domain verification
• Helpful error messages

How SupportRetriever handles this:

• Cloudflare Turnstile (accessible)
• Backend rate limiting
• Email validation with clear errors
• No user-hostile CAPTCHAs

How to Test Quickly

Keyboard-Only Test (5 minutes)

Disconnect your mouse and:

1. Tab through entire form
2. Fill out all fields using only keyboard
3. Submit form with Enter key
4. Navigate to error messages if any
5. Complete successful submission

If you can do all this, keyboard accessibility is good.

Screen Reader Basics (10 minutes)

macOS (VoiceOver):

1. Press Cmd+F5 to enable VoiceOver
2. Navigate form with Tab key
3. Listen to what's announced
4. Try submitting with errors
5. Listen to error messages

Windows (NVDA - free):

1. Download NVDA from nvaccess.org
2. Launch NVDA
3. Navigate form with Tab key
4. Listen to announcements
5. Test error handling

What you should hear:

• Field labels
• Field types ("edit text", "button")
• Required status
• Error messages
• Success confirmations

Color Contrast Test (2 minutes)

Tools:

• WebAIM Contrast Checker
• Chrome DevTools (Lighthouse)
• Browser extensions (WCAG Color Contrast Checker)

Quick check:

• Inspect text elements
• Check contrast ratios
• Ensure 4.5:1 minimum for text
• Ensure 3:1 minimum for UI elements

Automated Testing (5 minutes)

Browser DevTools:

1. Open Chrome DevTools
2. Go to Lighthouse tab
3. Check "Accessibility"
4. Run audit
5. Review issues

Tools:

• WAVE Browser Extension
• axe DevTools
• Lighthouse (built into Chrome)

Note: Automated tools catch ~30-40% of issues. Manual testing is essential.

How SupportRetriever Helps

Built-In Accessibility

SupportRetriever forms include:

✓ Proper Semantic HTML

• Correct heading hierarchy
• Form landmarks
• Semantic form elements

✓ ARIA Labels

• All fields properly labeled
• Required fields announced
• Error states communicated

✓ Keyboard Accessible

• Logical tab order
• Visible focus indicators
• No keyboard traps

✓ Screen Reader Compatible

• Meaningful labels
• Error announcements
• Status updates

✓ Color Contrast

• WCAG AA compliant
• Clear visual boundaries
• Error states clearly visible

✓ Responsive & Mobile

• Touch-friendly targets
• Proper zoom support
• Mobile keyboard types

✓ Accessible Anti-Spam

• Cloudflare Turnstile (WCAG compliant)
• No hostile CAPTCHAs
• No time limits
• No user-hostile patterns

What You Don't Have to Worry About

When using SupportRetriever:

• ✓ Form markup is correct
• ✓ ARIA attributes are proper
• ✓ Focus management works
• ✓ Error handling is accessible
• ✓ Keyboard navigation works
• ✓ Screen readers work correctly

You just need to:

• Embed the form
• Test in your context
• Ensure surrounding content is accessible

Quick Accessibility Checklist

Before Launch

• All form fields have visible labels
• Required fields are marked
• Focus indicators are visible
• Form is keyboard navigable
• Color contrast meets WCAG AA
• Input types are appropriate
• Error messages are specific and clear
• Error summary appears on submission failure
• Success message is announced to screen readers
• Tested with keyboard only
• Tested with screen reader
• Automated accessibility scan passed

Ongoing

• Review user feedback about accessibility
• Test with real assistive technology users
• Keep up with WCAG updates
• Monitor for browser changes
• Test on mobile devices
• Verify with latest screen readers

Common Mistakes to Avoid

Placeholder-Only Labels

Bad:

<input type="text" placeholder="Enter your name">

Why: Placeholder disappears when typing, not read consistently by screen readers.

Good:

<label for="name">Name:</label>
<input type="text" id="name" placeholder="e.g., John Smith">

Hidden Labels

Bad:

<label style="display:none;">Name</label>
<input type="text">

Why: Invisible to sighted users, creates confusion.

Generic Error Messages

Bad:

<div>Form has errors</div>

Good:

<div role="alert">
  <h2>Please fix the following:</h2>
  <ul>
    <li><a href="#email">Email address is required</a></li>
  </ul>
</div>

Removing Focus Indicators

Never do this:

*:focus { outline: none; }

Alternative:

*:focus {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

Resources

Testing Tools

• WAVE: Web accessibility evaluation tool
• axe DevTools: Automated accessibility testing
• Lighthouse: Built into Chrome
• NVDA: Free screen reader (Windows)
• VoiceOver: Built into macOS/iOS

Guidelines

• WCAG 2.1: Web Content Accessibility Guidelines
• ARIA: Accessible Rich Internet Applications
• WebAIM: Web Accessibility In Mind

Learning

• WebAIM Articles
• A11y Project
• MDN Accessibility

Related Topics

• Understanding bot protection
• Reduce contact form spam without CAPTCHAs
• Mobile vs desktop experience
• Best practices for customer support