EAA-Compliant Contact Form: A Step-by-Step Guide for Web Developers

note

Because we are based in Germany, the explanations in this article are Germany-centric. But the core principles also apply to the European Accessibility Act (EAA) in other countries of the EU.

tip

You can find the source code for the entire implementation (HTML/CSS/JS) in this Codepen. The consolidated checklist of all points from this guide can be found in my Form Checklist for Web Developers.

The European Accessibility Act (EAA) [1] is in force and brings digital accessibility into focus. For you as a developer, this means: Every element, especially a contact form, must be usable by absolutely everyone. An inaccessible form is not only a legal risk but also a missed opportunity to connect with potential customers [2].

In this guide, we will build a form step-by-step that meets current legal requirements. I will explain not only what needs to be done but also why, referencing official guidelines. By the end, you will have a robust, accessible contact form that you can use in your projects.

Here is the live demo of the finished, accessible contact form:

warning

This form is a demo implementation for learning purposes. It does not send actual messages.

Demo Contact Form

All fields marked with an asterisk (*) are required. When a message is submitted, if there are no errors, a success message will appear, but nothing further will happen.

Your personal data

First name*

Last name*

Email*A valid email address consists of a name, the "@" symbol, and a domain (e.g., john.doe@example.tld).

Mobile number (Optional)For any follow-up questions. Only valid German mobile numbers with 7-11 digits (e.g., 01701234567).

Preferred contact method*

By emailBy phone

Message*

I have read the Privacy Policy and agree.*

info

The live demo above is created using React. The code examples in this step-by-step guide use Vanilla JavaScript (pure HTML/CSS/JS) so they are understandable regardless of the framework.

warning

This guide does not claim to cover all conceivable implementation variants. Rather, it offers a robust, practical reference that can be adapted to project-specific requirements.

Basic Structure & Instructions

The basis of every accessible form is clean, semantic HTML. This starts with correctly linking labels (<label>) with their input fields (<input>).

Every field needs a permanently visible <label> [3], which is connected to the field's id via the for attribute [4]. Placeholders that disappear upon input are no substitute for a label [5]. In Figure 1.1 you can see the example structure of an accessible form, which we will build below.

Furthermore, you should place general instructions, such as marking required fields, before the form so that users know what to expect [6]. The labels of the input fields should also be positioned before the field [7].

Schematic Basic Structure of an Accessible Form

Open text description for "Schematic Basic Structure of an Accessible Form"

This diagram shows the basic building blocks of a form.

1. Contact Form: The outermost element that encloses everything. It contains instructions, an error summary, fieldsets, and a send button.
2. Field Groups (<fieldset>): Used for grouping related input fields. It contains a label (<legend>) and the actual input fields.
3. Input Fields: Each field consists of a label (<label>) linked to an input field (<input>). Additionally, there may be input help that provides further information about the field.

Here is a code example for the basic structure:

HTML: Basic Structure of the Form

<p id="form-instructions-demo">
  All fields marked with an asterisk (*) are required fields.
</p>

<div
  id="error-summary-demo"
  class="contact-form__error-summary"
  role="alert"
  tabIndex="-1"
  hidden
  aria-labelledby="error-summary-title-demo"
>
  <h2 id="error-summary-title-demo">Your entries contain errors</h2>
  <p id="error-summary-intro"></p>
  <ul class="contact-form__error-summary-list">
    </ul>
</div>

<form id="contact-form-demo" class="contact-form__form" novalidate>
  <div class="contact-form__group">
    <label for="fname-demo" class="contact-form__label">
      <span class="contact-form__error-prefix" hidden>Error: </span>
      First Name*
    </label>
    <input
      type="text"
      id="fname-demo"
      name="fname"
      required
      aria-required="true"
      aria-invalid="false"
      aria-describedby="fname-error-demo"
      class="contact-form__input"
    />
    <div
      id="fname-error-demo"
      class="contact-form__error-message"
      hidden
    ></div>
  </div>
  <button type="submit" class="contact-form__submit-button">
    Send Message
  </button>
</form>

We use novalidate in the <form> tag to disable the browser's inaccessible default validation and manage error handling ourselves.

warning

Please note that the form must also be readable and operable at a screen width of 320px [8]. Ensure sufficiently large clickable areas (at least 44x44px) and avoid horizontal scrolling.

This can be particularly challenging for German due to often long words. Use CSS techniques like word-break: break-all; and insert soft hyphens (­) at appropriate places to allow line breaks without compromising readability.

Focus Order and Visibility for Keyboard Operability

A form that cannot be operated without a mouse is not accessible. Two criteria are essential here:

1. Logical Focus Order: Users navigating with the Tab key must be able to move through the form in a logical and intuitive sequence [9]. With a clean HTML structure (top to bottom), this is usually automatic. More complex layouts (e.g., using CSS Grid or Flexbox) must be checked for this.

2. Visible Focus: Every interactive element (input, button, link) must show a clearly visible indicator when it receives focus [10]. This is the "you are here" indicator for keyboard users. Never hide the outline style without providing a better, clearly visible replacement.

Modern Focus Style with :focus-visible

The CSS pseudo-class :focus-visible is the best choice for showing the focus outline only to keyboard users (but not on a mouse click), which prevents design discussions.

CSS: Modern & Visible Focus Style

/* Give all focusable elements a clear focus style */
input:focus-visible,
textarea:focus-visible,
button:focus-visible,
a:focus-visible,
[role='radio']:focus-visible,
[role='checkbox']:focus-visible {
  outline: 2px solid var(--ifm-link-color, #3153ad);
  outline-offset: 2px;
}

Logical Grouping of Input Fields

Related information (such as "First Name" and "Last Name" or a group of radio buttons) must also be programmatically recognizable as a group [11]. You use <fieldset> and <legend> for this [12] or alternatively ARIA roles such as role="group" [13].

The <fieldset> encloses the group, and the <legend> gives it a name that screen readers read aloud [12]. Without this structure, users of assistive technologies must guess which fields form a thematic block.

tip

When is <fieldset> a "must" and when is it "optional"? The <fieldset> element is not equally important for every grouping:

• Must (Mandatory): For groups of <input type="radio"> or <input type="checkbox">. The <legend> here presents the overarching "question" (e.g., "Preferred contact method?"), which is read for each individual element in context. Without <fieldset>, the options ("By email", "By phone") would be contextless for screen reader users.

• Optional (Best Practice): For thematically related text fields (like "First Name" and "Last Name"). Although each field has its own <label>, the <fieldset> creates additional semantic context that helps screen readers skim sections more easily.

HTML: Grouping Fields with <fieldset>

<fieldset class="contact-form__fieldset">
  <legend class="contact-form__legend">Your personal data</legend>

  <div class="contact-form__group">
    <label for="fname-demo" class="contact-form__label">
      <span class="contact-form__error-prefix" hidden>Error: </span>
      First Name*
    </label>
    <input
      type="text"
      id="fname-demo"
      name="fname"
      required
      aria-required="true"
      aria-invalid="false"
      aria-describedby="fname-error-demo"
      class="contact-form__input"
    />
    <div id="fname-error-demo" class="contact-form__error-message" hidden></div>
  </div>

  <div class="contact-form__group">
    <label for="lname-demo" class="contact-form__label">
      <span class="contact-form__error-prefix" hidden>Error: </span>
      Last Name*
    </label>
    <input
      type="text"
      id="lname-demo"
      name="lname"
      required
      aria-required="true"
      aria-invalid="false"
      aria-describedby="lname-error-demo"
      class="contact-form__input"
    />
    <div id="lname-error-demo" class="contact-form__error-message" hidden></div>
  </div>
</fieldset>

<fieldset
  class="contact-form__fieldset"
  aria-describedby="contactMethod-group-error-demo"
>
  <legend id="contactMethod-legend" class="contact-form__legend">
    <span class="contact-form__error-prefix" hidden>Error: </span>
    Preferred contact method*
  </legend>
  <div class="contact-form__radio-group">
    <label for="contact-pref-email-demo" class="contact-form__radio-label">
      <input
        type="radio"
        id="contact-pref-email-demo"
        name="contactMethod"
        value="email"
        required
        aria-required="true"
        class="contact-form__radio-input"
      />
      By Email
    </label>
    <label for="contact-pref-phone-demo" class="contact-form__radio-label">
      <input
        type="radio"
        id="contact-pref-phone-demo"
        name="contactMethod"
        value="phone"
        required
        aria-required="true"
        class="contact-form__radio-input"
      />
      By Phone
    </label>
  </div>
  <div
    id="contactMethod-group-error-demo"
    class="contact-form__error-message"
    hidden
  ></div>
</fieldset>

Help Texts & Input Support

Sometimes fields need additional explanations, e.g., about a specific format. These help texts must be programmatically linked to the field.

For this, the help text receives an id and the <input> element receives an aria-describedby attribute pointing to this id [14]. A screen reader then reads the label first, followed by the help text.

note

If you combine help text and error message, you can specify multiple IDs in the aria-describedby attribute, separated by spaces.

To further facilitate input, you should use the autocomplete attribute [15]. It allows the browser to automatically suggest known data (name, email, etc.). This is not only convenient but also an explicit requirement [16].

warning

Do not use placeholder attributes as the sole source of help. These disappear upon input and are therefore not permanently visible. They are no substitute for a <label> or help text [5].

If you use placeholder attributes, they should be supplementary and not contain essential information. For example, you can provide an example format, but not the only explanation of the format.

Ensure that the placeholder text has sufficient contrast of at least 4.5:1 against the background to ensure readability [17]. Make the text italic or use a different font style that identifies it as help text without compromising readability.

HTML: Help Texts and Autocomplete

<div class="contact-form__group">
  <label for="phone-demo" class="contact-form__label">
    <span class="contact-form__error-prefix" hidden>Error: </span>
    Mobile Phone Number (Optional)
  </label>
  <input
    type="tel"
    id="phone-demo"
    name="phone"
    autocomplete="tel"
    aria-invalid="false"
    aria-describedby="phone-hint-demo phone-error-demo"
    class="contact-form__input"
    placeholder="z.B.: 01701234567"
  />
  <span id="phone-hint-demo" class="contact-form__help-text">
    For any inquiries. Only valid German mobile phone numbers.
  </span>
  <div id="phone-error-demo" class="contact-form__error-message" hidden></div>
</div>

<div class="contact-form__group">
  <label for="email-demo" class="contact-form__label">
    <span class="contact-form__error-prefix" hidden>Error: </span>
    Email Address*
  </label>
  <input
    type="email"
    id="email-demo"
    name="email"
    autocomplete="email"
    required
    aria-required="true"
    aria-invalid="false"
    aria-describedby="email-hint-demo email-error-demo"
    class="contact-form__input"
  />
  <span id="email-hint-demo" class="contact-form__help-text">
    A valid email address (e.g. max.mustermann@example.com).
  </span>
  <div id="email-error-demo" class="contact-form__error-message" hidden></div>
</div>

Error Handling & Validation

Errors happen. An accessible form guides the user precisely toward correction [18]. The browser's default validation (which we disabled with novalidate) is unsuitable for this because its messages are often not focusable or are not noticed by screen readers [19].

Our approach consists of three parts:

1. Error Summary: A <div> at the beginning of the form that lists all errors [6]. This helps users quickly see what needs to be corrected and allows them to jump directly to the erroneous fields [20].
2. Inline Error: A text message directly beneath the erroneous field to provide the user with detailed information [21]. The input field itself is marked with aria-invalid="true" so that screen readers recognize the error [22].
3. Focus Management: The focus is actively set to the error summary using JavaScript when an error occurs.
4. We adjust the <label> (or <legend>) of each erroneous field by adding an "Error: " prefix. This is crucial to meet WCAG Success Criterion 1.4.1 [23]. If we only changed the color, the error would not be recognizable to colorblind users.

warning

This is not the only way to flag errors, but it is a proven method. It is important that the indication is provided both visually (color) and textually (prefix) to reach all user groups.

tip

A direct validation during input (e.g., with the input event) can greatly improve the user experience by displaying errors immediately [24].

However, this is not necessary for legal requirements. Therefore, we focus in this tutorial on validation when submitting the form.

In Figure 4.1 you can see the logic of validation and error handling that we will implement below.

Logic of Accessible Error Handling in a Form

Open text description for "Logic of Accessible Error Handling"

This flow chart shows the validation process:

1. The user clicks "Send".
2. JavaScript prevents the default submit action.
3. The resetErrors() function deletes all old error messages.
4. The validateForm() function checks all fields.
5. A decision checks: "Errors found?".
6. If Yes: The showErrorSummary() function populates the error summary, showInlineError() marks the fields, and the focus is set on the error summary via errorSummary.focus().
7. If No: The form is submitted.

Now we build the logic and the HTML structure for error handling.

HTML for Error Summary

The error summary must be prepared in the HTML. The summary receives role="alert", so screen readers immediately read it when displayed [25], and tabindex="-1", so we can focus it via JavaScript [26].

HTML: Preparing the Error Summary

<div
  id="error-summary-demo"
  class="contact-form__error-summary"
  role="alert"
  tabindex="-1"
  hidden
  aria-labelledby="error-summary-title-demo"
>
  <h2 id="error-summary-title-demo">Your entries contain errors</h2>
  <p id="error-summary-intro"></p>
  <ul class="contact-form__error-summary-list"></ul>
</div>

<!-- Form fields -->

In this example, the error summary is initially hidden with hidden and aria-hidden="true". As soon as an error occurs, it is made visible via JavaScript.

JavaScript for Validation

The script captures the submit event, validates the fields, and controls the display of errors.

Two things are important here for accessibility:

1. showErrorSummary(errors): Builds the error list with links that jump directly to the erroneous field. This is essential for keyboard navigation [20].
2. showInlineError(inputId, message): Sets the attribute aria-invalid="true" on the erroneous <input> [22] and shows the inline message.

JavaScript: Logic for Error Handling

document.addEventListener('DOMContentLoaded', () => {
  const form = document.getElementById('contact-form-demo');
  const fnameInput = document.getElementById('fname-demo');
  const errorSummary = document.getElementById('error-summary-demo');
  const errorSummaryList = errorSummary.querySelector(
    '.contact-form__error-summary-list'
  );
  const errorSummaryIntro = document.getElementById('error-summary-intro');

  // --- Regex Definitions ---
  const EMAIL_REGEX = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

  // --- Field Configuration (simplified for the snippet) ---
  // The original script uses a "fieldConfig" object
  // to manage all DOM elements (Inputs, Labels, Error Divs).
  // We access them directly here for simplicity.

  form.addEventListener('submit', (event) => {
    event.preventDefault();
    resetErrors(); // Reset old errors
    const newErrors = validateForm(); // Validate form

    if (Object.keys(newErrors).length > 0) {
      displayErrors(newErrors); // Display new errors
      errorSummary.focus(); // Set focus on summary
    } else {
      // Submit form successfully
      console.log('Form is valid.');
      // (Logic will be added in the next section)
    }
  });

  /**
   * Reads the form and returns an error object.
   */
  function validateForm() {
    const newErrors = {};
    // (Insert logic for all fields here)
    if (fnameInput.value.trim() === '') {
      newErrors.fname = 'Please enter your first name.';
    }
    // ...
    const emailInput = document.getElementById('email-demo');
    if (emailInput.value.trim() === '') {
      newErrors.email = 'Please enter your email address.';
    } else if (!EMAIL_REGEX.test(emailInput.value)) {
      newErrors.email = 'Please enter a valid email address.';
    }
    // ...
    return newErrors;
  }

  /**
   * Displays all errors in the summary and inline.
   */
  function displayErrors(currentErrors) {
    errorSummaryList.innerHTML = ''; // Delete old error links
    const errorEntries = Object.entries(currentErrors);

    errorSummaryIntro.textContent = `Please correct the following ${errorEntries.length} errors:`;

    errorEntries.forEach(([key, message]) => {
      // ID of the field (e.g., 'fname-demo')
      const fieldId = key + '-demo';

      // Display inline error
      const errorElement = document.getElementById(fieldId + '-error');
      if (errorElement) {
        errorElement.textContent = message;
        errorElement.hidden = false;
      }

      // Find and mark Label/Legend
      const labelElement =
        document.querySelector(`label[for="${fieldId}"]`) ||
        document.getElementById(key + '-legend'); // For fieldsets
      if (labelElement) {
        labelElement.classList.add(
          key === 'contactMethod'
            ? 'contact-form__legend--error'
            : 'contact-form__label--error'
        );
        // Display error prefix
        labelElement
          .querySelector('.contact-form__error-prefix')
          .removeAttribute('hidden');
      }

      // Mark input as 'aria-invalid'
      const inputElement = document.getElementById(fieldId);
      if (inputElement) {
        inputElement.setAttribute('aria-invalid', 'true');
      }

      // Add link to the error summary
      const li = document.createElement('li');
      const a = document.createElement('a');
      a.href = `#${fieldId}`; // Link to Input ID
      const labelText =
        labelElement?.dataset.errorsummaryLabel ||
        labelElement?.textContent
          .replace('*', '')
          .replace('Error:', '')
          .trim() ||
        key;
      a.textContent = `${labelText}: ${message}`;
      li.appendChild(a);
      errorSummaryList.appendChild(li);
    });

    errorSummary.hidden = false;
  }

  /**
   * Resets all error displays in the form.
   */
  function resetErrors() {
    errorSummary.hidden = true;
    errorSummaryList.innerHTML = '';
    errorSummaryIntro.textContent = '';

    // Reset all inline errors and attributes
    form.querySelectorAll('.contact-form__error-message').forEach((el) => {
      el.hidden = true;
      el.textContent = '';
    });
    form.querySelectorAll('[aria-invalid="true"]').forEach((el) => {
      el.setAttribute('aria-invalid', 'false');
    });
    form
      .querySelectorAll(
        '.contact-form__label--error, .contact-form__legend--error'
      )
      .forEach((el) => {
        el.classList.remove(
          'contact-form__label--error',
          'contact-form__legend--error'
        );
      });
    form.querySelectorAll('.contact-form__error-prefix').forEach((el) => {
      el.setAttribute('hidden', 'true');
    });
  }
});

Don't forget CSS for Error Labels

To make the "Error: " prefix and the red color visible, you need corresponding CSS rules:

Example CSS: Error Label Styling

/* BEM modifier for the label or legend in error state */
.contact-form__label--error,
.contact-form__legend--error {
  color: var(--ifm-color-danger, #f31221);
}

/* The "Error: " prefix, which is made visible via JS */
.contact-form__error-prefix {
  font-weight: bold;
}

/* The inline error message beneath the field */
.contact-form__error-message {
  color: var(--ifm-color-danger, #f31221);
  font-weight: 600;
  font-size: 0.875rem;
}

tip

Shortening Long Labels in the Error Summary You may have noticed the line label.dataset.errorsummaryLabel in the JavaScript code (Tab "JavaScript for Validation"). This is a useful technique for fields like the privacy policy checkbox.

The actual label is often very long ("I have read the privacy policy and agree."). In the error summary, however, we want a short, concise message (e.g., "Privacy Consent: Please agree.").

By applying a data-errorsummary-label attribute to the <label>, our JavaScript code can prioritize this shorter text for the error list.

The accessible error handling is now implemented!

Making the Submission Status (Loading) Accessible

After a user clicks "Send" and the form is valid, the submission process begins. This network request takes a moment. If you don't provide feedback here, the user is uncertain:

• "Did something happen?"
• "Do I need to click again?"

We must bridge this uncertain "in-between" accessibly. The best method is to disable the button to prevent double submission [27] and communicate a "busy" status.

We adjust the else block in our submit event listener accordingly.

JavaScript: Disable Submit Button and Announce Status

// ... inside the submit event listener ...

// ... (Variable Definitions)
const submitButton = form.querySelector('button[type="submit"]');

if (Object.keys(newErrors).length > 0) {
  // ... (Error handling as above) ...
} else {
  // NO ERRORS: Submit form

  // 1. Set UI status to 'submitting'
  // This function controls the button, spinner, and live region
  updateUIforStatusChange('submitting');

  // 2. Your actual submission logic (e.g., fetch) goes here
  // In this example, we simulate it:
  simulateFormSend() // This function returns a Promise
    .then((response) => {
      // Handle success case
      updateUIforStatusChange('success');
    })
    .catch((error) => {
      // Handle error case
      updateUIforStatusChange('error');
    });
}
// ...

/**
 * Simulates sending (takes 3 sec.)
 */
function simulateFormSend() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({ success: true });
    }, 3000);
  });
}

For the status announcement (statusRegion.textContent = ...), we need a live region. You can place this directly next to your error summary in the HTML. It is important to use role="status" and aria-live="polite" so that the announcement does not interrupt the current screen reader output [28].

HTML: Live Region for Loading and Success Status

<div
  id="form-status-message"
  role="status"
  aria-live="polite"
  class="visually-hidden"
>
  <!-- Here the status is displayed -->
</div>

Status After Submission (Success/Error)

After loading, there are two results: success (HTTP 200) or error (e.g., server error, HTTP 500). You must clearly communicate both to the user. There are two common, accessible scenarios here.

Scenario 1: Redirection to a Confirmation Page (Recommended)

This is the most robust and simplest method.

1. On Success: Redirect the user to a "Thank You" page (e.g., /contact/thanks).
2. On Error: Redirect the user to an "Error" page (e.g., /contact/error).

Here is an example of the success redirection in handleSuccess():

JavaScript: Success Redirection

function handleSuccess(response) {
  // 1. Success redirection
  window.location.href = '/contact/thanks';
}

For this to be accessible, the new page must:

• Have a clear, descriptive <title> tag (e.g., "Thank you for your message - My Website").
• Have a clear <h1> heading (e.g., "Thank you!").
• The focus is automatically set to the beginning of the document when the new page loads, causing the screen reader to read the new page title and the <h1>.

You do not need aria-live or focus management for this, as the browser page change already clearly communicates the context switch.

tip

I recommend this approach (redirection) because it provides the clearest feedback for all users and is less prone to implementation errors than a dynamic status display.

Scenario 2: Status Display Directly in the Form (without Redirection)

If you do not want a redirection, the status message must be brought actively to the user. We hide the form and display a status message that receives the focus.

Very important: This message must contain a button to reset the form. Otherwise, the user is stuck in a dead end.

HTML: Final Status Message (as Alert)

<div
  id="form-final-status"
  class="contact-form__final-status"
  role="alert"
  tabindex="-1"
  hidden
>
  <div id="final-status-success" hidden>
    <h2>Thank You!</h2>
    <p>Your message was sent successfully. (This is a demo).</p>
    <button type="button" class="contact-form__reset-button">
      Fill out again
    </button>
  </div>

  <div id="final-status-error" hidden>
    <h2>Error During Sending</h2>
    <p>Unfortunately, an error occurred. Please try again.</p>
    <button type="button" class="contact-form__reset-button">Try again</button>
  </div>
</div>

JavaScript: Display Success or Error in the Form

// --- These elements must be globally available in the script ---
const form = document.getElementById('contact-form-demo');
const finalStatus = document.getElementById('form-final-status');
const successView = document.getElementById('final-status-success');
const errorView = document.getElementById('final-status-error');
const statusMessage = document.getElementById('form-status-message');
const submitButton = form.querySelector('button[type="submit"]');
const submitButtonText = submitButton.querySelector(
  '.contact-form__submit-text'
);
const spinner = submitButton.querySelector('.contact-form__spinner');
const resetButtons = document.querySelectorAll('.contact-form__reset-button');
const fnameInput = document.getElementById('fname-demo'); // First field

// Global status variable
let status = 'idle';

/**
 * Updates the entire form UI based on the status.
 * This function is called by the 'submit' listener.
 */
function updateUIforStatusChange(newStatus) {
  status = newStatus;

  // --- Loading state (Submitting) ---
  const isSubmitting = status === 'submitting';
  submitButton.disabled = isSubmitting;
  spinner.hidden = !isSubmitting;
  submitButtonText.textContent = isSubmitting ? 'Sending...' : 'Submit (Demo)';
  statusMessage.textContent = isSubmitting ? 'Form is being sent...' : '';

  // --- Final states (Success or Server Error) ---
  const isSuccess = status === 'success';
  const isError = status === 'error';
  const isFinal = isSuccess || isError;

  // Hide form, display status box
  form.hidden = isFinal;
  finalStatus.hidden = !isFinal;

  if (isFinal) {
    // Display correct inner block (Success vs. Error)
    successView.hidden = !isSuccess;
    errorView.hidden = !isError;

    // Set CSS modifier for styling
    finalStatus.classList.toggle(
      'contact-form__final-status--success',
      isSuccess
    );
    finalStatus.classList.toggle('contact-form__final-status--error', isError);

    // IMPORTANT: Set focus on the status box!
    finalStatus.focus();
  } else {
    // Remove CSS modifier when resetting
    finalStatus.classList.remove(
      'contact-form__final-status--success',
      'contact-form__final-status--error'
    );
  }
}

/**
 * Event listener for the Reset buttons (in Success/Error box).
 */
resetButtons.forEach((button) => {
  button.addEventListener('click', () => {
    handleReset();
  });
});

/**
 * Resets the entire form to its initial state.
 */
function handleReset() {
  form.reset(); // Native HTML form reset method
  resetErrors(); // Our existing error reset function
  updateUIforStatusChange('idle'); // Reset UI

  // IMPORTANT: Reset focus to the first field!
  fnameInput.focus();
}

By setting the focus on the role="alert" container, we force the screen reader to immediately read the success or error message. The handleReset() flow ensures that the user (especially keyboard and screen reader users) has a clear path back to the start.

Conclusion

Creating an accessible form is not witchcraft, but solid craftsmanship. It requires care and an understanding of how different people interact with the web.

By using semantic HTML (label, fieldset), creating clear structures, and implementing fault-tolerant, supportive user guidance, you not only meet the legal requirements of the EAA [1]. You build a better, more user-friendly product for all your users [29]. The techniques shown here are universally applicable and a decisive step towards a truly inclusive internet.

A consolidated checklist of all points from this guide can be found in my Form Checklist for Web Developers.

Frequently Asked Questions (FAQ) about Accessible Forms

Why use novalidate in the <form> tag?

The novalidate attribute disables the browser's default error messages. These are often not accessible (e.g., only visible as small tooltips that disappear after a short time) and are not uniformly designed [19]. With novalidate, we take full control and can implement robust error handling with JavaScript that is accessible to everyone.

Is a red border sufficient for error messages?

No. A red border is purely visual information and is not perceivable for users with visual impairments (e.g., color blindness) or when using a screen reader [23]. Accessible error handling requires programmatic states (like aria-invalid="true") [22] and text alternatives that can be read out by assistive technologies [18].

Must I follow WCAG 2.1 or 2.2?

The EAA currently refers to WCAG 2.1 [30] via the EU standard EN 301 549 [31]. However, WCAG 2.2 [32] is the newer, recommended standard. It is a best practice to already orient yourself toward WCAG 2.2, as this is future-proof and fully covers the requirements of 2.1. You can find more information in my section "Legal Situation regarding Digital Accessibility".

What is the difference between required and aria-required="true"?

required is an HTML5 attribute that tells the browser a field must be filled (and triggers native validation if novalidate is missing). aria-required="true" is an ARIA attribute that explicitly tells assistive technologies (like screen readers) in the most robust way that a field is required. It is best to use both to ensure maximum compatibility and semantic clarity, because in some cases required alone is not correctly interpreted by all technologies or ARIA is not supported.

What about the click size of buttons (Target Size)?

An important change in WCAG 2.2 is Criterion 2.5.8 Target Size (Minimum) (Level AA) [33]. It states that interactive elements (buttons, links, radio buttons, checkboxes) should not be smaller than a minimum size of 24x24 CSS pixels.

This is crucial for users with motor impairments, e.g., on touch devices or those with unsteady hands, as it reduces accidental clicking on the wrong element. Ensure in your CSS that your click targets (especially the often too-small radio buttons and checkboxes) meet this requirement.

Disclaimer

The content of this guide is for informational purposes only and does not constitute legal advice. While I strive to provide accurate and current information, I make no warranty regarding 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 that you seek professional advice when implementing accessible forms and conduct regular tests with real users to ensure that the requirements of the WCAG 2.2 guidelines are met. I am not liable for any damages or losses resulting from the use of or reliance on the information contained in this guide.

1. Bundesministerium der Justiz und für Verbraucherschutz, “Gesetz zur Umsetzung der Richtlinie (EU) 2019/882 des Europäischen Parlaments und des Rates über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen (Barrierefreiheitsstärkungsgesetz – BFSG).” 2023. [Online]. Available: https://www.gesetze-im-internet.de/bfsg/ ⤴
2. Forrester Research, “Accessibility Is Still Vital For Businesses.” Feb. 03, 2025. [Online]. Available: https://www.forrester.com/blogs/accessibility-is-still-vital-for-businesses/ ⤴
3. W3C, “Success Criterion 3.3.2 Labels or Instructions,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#labels-or-instructions ⤴
4. W3C, “H44: Using label elements to associate text labels with form controls,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H44 ⤴
5. W3C, “F82: Failure of Success Criterion 3.3.2 by visually formatting a set of phone number fields but not including a text label,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/failures/F82 ⤴
6. W3C, “G83: Providing text descriptions to identify required fields that were not completed,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G83 ⤴
7. W3C, “G162: Positioning labels to maximize predictability of relationships,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G162 ⤴
8. W3C, “Success Criterion 1.4.10 Reflow,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#reflow ⤴
9. W3C, “Success Criterion 2.4.3 Focus Order,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#focus-order ⤴
10. W3C, “Success Criterion 2.4.7 Focus Visible,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#focus-visible ⤴
11. W3C, “Success Criterion 1.3.1 Info and Relationships,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#info-and-relationships ⤴
12. W3C, “H71: Providing a description for groups of form controls using fieldset and legend elements,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H71 ⤴
13. W3C, “ARIA17: Using grouping roles to identify related form controls,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA17 ⤴
14. W3C, “ARIA1: Using the aria-describedby property to provide a descriptive label for user interface controls,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA1 ⤴
15. W3C, “H98: Using HTML autocomplete attributes,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H98 ⤴
16. W3C, “Success Criterion 1.3.5 Identify Input Purpose,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#identify-input-purpose ⤴
17. W3C, “Success Criterion 1.4.3 Contrast (Minimum),” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#contrast-minimum ⤴
18. W3C, “Success Criterion 3.3.1 Error Identification,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#error-identification ⤴
19. E. Smith, “Accessible form validation with examples and code,” Pope Tech, Oct. 2025, [Online]. Available: https://blog.pope.tech/2025/09/30/accessible-form-validation-with-examples-and-code/ ⤴
20. W3C, “G139: Creating a mechanism that allows users to jump to errors,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G139 ⤴
21. W3C, “G85: Providing a text description when user input falls outside the required format or values,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G85 ⤴
22. W3C, “ARIA21: Using aria-invalid to Indicate An Error Field,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA21 ⤴
23. W3C, “Success Criterion 1.4.1 Use of Color,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#use-of-color ⤴
24. W3C Web Accessibility Initiative (WAI), “W3C Forms Tutorial: User Notifications.” 2023. [Online]. Available: https://www.w3.org/WAI/tutorials/forms/notifications/ ⤴
25. W3C, “ARIA19: Using ARIA role=alert or Live Regions to Identify Errors,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA19 ⤴
26. WHATWG, “HTML Living Standard.” 2024. [Online]. Available: https://html.spec.whatwg.org/ ⤴
27. W3C, “Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data),” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#error-prevention-legal-financial-data ⤴
28. W3C, “Success Criterion 4.1.3 Status Messages,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#status-messages ⤴
29. W3C Web Accessibility Initiative, “The Case for Digital Accessibility.” 2022. [Online]. Available: https://www.w3.org/WAI/business-case/ ⤴
30. W3C, “Web Content Accessibility Guidelines (WCAG) 2.1.” 2021. [Online]. Available: https://www.w3.org/TR/WCAG21/ ⤴
31. ETSI, “ETSI EN 301 549 V3.2.1 (2021-03) - Accessibility requirements for ICT products and services.” 2021. [Online]. Available: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf ⤴
32. W3C, “Web Content Accessibility Guidelines (WCAG) 2.2.” 2023. [Online]. Available: https://www.w3.org/TR/WCAG22/ ⤴
33. W3C, “Success Criterion 2.5.8 Target Size (Minimum),” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#target-size-minimum ⤴