Form Styling That Survives Production: Inputs, Selects, Checkboxes, Radios, Switches

December 5, 2025 • February 3, 2026 • Read: 15 min • Views: 7

Was this helpful?

The form looked perfect in the design review. Then production happened: iOS Safari “helpfully” zoomed the page, the select arrow vanished, checkboxes
became microscopic in Windows High Contrast, and your support queue got a new hobby.

Forms are where your brand meets the browser’s opinions. Your job is to ship controls that keep working when users crank up zoom to 200%, switch to dark mode,
use a keyboard, have flaky network, or run a corporate-managed browser from 2019 that nobody will upgrade because “it breaks SAP.”

Production goals: what “good” actually means

“Pretty” is cheap. “Stable” is expensive. “Stable and pretty” is a job.

Production-grade form styling has a small set of hard requirements. If you optimize for anything else first, you’ll be back here later with a bug titled
“checkbox disappears when user is left-handed” (and yes, it will be real).

Non-negotiables

Keyboard works everywhere: tab order, focus indicators, and activation via Space/Enter.
Readable at 200% zoom: no clipped text, no overlapping labels, no fixed-height traps.
High Contrast / forced colors does not break: controls remain visible and usable.
Mobile Safari behaves: no unexpected zooming on focus, no misaligned overlays, no “tap target too small.”
States are consistent: hover/focus/active/disabled/error must be predictable and not rely on color alone.
Validation is clear and forgiving: error messages appear in the right place, without layout chaos.
International text doesn’t explode: long labels, RTL, different numerals, different line breaks.

A guiding principle: keep the native control until you have a reason not to

Browsers ship decades of accessibility behavior inside native controls. When you replace a checkbox with a div, you inherit the entire responsibility:
semantics, focus, toggle behavior, pointer hit testing, screen reader announcements, forced color behavior, and more. That’s not “custom styling.” That’s
“writing a browser, but worse.”

So the sane default is: use native elements, style them with minimal surgery, and only go fully custom when you can test like you mean it.

Facts and history: why form controls are weird

These aren’t trivia night facts. They’re the reasons your forms behave differently on different machines, and why your CSS sometimes feels like a polite suggestion.

Native form controls are OS widgets in disguise. Historically, browsers delegated rendering to the operating system, which is why a select
on Windows never quite matches one on macOS.
The “appearance” wars: vendors introduced -webkit-appearance and friends to control native rendering. It helped… and also
created a decade of browser-specific hacks.
Mobile Safari zoom-on-focus is a legacy “feature”: if text is under a threshold (often 16px), iOS Safari may zoom to help readability.
It’s annoying, but it’s consistent enough to plan around.
Form controls have their own internal shadow DOM in many engines. Some pieces are styleable, some are not, and the boundaries differ by browser.
The :focus-visible selector is relatively recent. Before it, designers often removed focus outlines because they looked “ugly,”
and keyboard users paid the price.
Windows High Contrast mode predates modern “dark mode” trends. Forced colors can override your palette, so your custom UI needs explicit support.
Checkboxes and radios used to be basically unstyleable. Modern CSS (like accent-color) is the first time we’ve had a
mostly sane, standards-based approach.
Labels became clickable for usability, not aesthetics. Proper <label for> wiring is still one of the highest ROI form improvements.

Foundation: tokens, spacing, and the “boring” baseline

The best form styling work happens before you touch a checkbox. You decide how spacing behaves, how typography scales, and how state colors work in both light
and dark. This is SRE logic applied to UI: define invariants, then automate the enforcement.

Tokenize what matters, not what’s trendy

You want a small set of CSS custom properties that represent decisions, not implementation details. Think “control height,” “border radius,” “focus ring,”
not “blue-500.” Your color system can still exist, but the form system should reference semantic tokens.

Baseline rules that prevent 60% of incidents

Never hardcode heights for text inputs. Use padding + line-height. Fixed heights clip text at large font sizes.
Use box-sizing: border-box globally. Otherwise borders change layout, and validation states cause layout shift.
Reserve space for messages. A dynamic error message that pushes the layout down is not “responsive”; it’s chaos.
Focus ring is a first-class design token. Treat it like uptime.

Joke #1: Removing focus outlines is like turning off smoke detectors because the blinking light is annoying. The silence is not success.

Inputs and textareas that don’t betray you

Text inputs are where your typography meets the browser’s autofill, the password manager, and the user’s motor skills. You’re not styling a rectangle.
You’re negotiating with a swarm.

Do this: style the container, not the text node

A stable pattern is to wrap inputs in a container that owns the border, background, and focus ring. The input itself stays mostly “naked” and inherits
typography.

Benefit: consistent borders across input types.
Benefit: easier error states without reflow.
Benefit: you can place icons, spinners, and clear buttons without weird padding hacks.

Autofill: plan for it or it will style your form for you

Chrome’s autofill can apply a bright background color that ignores your theme. If you have dark mode, that’s a jump scare. Your job is not to fight it into
invisibility; it’s to integrate it so the user understands what happened.

Practical rule: make autofill readable, not identical. A subtle tint that works in your palette is fine. Fully hiding autofill often makes
the text unreadable in forced colors or creates contrast failures.

Input types: don’t assume the UI

type="date", type="number", and friends come with native UI that differs widely. Some are great. Some are… a mood. If your product
needs consistent UX across browsers, consider a specialized component. If you can accept native variability, keep it native and style lightly.

Textarea resizing: choose your poison explicitly

resize: vertical is often the best compromise. Users can expand, layout stays sane.
resize: none is acceptable only when you provide another mechanism (auto-grow) and test thoroughly.

Selects: style them lightly or pay the tax

Select controls are the most expensive place to be “creative.” Native selects involve OS pickers, accessibility behaviors, and sometimes separate rendering
paths. You can style the closed state somewhat; the open dropdown is frequently not yours.

The production recommendation

If you need a simple dropdown: use a native select and style the box. Keep the arrow if you can. If you must replace it, do it in a way
that doesn’t break forced colors.

If you need search, async loading, multi-select chips, grouped options, virtualization: you’re no longer styling a select. You’re building a combobox/listbox.
Accept the a11y work and the testing cost up front.

Failure mode: “custom select” that is actually a div

Div-based selects often fail in at least one of these:

Screen reader announces “group” or “clickable,” not “combobox.”
Keyboard navigation is partial or wrong.
Scroll locking breaks on iOS.
Focus gets trapped inside the menu.
High contrast makes the text and background the same color.

If you can’t test those conditions, don’t ship that component. It will become a slow-burn incident: not a single outage, but a constant stream of user failures.

Checkboxes and radios: custom look, native behavior

A checkbox is deceptively simple. It’s also one of the highest accessibility leverage points in a product. Users rely on predictable toggle behavior and large
hit areas. You should too.

Modern default: `accent-color` is your friend

For many products, accent-color gets you 80% of the brand feel with 20% of the risk. It keeps the control native, preserves forced-colors behavior
better, and generally plays nicely with OS settings.

Where it falls short: if you need a fully custom shape, complex animations, or pixel-perfect alignment across platforms. That’s where you either accept native
variation or you build a custom control with real semantics.

If you go custom, keep the input in the DOM

The production-safe pattern is: visually hide the native input (not display:none), style a sibling element, and use the input’s state selectors:
:checked, :focus-visible, :disabled.

Key detail: “visually hidden” must still allow focus. If your input is not focusable, keyboard users are gone. Also, keep the label clickable and generous.
The checkbox box should not be the only target.

Radios: communicate exclusivity

Radios are mutually exclusive by name group. Styling should reinforce that: consistent spacing, clear selected state, and ideally a group label. Don’t present
radios like independent toggles. Users will interpret them as “multiple allowed.”

Switches: when to use them and how not to lie

Switches are for immediate, binary, reversible actions. Think “Enable notifications,” not “Delete account.” If the change requires confirmation or has delayed
effect, a switch is misleading.

Switch semantics: checkbox, not magic

Most “switch” UI should be implemented as a checkbox with switch styling. Why: the semantics match, and the accessibility behaviors are well understood.
If you implement a switch as a button, you will need to manage pressed state, announcements, and keyboard toggling carefully.

Joke #2: A custom switch without keyboard support is like a data center door with a “Pull” sign printed on the wall. It looks official, but you’re still locked out.

States and validation: error, disabled, loading, success

Most form incidents aren’t caused by the “normal” state. They’re caused by transitions: error appears, button disables, spinner shows, label moves, and the page
jumps. Users interpret that as broken.

Validation rules that keep you out of trouble

Show errors next to the field, not only as a banner. Banners are great for summaries, terrible for navigation.
Do not rely on red alone. Add icons, text, and consistent placement.
Reserve space for helper/error text. If you can’t reserve, at least animate height to reduce jumpiness.
Keep the border width constant. Change color, not thickness, or your layout will shift.
Disabled is a state, not a style. Use disabled attribute where appropriate, not just grey paint.

Loading states: don’t block typing

The classic mistake: you show a spinner inside an input and disable the field during async validation. Users keep typing, nothing happens, and now you’ve trained
them to distrust the UI. Prefer optimistic typing with deferred validation, or validate on blur with clear messaging.

Accessibility isn’t charity. It’s engineering discipline. If your form control breaks under keyboard navigation, that’s not a “nice-to-have bug.” That’s a user
who cannot complete a workflow. In production terms, it’s a partial outage.

Focus indicators: use `:focus-visible` and don’t get cute

Use a visible outline or ring with enough contrast. Avoid relying on box-shadow alone in forced colors. If you’re using a container-based focus ring, ensure
it triggers when the input receives focus.

Forced colors: support `forced-colors: active`

In Windows High Contrast / forced colors, the browser may override your colors and backgrounds. Your job is to avoid hiding controls and to respect system colors.
That usually means: don’t depend on background images for essential UI (like a select arrow or checkbox checkmark).

One quote, because it’s still true

“Hope is not a strategy.” — General Gordon R. Sullivan

Performance and resilience: CSS, fonts, and layout shift

In forms, performance issues often show up as: delayed font load causing text reflow, focus ring lag on low-end devices, and layout shift when validation
messages appear. That’s UX debt that converts directly into abandonment.

Fonts: don’t let them DOS your layout

If a webfont swaps late, input text width changes mid-typing. It feels like the caret is haunted. Prefer font-display strategies and select fallback fonts with
similar metrics. Also: make sure line-height is stable.

Layout shift: reserve space for messages and icons

If you inject a “valid” icon, reserve the space in the layout from the start. If you inject an error message, reserve the line. Avoid transitions that change
height abruptly. This is the UI version of noisy neighbor: everyone feels it.

Three corporate mini-stories from the trenches

Mini-story #1: the incident caused by a wrong assumption

A B2B product shipped a redesigned billing form. The team assumed the browser would keep default behavior for numeric fields, so they used
input type="number" for credit card and invoice IDs. It worked in their Chrome-heavy testing.

Then a chunk of customers started reporting “I can’t type my card number.” Not “it looks wrong.” Literally: can’t type. The issue reproduced on iOS Safari:
the numeric keyboard showed, but the field rejected spaces and leading zeros, and it also applied locale formatting in unexpected ways. In some cases, it
displayed scientific notation when pasted values were long.

Support escalated it as “payments down,” which was not technically accurate but emotionally correct. The ops on-call dug through error logs and found nothing:
the request never arrived. The form couldn’t be completed.

The fix was mundane: switch those fields to type="text" with appropriate inputmode and validation. They also added a Playwright test
that pastes a long card-like string on WebKit. The lesson wasn’t “Safari is bad.” The lesson was: browser input types have semantics, and you don’t get to
redefine them with CSS.

Mini-story #2: the optimization that backfired

A team tried to improve performance by removing “unnecessary” DOM nodes. They flattened their form field component: no wrapper, no helper-text container, fewer
elements. It looked clean in the inspector and shaved a tiny amount of HTML.

Two sprints later, they rolled out inline validation. Errors now appeared by inserting a new element after the input. On slow devices, the layout shifted every
time an error toggled. Users would click “Submit,” see an error appear, and the submit button would jump under their cursor. Some users double-clicked and ended
up submitting twice once the form became valid.

The bug reports were weird: “The app clicks the wrong thing.” That’s the kind of report that ruins your week, because it sounds like user error until you
reproduce it on a budget Android phone with 200% font scaling.

They reintroduced a stable helper-text area with reserved height, and the problem disappeared. The performance win was imaginary; the conversion loss was real.
Optimization that removes structure often removes predictability.

Mini-story #3: the boring but correct practice that saved the day

A company with a design system enforced a rule: every form control must pass a “four-mode matrix” in CI screenshots—light, dark, forced-colors, and 200% zoom.
It wasn’t glamorous. Engineers grumbled. Designers rolled their eyes. Then it paid for itself.

A routine dependency update changed how focus outlines were drawn in one browser. Their custom checkbox used a pseudo-element for the checkmark and removed the
native appearance. In forced-colors mode, the checkmark became invisible because it was implemented as a background image.

The CI screenshot diff caught it the same day. No support tickets, no silent failure. The fix was to render the checkmark using borders (or to keep the native
checkmark via accent-color) and to add a forced-colors override that respects system colors.

Nobody wrote a postmortem because nothing broke in production. That’s the point. The boring practice did its job: it prevented an accessibility outage that
would have quietly harmed a set of users who already deal with enough friction.

Hands-on tasks: commands, outputs, and decisions

Styling forms “in theory” is how you end up with a checkbox that works only on your laptop. These tasks are the operational side: inspect what’s shipped,
reproduce the environment, and make decisions based on concrete signals.

Task 1: Find which CSS files actually ship to production

cr0x@server:~$ ls -lh dist/assets/*.css | head
-rw-r--r-- 1 deploy deploy  54K Dec 29 10:12 dist/assets/app-3c1f2a.css
-rw-r--r-- 1 deploy deploy  12K Dec 29 10:12 dist/assets/vendor-9a22be.css

What it means: you have at least two CSS bundles; form styles might be split across them.

Decision: when debugging, grep both bundles; don’t assume “app.css” contains the component styles.

Task 2: Check if you’re relying on unsupported selectors for older browsers

cr0x@server:~$ rg -n ":has\(|:focus-visible|accent-color" dist/assets/*.css | head
dist/assets/app-3c1f2a.css:2148:.field:has(input:focus-visible){outline:2px solid var(--ring);}
dist/assets/app-3c1f2a.css:3880:input[type=checkbox]{accent-color:var(--accent);}

What it means: you’re using :has() and :focus-visible; support varies by browser and version.

Decision: ensure a fallback path exists (e.g., :focus styling) and confirm your browser support matrix supports :has() usage.

Task 3: Confirm whether High Contrast / forced colors overrides are present

cr0x@server:~$ rg -n "forced-colors|prefers-contrast" src/styles -S
src/styles/forms.css:201:@media (forced-colors: active) {
src/styles/forms.css:202:  .field { forced-color-adjust: auto; }

What it means: you at least considered forced colors and didn’t globally opt out.

Decision: keep forced-color-adjust: none usage extremely limited; only use it when you reimplement equivalent contrast-safe styling.

Task 4: Check for “outline: none” landmines

cr0x@server:~$ rg -n "outline:\s*none" src -S
src/styles/reset.css:88:button:focus{outline:none;}
src/styles/forms.css:146:input:focus{outline:none;}

What it means: focus indicators were explicitly removed in at least two places.

Decision: replace with :focus-visible rings or outlines; do not ship without a keyboard-visible focus state.

Task 5: Identify whether selects are being “fully custom” (high risk)

cr0x@server:~$ rg -n "select\{|appearance:\s*none|::-ms-expand" src/styles -S
src/styles/forms.css:312:select{appearance:none;background-image:var(--select-arrow);}
src/styles/forms.css:329:select::-ms-expand{display:none;}

What it means: you’re removing native appearance and injecting an arrow, plus carrying old IE/Edge Legacy hacks.

Decision: test forced-colors and zoom; ensure the arrow isn’t the only affordance and that the control remains recognizable.

Task 6: Confirm minimum font-size in inputs to prevent iOS zoom

cr0x@server:~$ rg -n "input\{|font-size" src/styles/forms.css -n
112:input, textarea, select { font-size: 16px; line-height: 1.25; }

What it means: inputs are at 16px; iOS Safari is less likely to zoom on focus.

Decision: keep it; if design wants smaller text, use 16px for the input and adjust surrounding UI, not the input font.

Task 7: Detect layout shift risk from validation styles

cr0x@server:~$ rg -n "border:\s*[0-9]+px|border-width" src/styles/forms.css
165:.field{border:1px solid var(--border);}
178:.field.is-error{border:2px solid var(--danger);}

What it means: error state increases border thickness, likely causing layout shift.

Decision: keep border width constant; use color and an outer ring for emphasis.

Task 8: Verify that inputs have associated labels (server-rendered HTML check)

cr0x@server:~$ node -e "const fs=require('fs');const html=fs.readFileSync('dist/index.html','utf8');console.log((html.match(/]+for=/g)||[]).length,'labels-with-for');console.log((html.match(/

What it means: not every input necessarily has a label for association.

Decision: audit the missing ones; if you’re using aria-label, ensure it’s intentional and consistent (and not a patch for missing markup).

Task 9: Check whether any inputs are accidentally hidden from assistive tech

cr0x@server:~$ rg -n "aria-hidden=\"true\"|role=\"presentation\"" dist/index.html
152:

What it means: a real control is hidden from screen readers. That’s almost always wrong.

Decision: remove aria-hidden from interactive controls; if you need custom visuals, hide the decoration, not the input.

Task 10: Use Lighthouse CI output to catch contrast and label issues

cr0x@server:~$ npx lighthouse http://localhost:4173 --only-categories=accessibility --quiet
Performance: 0.92
Accessibility: 0.86
Best Practices: 0.96
SEO: 1.00

What it means: accessibility score is lagging; form labels/contrast/focus are common offenders.

Decision: open the report and fix the concrete failures; don’t “chase score,” chase the specific broken controls.

Task 11: Run Playwright against WebKit to catch Safari-style regressions

cr0x@server:~$ npx playwright test --project=webkit tests/forms.spec.ts
Running 12 tests using 1 worker
✓ 12 passed (28.4s)

What it means: your forms pass on WebKit, which catches a class of “works in Chrome” assumptions.

Decision: keep WebKit in CI for form-heavy apps; it’s cheaper than a support escalation.

Task 12: Verify tap target sizes via axe-core in CI

cr0x@server:~$ npx axe http://localhost:4173/settings --tags wcag2a,wcag2aa
axe ran against 1 page, found 2 violations
1) Targets must be at least 24px by 24px
2) Form elements must have labels

What it means: your checkbox/radio hit areas are too small and some controls lack labels.

Decision: increase label padding/click area; wire labels properly; treat this as a release blocker for form workflows.

Task 13: Confirm CSS specificity is not a war zone

cr0x@server:~$ node -e "const fs=require('fs');const css=fs.readFileSync('dist/assets/app-3c1f2a.css','utf8');const matches=[...css.matchAll(/!important/g)].length;console.log('!important count:',matches);"
!important count: 37

What it means: you have 37 !important uses; that’s often a smell for inconsistent component boundaries.

Decision: audit form-related ones; replace with sane component layering and predictable selectors before the next redesign multiplies the count.

Fast diagnosis playbook

When form styling breaks in production, you don’t have time for a philosophical discussion about CSS purity. You need a fast path to “what changed” and “what’s
actually broken.”

First: is it a semantics problem or a paint problem?

Check keyboard: can you tab to the control and toggle it with Space/Enter?
Check label wiring: clicking the label toggles checkbox/radio or focuses input.
Check screen reader announcement: control type and state are announced correctly.

If semantics are broken, stop styling and fix markup/ARIA. CSS won’t rescue missing semantics.

Second: is it environment-specific?

Repro on WebKit (Safari), Chromium, and Firefox.
Repro with 200% zoom and increased font size.
Repro in forced colors / high contrast.
Repro with dark mode.

If it breaks only in forced colors or zoom, your issue is almost always: hidden native appearance, background-image affordances, or fixed sizing.

Third: find the regression boundary

Diff the CSS bundle between last good and current.
Check for reset changes: appearance, outline, line-height, box-sizing.
Check for dependency updates in UI libraries and CSS tooling.

Most form regressions are introduced by “harmless” global CSS changes. Treat resets like production infrastructure. You don’t casually rewrite routing tables;
don’t casually rewrite focus behavior either.

Common mistakes: symptoms → root cause → fix

1) Symptom: keyboard users can’t see where they are

Root cause: outline: none removed; no :focus-visible replacement.

Fix: restore focus outlines or implement a ring on :focus-visible. Ensure it meets contrast requirements and works in forced colors.

2) Symptom: page zooms when tapping an input on iPhone

Root cause: input font-size under 16px triggers iOS Safari zoom-on-focus behavior.

Fix: set input/select/textarea font-size to 16px; adjust surrounding UI rather than shrinking input text.

3) Symptom: select arrow disappears in High Contrast

Root cause: arrow rendered as background-image; forced colors remove backgrounds or override colors.

Fix: keep native appearance when possible; otherwise render arrow with borders/SVG that respects forced colors, and test @media (forced-colors: active).

4) Symptom: error state causes fields to “jump”

Root cause: border width changes or helper text is inserted without reserved space.

Fix: keep border width constant; reserve helper/error area height; use an outer ring for emphasis.

5) Symptom: checkbox toggles only when clicking the tiny box

Root cause: label not associated; click target limited to the input element.

Fix: use <label for> or wrap input in label; add padding to label to meet tap target guidance.

6) Symptom: custom checkbox looks fine but is silent to screen readers

Root cause: the real input is display:none or aria-hidden; visual element has no semantics.

Fix: keep the native input focusable (visually hidden pattern); style sibling; ensure name/role/state remain native or correctly implemented ARIA.

7) Symptom: placeholder text is too light in dark mode

Root cause: placeholder color not tokenized; insufficient contrast; autofill/UA styles override.

Fix: define placeholder token; test against actual background; avoid extremely low contrast placeholders.

8) Symptom: radio group acts like multiple selection

Root cause: radios missing shared name; or custom component implemented as independent toggles.

Fix: ensure radios share a name; provide a group label; if custom, use correct role patterns.

9) Symptom: text gets clipped at large font sizes

Root cause: fixed height, tight line-height, or vertical centering hacks.

Fix: use padding + line-height; avoid fixed heights; test at 200% zoom and increased font settings.

Checklists / step-by-step plan

Checklist: building a production-safe form control

Start with native element (input, select, textarea).
Wire label with for/id or wrapping label pattern.
Define states: default, hover, focus-visible, active, disabled, error, success, loading.
Keep border width constant; use outer ring for emphasis.
Guarantee minimum tap target via label padding and layout.
Test zoom and font scaling; ensure no clipping.
Test forced-colors; ensure affordances aren’t background images only.
Test keyboard navigation; ensure focus is visible and activation works.
Test autofill in Chrome and password managers; ensure text is readable.
Snapshot in CI across light/dark/forced-colors/zoom.

Step-by-step plan: hardening an existing form styling system

Inventory controls: list every input type used in production (text, email, password, date, number, search, file, textarea, select,
checkbox, radio, switch).
Pick a baseline strategy: native-first with accent-color for check/radio, minimal select styling, wrapper-based focus rings.
Eliminate global hazards: remove/replace blanket outline: none, aggressive resets on appearance, and fixed heights.
Implement a state contract: consistent classes/data-attributes that represent state without increasing specificity wars.
Add forced-colors support: start by removing background-image dependence for essential affordances.
Automate verification: Playwright WebKit + axe checks + screenshot matrix.
Set a regression gate: treat form breakage as a release blocker for workflows that affect revenue or access.

FAQ

1) Should we fully custom-style every control to match the brand?

No. Brand consistency is not worth breaking accessibility or platform conventions. Style the container, typography, spacing, and focus ring; keep native behavior.

2) Is `accent-color` good enough for checkboxes and radios?

Often yes. It gives you brand tinting while preserving native semantics. If you need a bespoke shape/animation, you’ll need a custom pattern and much heavier testing.

3) Why does styling `<select>` feel harder than everything else?

Because much of the select UI is delegated to OS-level widgets or engine-internal rendering. You can style the closed control; the open list is frequently not yours.

4) When should a “switch” be a checkbox vs a button?

If it represents a persistent on/off setting, implement it as a checkbox (styled as a switch). Use a button for actions, not states.

5) How do we stop iOS Safari from zooming on input focus?

Keep input font size at 16px or greater. Avoid trying to hack around it with viewport tricks; you’ll create worse issues.

6) Do we need to support forced-colors mode if our user base is “mostly” not using it?

Yes, if you sell to enterprises or public sector, and honestly yes even if you don’t. Forced-colors failures are silent outages: the user can’t proceed, and you may never know.

7) Is it okay to hide the native checkbox and draw our own?

It can be, but only if the native input remains focusable and present for assistive tech. “Visually hidden” is not the same as display:none.

8) What’s the most common root cause of “works in Chrome, broken in Safari” for forms?

Overreliance on appearance: none without careful testing, plus font sizing and layout assumptions that Safari handles differently.

9) How do we keep validation messages from causing layout shift?

Reserve space for helper/error text in your layout. Keep borders constant width. Avoid inserting elements that change control size mid-interaction.

10) What’s a sane minimal test matrix for form controls?

Chromium + Firefox + WebKit, each with light/dark; add forced-colors and 200% zoom at least for your critical form pages. Automate screenshots and axe checks.

Next steps you can ship this week

Remove “outline: none” and replace it with :focus-visible rings that work in forced colors.
Set input font-size to 16px to prevent iOS zoom surprises.
Stop changing border widths for errors; use color and outer rings to avoid layout shift.
Adopt accent-color for checkbox/radio where possible; keep native semantics.
Add one CI gate: Playwright WebKit + axe on your top 3 form workflows.
Run the four-mode screenshot matrix: light, dark, forced-colors, 200% zoom. Make it routine, not heroic.

Forms are not where you prove your creativity. Forms are where you prove your reliability. Ship the boring correctness first—then add polish where it won’t
create a new class of outages.