EAA-Compliant Contact Form: A Checklist for Web Developers
Information about the article
Author: Dmitry Dugarev
Forms are the most crucial interaction points on your website. Therefore, it is essential that they are accessible to all users—regardless of their abilities or the technologies used. This checklist, taken from my complete guide to accessible forms, helps you review the most important accessibility aspects of your forms.
Checklist for Basic Structure & Instructions
- Does every form field have a permanently visible
<label>element? [1] - Is the
<label>element positioned before the associated input field? [2] - Is every
<label>linked to theidof the associated field via theforattribute? [3] - Are the IDs of all form elements on the page unique? [4]
- Are there general instructions before the form (e.g., regarding the designation of mandatory fields) and/or an error summary? [5]
- Are mandatory fields visually (e.g.,
*) AND programmatically (required,aria-required="true") marked? [6] - Do all interactive elements (buttons, links, radio buttons, checkboxes) have a minimum clickable area of 24x24 CSS pixels? [7]
- Is there no horizontal scrolling at small screen sizes (e.g., 320px width)? [8]
Keyboard Operability
- Is the focus order logical and intuitive when navigating with the
Tabkey? [9] - Is the keyboard focus (e.g., the
outline) clearly visible at all times and does it have sufficient contrast? [10]
Grouping of Input Fields
- Are all groups of radio buttons and checkboxes mandatorily enclosed in a
<fieldset>? [11] - Do these
<fieldset>groups have a meaningful<legend>which poses the "question" to the group? [12] - Are strongly related text fields (e.g., "First Name & Last Name" or a "Billing Address") also grouped (as best practice) in a
<fieldset>with<legend>?
Help Texts & Input Support
- Do fields with specific format requirements have a visible help text? [1]
- Is this help text linked to the field via
aria-describedby? [13] - Do all fields that request personal or known data (Name, E-Mail, Phone, Address) have the correct
autocompleteattribute? [14], [15] - Are
placeholderattributes only used supplementarily and do not contain essential information? [16] - Do all
placeholderattributes have sufficient contrast (at least 4.5:1) and are they recognizable as help text (e.g., through italics)? [17]
Error Handling
- Is the browser's default validation suppressed with
novalidate? - Does an error summary appear at the beginning of the form upon an error? [6]
- Does the summary container have
role="alert"andtabindex="-1"? [18] - Is the focus programmatically set to the summary upon an error? [6]
- Does the summary contain clickable links that correctly jump to the respective field (or to the first element of a group like radio buttons)? [19]
- Are the link texts in the summary precise and helpful (e.g., by using
data-errorsummary-labelfor long checkbox texts)? - Is a specific inline error message displayed for every faulty field? [20]
- Does every faulty field dynamically receive the attribute
aria-invalid="true"? [21] - Is the
<label>or<legend>of a faulty field marked both with color and with a textual prefix (e.g., "Error: ")? [22] - Are all error messages,
aria-invalidattributes, and label error states (prefix/color) removed upon a new check (e.g.,resetErrors())? [20]
After Submission
As soon as the user submits the form, they should be informed about the status of the submission process—whether through a redirect, a success message, or an error message.
Submission Status
- Is the "Send" button immediately disabled after the click (and successful validation) to prevent double submissions? [23]
- Is the "Busy" state displayed visually (e.g., "Sending...", spinner)?
- Is the "Busy" state programmatically announced via an
aria-liveregion (role="status")? [24]
Final Status (if no redirection occurs)
- Is a success or server error message displayed in a
role="alert"region? [18] - Is the keyboard focus programmatically set to the start of this message (
.focus()) as soon as it appears? - Is the form hidden upon success to prevent confusion?
- Does the final status message contain a visible button (e.g., "Fill out again" / "Try again") to reset the form?
- After clicking the reset button, is the form reset, the status message hidden, and the form displayed again?
- Is the focus programmatically set to the first field of the form after resetting?
- Is the Send button reactivated (or remains active) upon a server error so that the user can try again? [23]
Conclusion
The accessibility of forms is crucial to ensure that all users can interact with your website without problems. Use this checklist to review your forms and ensure they comply with the best accessibility practices. For a detailed explanation and further tips, I recommend reading my complete guide to accessible forms.
Disclaimer
The content of this checklist is for informational purposes only and does not constitute legal advice. While I strive to provide accurate and current information, I make no guarantee as to the completeness, accuracy, or timeliness of the information provided. Compliance with accessibility standards may vary depending on the specific context and use case. It is recommended to seek professional advice when implementing accessible forms and to conduct regular testing with real users to ensure that the requirements of the WCAG 2.2 guidelines are met. I am not liable for damages or losses resulting from the use of or reliance on the information contained in this guide.
About the author