Accessibility
Accessible forms: labels, errors and multi-step enquiries
An accessible form makes it clear at every stage which information is needed, how errors can be corrected and whether submission has actually succeeded. Visible labels, programmatic associations, keyboard operation and feedback must work together. For multi-step enquiries in particular, checking individual input fields is not enough: backward navigation, file uploads, session expiry and confirmation are also part of the complete user journey.
This article explores implementation through an explicitly hypothetical project enquiry: customers select a service, describe their project, provide contact details and optionally upload a brief. These examples are not documented client outcomes. The technical benchmark is WCAG 2.2 AA, including all applicable Level A and AA criteria. A technical assessment does not, however, replace a complete legal evaluation.
1. Start with the journey through the form
First establish which information is genuinely necessary. For our hypothetical initial consultation, a name, email address and short description might be enough. Telephone number, organisation and project documents remain optional unless the actual process requires them. Every additional required field creates another potential barrier. Ask not only whether a field is technically accessible, but also whether its purpose makes sense to the person completing it.
Then describe the whole journey, including its failure paths. Someone opens the form using a keyboard, enters an international telephone number, returns to the previous step and submits over an unstable connection. What is preserved? Where does focus go? Which message appears? These concrete journeys produce better requirements than a general instruction to “make the form accessible”. Record expected states and observable results before design and development begin.
2. Connect labels, instructions and groups clearly
Every input needs a programmatically determinable accessible name. Use permanently visible text labels for the form fields described here. In particular contexts, clear visible icons or other unambiguous contextual cues can also communicate purpose; a placeholder alone is not a reliable substitute. For native HTML fields, connect a label through its for attribute to the input's unique id. A placeholder does not replace that label: it disappears during typing and can be mistaken for an example value. A hypothetical field should visibly say “Email address”, rather than only carrying the internal name “email”. This also allows people using voice control to refer to the visible wording.
Place supplementary instructions beside the field and associate them using aria-describedby where appropriate. “We use this address to reply to your enquiry” explains the purpose; another instruction can explain a genuinely necessary format. Avoid conflicting names introduced through additional ARIA labelling. Native semantics are usually simpler and more robust than a system of roles and attributes added afterwards.
Related choices need a group context. For “What support do you need?”, fieldset and legend are suitable alongside clearly labelled options. Explain required information in advance and identify it at the relevant field, rather than relying only on colour or an unexplained asterisk. The WAI Forms Tutorial explains these relationships between labels, groups and instructions.
3. Align input purpose, autocomplete and formats
Choose appropriate native input types without delegating all validation to them. type=email supports email entry, while type=tel supports telephone numbers. inputmode can request a suitable on-screen keyboard, but does not define valid values. Telephone numbers, for example, are not quantities for calculation: a number input can make leading zeros or international notation difficult. Accept spaces and common separators when your downstream process can safely normalise them.
For information about the person completing the form, appropriate autocomplete tokens include name, given-name, family-name, email and tel. Use only values matching the actual purpose, and distinguish multiple address contexts with suitable section identifiers when necessary. Autocomplete replaces neither labels nor validation. Test the journey with a populated browser profile: are values assigned correctly, retained between steps and recognised by your form logic when the browser fills them automatically?
Do not demand a restrictive format without a business reason. A hypothetical date field needs clear advance instructions and an accessible way to enter the date; a graphical calendar alone is insufficient. International names must not fail a validation rule limited to ASCII letters. Document these rules as product decisions so that the frontend and backend accept the same inputs.
4. Validate when feedback becomes useful
An error message triggered by the first character is rarely helpful. Depending on the field, validate after the person has finished entering information or when they submit. Restrained updates during correction can be useful. However, avoid issuing a fresh announcement with every keystroke. A screen reader should not repeatedly interrupt typing with “invalid”. Specify exactly how an untouched field, a checked field and a corrected field should be presented.
Client-side validation improves immediate feedback; server-side validation remains necessary for processing. Both must communicate the same business rules clearly. A valid address might still encounter a server problem, for example. In that case, the message should describe the submission problem rather than say “Invalid email address”. Preserve entered values and distinguish input errors, connection failures and internal errors. People should not be asked to change correct information because of a technical fault.
5. Combine field errors with an error summary
A useful field error identifies the problem and the next practical action: “Enter an email address containing an @ sign” is more helpful than “Invalid value”. Associate the message programmatically with the field and set aria-invalid=true when an error is detected. Remove or update the error state after successful correction. A red border can provide reinforcement, but must not be the only indication of an error.
When several errors occur, a summary at the beginning of the form helps after submission. One implementation moves focus to a programmatically focusable summary container headed “Please correct three details”. Meaningful links underneath lead to the affected fields. Activating a link must actually focus the input, rather than merely scroll the page to its position. Keep the count consistent as the errors change.
Choose deliberately between moving focus and making additional live announcements, so the whole list is not read twice. The WAI Forms Tutorial: User Notifications describes accessible error and success feedback. A recorded journey provides useful acceptance evidence: submit, hear the summary, activate an error link, understand the field description, correct the value and submit again without losing other information.
6. Build multi-step enquiries as one connected process
Split a form only when the structure genuinely improves orientation. Our hypothetical enquiry could contain “Project”, “Contact” and “Review and send”. Show the current step in text and identify it programmatically, for example with aria-current=step within an ordered step indicator. Colour alone is insufficient. Steps that are not yet available should not look like working links.
After “Continue”, validate the current step. If it passes, change the view and move focus to a meaningful heading for the next step. A page navigation also needs an appropriate document title. “Back” preserves information already entered and must not be blocked by incomplete required fields in the current step. Test the browser's back navigation as well, rather than considering only your own button.
Information already supplied within the same process should not be requested again unnecessarily. WCAG 2.2 addresses this under “Redundant Entry”, with defined exceptions. If someone changes their selected service, explain which subsequent details are no longer relevant or newly required. The WAI overview of WCAG 2.2 provides context for this and the other added criteria.
7. Test focus, keyboard operation and mobile presentation together
The tab sequence should follow the visual and logical order. Do not use positive tabindex values to repair an unsuitable layout after the fact. Every action needs an appropriate operable element: “Continue” is a button, not a clickable area without keyboard behaviour. Focus must remain visible. A fixed footer must not completely hide the focused field; preferably provide a working position where it remains fully visible.
Also test the form with enlarged text and at a width of 320 CSS pixels. Labels, instructions and error messages must not be clipped or create inaccessible overlaps. Long filenames and lengthy translated error messages are useful test data. Adequate contrast concerns not only text but, under the relevant conditions, meaningful component boundaries too. The normative requirements appear in WCAG 2.2; they do not prescribe a particular font family.
8. Make file uploads possible without dragging
An upload area needs an operable file picker even when drag-and-drop is also available. State accepted formats, size limits and the permitted number of files before selection. Label the upload according to its purpose, such as “Add project brief, optional”. A native file input is often a good foundation; a custom replacement must genuinely preserve accessible operation.
Show selected files with their names, states and clearly labelled removal actions. “Remove Brief.pdf” is easier to understand among several files than repeated buttons saying only “Remove”. After deletion, move focus to a sensible remaining element. Distinguish “selected”, “uploading”, “being checked” and “available” if those states exist in your system. A completed transfer does not automatically mean that server-side checks have passed.
If a file is rejected, explain the specific reason and preserve the rest of the enquiry. If the connection fails, provide an understandable retry option. Hypothetically test a disallowed file, a duplicate filename and an interruption during upload. Acceptance testing also covers the output through assistive technology and whether the form can sensibly continue despite a failed optional upload.
9. Deliver status messages selectively and reliably
Not every change needs a focus move. “File uploaded” or “Draft saved” can be communicated as a status message while the person continues working in the current field. Use an appropriate programmatic mechanism, often an existing region with role=status. Urgent errors require deliberate handling; role=alert is not a universal solution for every piece of feedback.
Understanding SC 4.1.3: Status Messages explains when status messages must be programmatically determinable without moving focus. During uploads, do not announce every small progress change separately. Instead, test understandable state changes and the final result. The presence of a live region alone does not guarantee usable output: timing, DOM updates and the browser–screen reader combination must work together.
10. Distinguish review, submission and confirmation
Before final submission, a summary presents the essential details with targeted editing options. An “Edit contact details” link returns to the relevant step without deleting other information. For legal commitments, financial transactions and certain data changes, WCAG 3.3.4 requires appropriate safeguards: at least reversibility, checking with an opportunity to correct, or review and confirmation with an opportunity to correct. An ordinary enquiry is not automatically such a transaction.
During submission, prevent accidental duplicate requests and communicate the waiting state. The backend architecture should also account for retries. Display success only when the system has reliably confirmed receipt. “Thank you for your enquiry” is rather brief on its own: explain what was received and what will actually happen next, without inventing a response time that has not been agreed.
A confirmation page needs a clear title and appropriate focus management; confirmation within the same view needs a suitable announcement. An email can supplement this but does not replace immediate feedback. If submission status is uncertain, claim neither success nor definite failure. Explain the uncertainty and provide a safe way to clarify the outcome so that people do not submit again blindly.
11. Organise acceptance around reproducible evidence
Test at least one successful journey and deliberately exercise the critical failure paths. Record the starting state, inputs, actions, expected behaviour and observed result. For a focus issue, this includes which element is active after “Continue” and which heading is announced. Automated checks can detect missing associations, but cannot fully judge whether correction instructions or the overall process are understandable.
Add keyboard testing, screen reader journeys, magnification, mobile entry and simulated server-side failures. Use synthetic rather than real personal test data. Agree regression tests for shared form components: changing the error component may affect several enquiry forms. Editorial changes to labels, new required fields and upload rules also need renewed testing in their respective usage contexts.
12. Common questions and a practical next step
Is an automated form check enough?
No. It supports technical checking but does not replace assessment of focus management, understandable messages, data retention and complete journeys using a keyboard and assistive technologies.
Are multi-step forms always better?
No. They help with longer processes that have meaningful sections. For a few details, one clear page is often simpler. Orientation, preserved inputs and reliable navigation are what matter.
Does every contact form fall under Austria's BaFG?
No. Since 28 June 2025, the BaFG has applied to covered services, not automatically to every website. Information-only offerings and exclusively B2B services generally are not consumer e-commerce; according to WKO, the classification of a contact form alone is disputed. See the guide to accessible websites in Austria for scope and exemptions.
How can Zensations help with an existing form?
An accessibility audit can examine a specific enquiry journey, including its error states, and prioritise actionable implementation steps. Zensations, founded in Vienna in 2010, also supports improvements through its accessibility services. Bring your form variants, known issues and test access. WCAG and EN 301 549 are not interchangeable; an audit is neither a complete legal assessment nor a guarantee of conformity.
Sources and review date
Content reviewed on 7 November 2026. The following primary sources support the technical recommendations; the linked Austria guide provides further legal context.
