How would you make a form accessible to screen readers

Making Forms Accessible to Screen Readers

Accessible forms ensure that all users, including those using screen readers, can understand and interact with the form easily. Proper labeling, instructions, and error handling are key.

Key Practices for Accessible Forms

1
Use <label> Elements – Associate each input with a <label> using the for attribute. This provides a clear accessible name.
2
Group Related Fields – Use <fieldset> and <legend> for groups of related controls, like radio buttons or checkboxes.
3
Provide Instructions – Include guidance using visible text or aria-describedby for additional context.
4
Use Semantic Input Types – Use HTML5 input types (e.g., email, tel, number) for better screen reader and keyboard support.
5
Error Handling – Clearly indicate errors with inline messages and associate them with the input using aria-describedby.
6
Keyboard Navigation – Ensure all inputs, buttons, and interactive elements are reachable and usable via keyboard.
7
Avoid Placeholder as Labels – Placeholders are not a replacement for labels; they disappear on focus and may not be read by all screen readers.

Example

1
<label for="email">Email:</label>
2<input type="email" id="email" name="email" aria-describedby="email-hint">
3<p id="email-hint">Enter a valid email address we can contact you at.</p>

Best Practices

1
Always provide a visible label for inputs whenever possible.
2
Use ARIA attributes like aria-describedby to provide extra instructions or error messages.
3
Ensure proper focus order and keyboard accessibility.
4
Test the form with screen readers to confirm usability.

Difficulty: 5/10

Topics: semantic HTML, ARIA attributes, error handling

Scenario Questions

0-2 years experience

1
We have a simple login form with username and password fields. Walk me through how you'd mark it up so a screen reader can understand it.
2
If a user reports that the placeholder text is being read as the field label, what would you change in the HTML?

2-5 years experience

1
We're adding a dynamic address autocomplete component to a checkout form. The component injects options via JavaScript. How would you ensure the screen reader announces the new options correctly?
2
During QA a tester finds that error messages appear visually but aren't announced by the screen reader. What steps would you take to debug and fix this?
3
Our form uses custom checkboxes styled with divs. Explain the trade‑offs of keeping the native input versus replacing it, and how you'd make it accessible.

5-8 years experience

1
Our product has a multi‑step wizard form that can be navigated via next/prev buttons and also via the browser's back button. How would you design the markup and ARIA to keep screen reader users oriented across steps, especially when steps are loaded lazily?
2
We need to support internationalization and right‑to‑left languages in a large form with many grouped fields. What considerations do you have for screen reader accessibility at scale, and how would you test them?

8+ years experience

1
The company is migrating a legacy monolithic checkout flow to a micro‑frontend architecture. The old forms have inconsistent ARIA usage. How would you set an organization‑wide strategy to audit, refactor, and enforce screen‑reader accessibility across teams?
2
We plan to expose our form components as a shared UI library used by multiple product lines. What patterns would you establish to ensure any new form component is automatically accessible, and how would you integrate that into CI/CD?

Follow-up Questions

❓Which ARIA attribute would you use to announce a validation error?
❓How do you verify that your markup works with NVDA or VoiceOver?
❓What are the risks of hiding native inputs and replacing them with divs?