Forms, Accessibility & UX Engineering
Build accessible React interfaces with semantic HTML, labels, keyboard navigation, focus management, validation, and robust form UX.
Semantic HTML in React
React does not make semantic HTML obsolete. Use buttons for actions, anchors for navigation, headings for document structure, lists for collections, and form elements for forms.
Semantic elements provide built-in browser behavior and accessibility support. Replacing a button with a div onClick creates extra keyboard, focus, and ARIA work.
Use ARIA to fill genuine semantic gaps, not to compensate for incorrect element choices.
<button type="button" onClick={save}>Save</button>- Prefer native semantic elements.
- ARIA supplements semantics; it does not replace them.
- Accessibility is easiest when built into component primitives.
Labels, Validation & Error Messaging
Every form control needs an accessible name. A visible <label> associated with an input is usually the best default.
Validation should explain what the user needs to fix. Connect error messages to fields with appropriate semantics and avoid relying on color alone.
Client-side validation improves feedback but does not replace server-side validation. Treat all client input as untrusted at the API boundary.
<label htmlFor="email">Email</label>
<input
id="email"
name="email"
aria-invalid={Boolean(error)}
aria-describedby={error ? "email-error" : undefined}
/>
{error && <p id="email-error">{error}</p>}- Every control needs an accessible name.
- Errors should identify the field and explain how to fix it.
- Server validation remains mandatory.
Keyboard Navigation & Focus Management
Keyboard users need to reach every interactive control, understand focus location, and activate controls without a mouse.
Modals and dialogs require careful focus management: move focus into the dialog when it opens, keep focus within it when appropriate, and restore focus to a sensible trigger when it closes.
Do not remove visible focus outlines without providing an equally clear replacement.
- Keyboard navigation is a first-class interaction mode.
- Dialogs need deliberate focus behavior.
- Never make focus invisible without a better replacement.
Responsive UI & Component Design
Responsive design is more than changing widths. Components should adapt to viewport constraints, content length, input methods, and accessibility needs.
Avoid hard-coding assumptions such as a fixed number of characters fitting in a card. Let content and layout rules cooperate. Test zoom, narrow screens, long labels, large text, and touch interactions.
Reusable components should expose layout behavior through intentional APIs rather than requiring consumers to override internal selectors.
- Design for content variation, not only ideal screenshots.
- Test keyboard, zoom, touch, and narrow widths.
- Keep component styling contracts explicit.