What is an Accessible Contact Form?

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.

Components of a Form

Forms (you know them as contact forms, logins, or checkouts) are the most important interaction points on the web. They are used to interact with users, collect data, or enable registrations.

Due to the European Accessibility Act (EAA), their accessibility is no longer optional, but a legal requirement [1]. The typical components of a form are:

• Labels & Input Fields: Every field (<input>, <textarea>) requires a clear, permanently visible <label>. [2]
• Logical Grouping: Related fields (e.g., address data or radio buttons) are grouped using <fieldset> and <legend>. [3]
• Help Texts & Support: Optional help texts (linked via aria-describedby) and autocomplete attributes facilitate completion. [4]
• Error Handling: A robust mechanism that identifies errors, displays them collectively, and guides the user toward correction. [5]
• Status Management: Visual and auditory feedback upon submission (role="status") and after completion (role="alert"). [6]

What makes a form accessible?

An accessible contact form ensures that all these functions are also accessible to people who use a keyboard instead of a mouse or rely on screen readers. This means for you:

• Clear Labeling & Structure: The relationship between labels, help texts, error messages, and input fields is semantically mapped correctly. [3]
• Complete Keyboard Operability: All fields, buttons, and links are reachable and operable via keyboard – in a logical order. [7], [8]
• Reliable Focus Management: The focus is guided logically. Especially in the case of errors, the user is actively directed to the error summary. [9]
• Helpful Input Assistance: Fields for known data (name, email, etc.) have autocomplete attributes. [4]
• Understandable Announcements: Screen readers can clearly communicate the purpose of each field, its status (e.g., "required field," "invalid"), and all status changes (e.g., "Sending...", "Error occurred") clearly communicate. [10], [6]

Ensure that your form meets these criteria to create an inclusive, EAA-compliant, and accessible user experience for all visitors to your website.

Here you can see an example of such a form:

warning

This form is a demo implementation for learning purposes. It does not send real 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.*

Resources for Accessible Forms

This section is aimed especially at developers who want to create accessible digital products. This is where the rubber meets the road: How do I build accessible forms that truly work – for all user groups?

Here you will find the following resources:

• Step-by-Step Guide for implementing an accessible contact form
• The ultimate checklist for auditing the accessibility of forms

tip

This area is regularly expanded. Feel free to check back often to discover new patterns and best practices!

For every recommendation, I explain the Why behind it, show practical Do’s & Don’ts, and provide concrete code examples. Additionally, they are provided with sources for relevant WCAG criteria [11] and WAI-ARIA patterns [12], so you can easily understand the requirements.

Just start with the Step-by-Step Guide to build a solid framework. Use the Checklist to ensure that your form meets all key accessibility requirements.

Good luck with the implementation of accessible forms! If you have any questions or would like to give feedback, please feel free to contact me.

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. W3C, “Success Criterion 3.3.2 Labels or Instructions,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#labels-or-instructions ⤴
3. W3C, “Success Criterion 1.3.1 Info and Relationships,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#info-and-relationships ⤴
4. W3C, “Success Criterion 1.3.5 Identify Input Purpose,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#identify-input-purpose ⤴
5. W3C, “Success Criterion 3.3.1 Error Identification,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#error-identification ⤴
6. W3C, “Success Criterion 4.1.3 Status Messages,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#status-messages ⤴
7. W3C, “Success Criterion 2.1.1 Keyboard,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#keyboard ⤴
8. W3C, “Success Criterion 2.4.3 Focus Order,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#focus-order ⤴
9. W3C, “Success Criterion 2.4.7 Focus Visible,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#focus-visible ⤴
10. W3C, “Success Criterion 4.1.2 Name, Role, Value,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#name-role-value ⤴
11. W3C Web Accessibility Initiative, “WCAG 2.2 Overview.” 2023. [Online]. Available: https://www.w3.org/WAI/standards-guidelines/wcag/wcag2.2/ ⤴
12. W3C Web Accessibility Initiative, “WAI-ARIA Authoring Practices 1.2.” 2021. [Online]. Available: https://www.w3.org/TR/wai-aria-practices/ ⤴