Accessibility Audit Checklist — Checkout Form, Custom Dropdown, Modal Confirmation, Toast Notifications

1. Checkout Form

1.1 Errors are identified, described, and announced

• WCAG 2.2 criteria at risk:
  • 3.3.1 Error Identification
  • 3.3.3 Error Suggestion
  • 3.3.7 Redundant Entry
  • 4.1.3 Status Messages
• Keyboard test:
  1. Submit the form with required fields empty or invalid.
  2. Confirm focus moves to the first invalid field or to an error summary.
  3. Tab through all invalid fields and verify each error is reachable and associated with its field.
  4. Correct and resubmit without being required to re-enter previously supplied information.
• Screen reader expectation:
  • Submission failure is announced without requiring users to search for it.
  • Each invalid field announces its label, state, and specific error.
  • Corrected errors are removed or updated appropriately.
• Typical failure:
  • Errors are communicated only by color.
  • Error text is visually present but not programmatically associated with the field.
  • Focus remains on the submit button.
  • A generic “Invalid input” message gives no correction guidance.
• Code-level fix:

  <div id="checkout-errors" role="alert" tabindex="-1">
    Please correct the highlighted fields.
  </div>
  
  <label for="email">Email address</label>
  <input
    id="email"
    name="email"
    type="email"
    required
    aria-invalid="true"
    aria-describedby="email-error"
  >
  <p id="email-error">Enter an email address in the format [email protected].</p>
  

  • On failed submission, focus the error summary or first invalid field.
  • Use aria-invalid="true" only while invalid.
  • Associate errors with aria-describedby.
  • Use an assertive announcement only for submission-blocking errors.

1.2 Every field has a clear accessible name and purpose

• WCAG 2.2 criteria at risk:
  • 1.3.1 Info and Relationships