Frontend Architecture
Accessible forms: code reading
Crux Read real JSX snippets — label association, an aria-live error region, focus management, and a controlled input — and pick the highest-leverage accessibility fix.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitForm accessibility is decided in the markup and the submit handler. Read each snippet the way you would in a PR review, then choose the fix a senior engineer makes first.
Goal
Practise the review loop: spot the broken label association, the live region that announces nothing, the missing focus move, and the controlled input that drops the field name — then reach for the correct fix.
Snippet 1 — the label that associates with nothing
function EmailField() {
return (
<div className="field">
<label>Email</label>
<input type="email" name="email" placeholder="you@example.com" />
</div>
);
} Quiz
Completed
A screen reader announces this field as 'edit text' with no name. What is the bug and the fix?
Heads-up A placeholder is not a programmatic name and vanishes on focus. There is no aria-hidden here; the real gap is the absent htmlFor/id association.
Heads-up aria-label on a non-interactive div does nothing for the input's name. Put the association on the control: htmlFor/id, or wrap the input in the label.
Heads-up type=email controls validation and keyboard, not the accessible name. The name comes from an associated <label>, which is missing.
Snippet 2 — the error region that announces nothing
function Form() {
const [error, setError] = useState("");
return (
<form onSubmit={validate}>
<input id="zip" name="zip" aria-describedby="zip-err" />
{error && <div id="zip-err" role="alert">{error}</div>}
<button>Submit</button>
</form>
);
} Quiz
Completed
Sighted users see the error; many screen-reader users hear nothing. Why, and what is the minimal fix?
Heads-up role=status is polite and right for non-urgent updates, but errors warrant assertive role=alert. The defect is that the region is conditionally mounted, not the role.
Heads-up Removing aria-describedby breaks the field-to-message link. Keep it and make the target persistent; the describedby is correct, the conditional mount is not.
Heads-up State updates the DOM fine. The issue is the element entering the DOM together with its text rather than the text changing inside an already-present region.
Snippet 3 — the submit handler that forgets focus
function handleSubmit(e) {
e.preventDefault();
const invalid = fields.filter((f) => !f.valid);
invalid.forEach((f) => {
f.el.setAttribute("aria-invalid", "true");
setMessage(f.id, f.error); // writes into a persistent live region
});
// ...nothing else
} Quiz
Completed
aria-invalid is set and the messages are announced, yet keyboard users say the form 'does nothing' on a failed submit. What is missing?
Heads-up Whether you set aria-invalid via attribute or prop, the user still never reaches the field. The missing step is moving focus, not the mechanism for the attribute.
Heads-up autofocus only fires on initial page load, not on a submit-time validation failure. You must imperatively focus the first invalid field after validating.
Heads-up Removing preventDefault discards the custom messages and async checks this handler exists for. Keep it and take ownership of focus: call focus() on the first invalid field.
Snippet 4 — the controlled input that drops its name
function NameField({ value, onChange }) {
return (
<>
<span className="lbl">Full name</span>
<input
value={value}
onChange={(e) => onChange(e.target.value)}
/>
</>
);
} Quiz
Completed
This is a correctly controlled React input, yet it fails accessibility. What is the real problem and fix?
Heads-up Controlled and uncontrolled inputs both associate with a label identically. The control mode is unrelated to the missing label; making it uncontrolled would not add a name.
Heads-up An onChange handler is present, so the input is editable, not read-only. The accessibility gap is the missing label association, not the value/defaultValue choice.
Heads-up A React fragment renders nothing and does not affect the tree. The input is exposed; what it lacks is a programmatically associated name.
Recap
Every form accessibility bug is visible in the markup or the submit handler: a label must be associated by htmlFor/id or wrapping (a placeholder or sibling span is not a name); a live region must be persistent so its text change is observed; a failed submit must imperatively move focus to the first invalid field, not just set aria-invalid; and controlled-vs-uncontrolled is orthogonal to whether the input has an accessible name. Read the markup, find the broken association or the un-moved focus, then fix that before anything else.