Forms in HTML Templates: Styling Without Breaking Accessibility

Last year we ran an audit on a lead-gen form for a client in insurance. Fourteen axe violations on the page, eleven of them inside a single four-field form. The form looked immaculate: soft shadows, animated floating labels, custom pill checkboxes, a submit button that stayed greyed out until everything validated. It was also unusable with a keyboard, silent to a screen reader, and invisible in Windows High Contrast mode.

That’s the usual shape of the problem. Nobody breaks accessibility by writing bad HTML. They break it with form styling CSS: one appearance: none, one outline: 0, one placeholder doing a label’s job, and the form is gone for a chunk of your users while looking perfect in your screenshots.

The good news is that 2026 is the easiest year yet to style forms without resorting to ARIA gymnastics. accent-color, :focus-visible, :user-invalid and :has() are all boring and shippable now. Here’s how we build them on client work, including the parts that still don’t work.

The five things styling actually breaks

In order of how often we find them in purchased templates and handed-over codebases:

1. The focus ring. Somebody added *:focus { outline: none } to kill the Chrome ring on mouse click, then never added a replacement. Keyboard users get a form with no visible cursor position.
2. The label. Placeholder text replaces the label to save vertical space. Then the text vanishes on first keystroke, fails the 4.5:1 contrast most placeholder greys sit below, and doesn’t get translated by some browser translation paths.
3. The border contrast. A 1px #e5e7eb border on white is about 1.2:1. WCAG 1.4.11 wants 3:1 for the visual boundary of a control. Half the “clean minimal” form designs on Dribbble fail this.
4. The error signal. Red border, red text, no icon, no text change announced. Colour-only error states fail 1.4.1, and a message injected into the DOM without a live region is never spoken.
5. The submit button. Disabled until the form validates. A disabled button is removed from the tab order and announced as unavailable, so a screen reader user gets no path to find out what’s wrong.

That last one deserves a position: a submit button disabled until valid is almost always the wrong choice. Let people submit, then tell them precisely what failed. The only case where we keep it disabled is a destructive irreversible action behind a confirmation, and even then we use aria-disabled="true" plus a click handler that explains the blocker, so the control stays focusable.

A form styling CSS baseline that doesn’t fight the browser

This is roughly the block we start every project with. It’s short on purpose. The idea is to keep native behaviour and change only the paint.

:root {
  accent-color: #0b5fff;           / tints native checkbox, radio, range, progress /
  --field-border: #6b7280;         / 3.4:1 on white, passes 1.4.11 /
  --err: #b42318;
}

/ Inherit typography so inputs don't fall back to 13px Arial /
input, select, textarea, button { font: inherit; color: inherit; }

/ Below 16px, iOS Safari zooms the viewport on focus. max() keeps rem scaling intact. /
input, select, textarea { font-size: max(1rem, 16px); }

input:not([type="checkbox"], [type="radio"]), select, textarea {
  border: 1px solid var(--field-border);
  border-radius: .375rem;
  padding: .625rem .75rem;         / 44px total height at 16px text /
  background: #fff;
  min-height: 2.75rem;
}

/ Outline, not box-shadow: forced-colors mode discards shadows and keeps outlines /
:where(input, select, textarea, button, [tabindex]):focus-visible {
  outline: 2px solid #0b5fff;
  outline-offset: 2px;
  border-radius: .375rem;
}

/ Chrome's autofill yellow can't be overridden with background-color. This can. /
input:autofill {
  box-shadow: inset 0 0 0 100px #fff;
  -webkit-text-fill-color: #111;
}

Two details that earn their place. accent-color means you usually don’t need custom checkbox markup at all: you get the brand colour with native keyboard handling, native indeterminate state, and native forced-colors behaviour for free. And :focus-visible gives you the thing people were trying to achieve with outline: none in the first place. A ring for keyboard users, nothing for mouse clicks, without the collateral damage.

One tradeoff worth naming: outline-offset: 2px can get clipped by an ancestor with overflow: hidden. If your field sits inside a card with clipped overflow, either drop the offset to 0 and increase the outline width, or add overflow: visible on the immediate wrapper.

Labels, and the floating label trap

Every field needs a persistent visible label associated with for and id. That’s not negotiable and it’s not interesting. Floating labels are more interesting, because they look great in a Figma file and cause four specific problems in production.

First, the label sits at roughly 11px to 12px when floated, which fails contrast and readability for low-vision users at the exact moment they most need to confirm what they typed. Second, at 200% zoom the floated label frequently overlaps or truncates against the field value. Third, autofill fires without a reliable input event in some Chrome flows, so the label stays in its resting position behind the filled value until the user clicks. Fourth, hint text has nowhere to live, so people drop it and add a tooltip instead, which creates a 1.4.13 problem.

We still ship floating labels when a client insists. The version that survives looks like this:

.field { position: relative; }
.field label {
  position: absolute; inset-inline-start: .75rem; top: .75rem;
  transition: transform .15s, font-size .15s;
  transform-origin: left top;
  pointer-events: none;
}
/ :placeholder-shown and :autofill cover typed, autofilled and prefilled values /
.field:has(input:focus, input:not(:placeholder-shown), input:autofill) label {
  transform: translateY(-1.35rem) scale(.8);   / 12.8px floor at 16px base /
}

Note that this requires a placeholder=" " attribute on the input for :placeholder-shown to work, and that scale(.8) is the floor we use rather than a hardcoded small font-size, so it still scales with the user’s root font setting.

Custom checkboxes, radios and selects

If accent-color isn’t enough (you need a square checkbox, a specific tick weight, a 24px hit area), style the native input with appearance: none rather than hiding it behind a div. The hidden-input-plus-span pattern works until someone tabs through it, and it reliably breaks in forced-colors mode because the visual state lived in a background colour that got overridden.

.check input[type="checkbox"] {
  appearance: none;
  inline-size: 1.5rem; block-size: 1.5rem;   / 24px: WCAG 2.2 SC 2.5.8 minimum /
  border: 2px solid var(--field-border);
  border-radius: .25rem;
  display: grid; place-content: center;
}
.check input[type="checkbox"]::before {
  content: ""; inline-size: .9rem; block-size: .9rem;
  background: currentColor;
  clip-path: polygon(14% 44%, 0 65%, 50% 100%, 100% 16%, 80% 0%, 43% 62%);
  transform: scale(0); transition: transform .12s;
}
.check input[type="checkbox"]:checked { background: #0b5fff; border-color: #0b5fff; color: #fff; }
.check input[type="checkbox"]:checked::before { transform: scale(1); }

/ Give up gracefully where the OS owns the palette /
@media (forced-colors: active) {
  .check input[type="checkbox"] { appearance: auto; }
}

Selects are the stubborn one. appearance: base-select and a stylable ::picker(select) shipped in Chrome 135 and it’s genuinely good, but it’s still Chromium-only in early 2026, so treat it as progressive enhancement behind @supports (appearance: base-select) and make sure the unstyled native select is acceptable. Date inputs are similar: you can reach ::-webkit-calendar-picker-indicator in Chromium and almost nothing in Safari. If the design demands pixel-identical date pickers across browsers, that’s a build-a-combobox project with full keyboard and ARIA work, not a styling task. Price it accordingly.

Validation that actually gets announced

Native constraint validation bubbles aren’t stylable and they disappear on their own. So we set novalidate on the form, keep the constraint attributes (required, type="email", pattern, minlength) and read validity through the API.

<form id="quote" action="https://webforms.to/submit/YOUR_ID" method="post" novalidate>
  <div id="errors" class="error-summary" role="alert" tabindex="-1" hidden></div>

  <div class="field">
    <label for="email">Email address</label>
    <p id="email-hint" class="hint">We only use this to send your quote.</p>
    <input id="email" name="email" type="email" required
           autocomplete="email" inputmode="email" enterkeyhint="next"
           aria-describedby="email-hint email-error">
    <p id="email-error" class="error"></p>
  </div>

  <button type="submit">Get my quote</button>
</form>

The error paragraph stays in the DOM with empty text and stays referenced by aria-describedby at all times. If you toggle display: none on it, the reference is silently ignored by assistive tech and your careful message goes nowhere.

const form = document.querySelector('#quote');
const summary = document.querySelector('#errors');

form.addEventListener('submit', (e) => {
  const bad = [...form.elements].filter(el => el.willValidate && !el.checkValidity());
  form.querySelectorAll('.error').forEach(p => { p.textContent = ''; });
  form.querySelectorAll('[aria-invalid]').forEach(el => el.removeAttribute('aria-invalid'));

  if (!bad.length) return;                     // let it submit
  e.preventDefault();

  bad.forEach(el => {
    el.setAttribute('aria-invalid', 'true');
    const msg = document.getElementById(${el.id}-error);
    if (msg) msg.textContent = messageFor(el); // human text, not "Invalid input"
  });

  summary.innerHTML = <h2>There ${bad.length === 1 ? 'is 1 problem' : are ${bad.length} problems}</h2> +
    <ul>${bad.map(el => <li><a href="#${el.id}">${messageFor(el)}</a></li>).join('')}</ul>;
  summary.hidden = false;
  summary.focus();                             // tabindex="-1" makes this possible
});

The summary-with-links pattern comes out of the GOV.UK Design System and it’s held up better than anything else we’ve tried, especially on long forms where the first error is three screens above the submit button. Error text should name the fix, not the fault: “Enter an email address in the format [email protected]” beats “Invalid email” every time. The same reasoning we apply to 404 and 500 pages applies here. A failure state is a piece of copywriting with a CSS budget.

For inline feedback during typing, :user-invalid is the whole answer:

/ Only after the user has interacted and blurred. No red fields on page load. /
.field:has(:user-invalid) input { border-color: var(--err); border-width: 2px; }
.field:has(:user-invalid) .error { display: block; }

Mobile keyboards, zoom and WCAG 2.2

The cheapest accessibility win on any form is correct autocomplete tokens. They satisfy 1.3.5 Identify Input Purpose, they cut typing on mobile massively, and they’re one attribute: autocomplete="email", "tel", "postal-code", "cc-number", "one-time-code". Pair with inputmode="numeric" for digits that aren’t numbers (postcodes, card numbers, OTPs) so you get the numeric pad without the spinner.

Then check these four:

• Target size. 24 by 24 CSS pixels minimum for AA under 2.5.8, including the clickable label area. We use 44px for anything a thumb touches.
• Focus not obscured. 2.4.11. Sticky headers and cookie bars love to cover the field you just tabbed to. Add scroll-padding-block: 6rem on the scroll container.
• Redundant entry. 3.3.7. Don’t ask for the same data twice in a multi-step flow unless you’re confirming it on purpose, and prefill the second instance. Worth reading alongside our notes on reducing multi-step form abandonment.
• Zoom. Test at 200% and at 320px width. Two-column field grids need to collapse, and absolute-positioned labels need checking at both.

If you’re on a static site, the backend side can stay out of the way entirely. We use WebForms as the endpoint on a lot of brochure builds: it takes the POST, forwards to email or Slack, and leaves you with plain HTML markup to make accessible. One less server to reason about.

A twelve-minute test pass

Automated tools catch maybe a third of form issues. axe will flag a missing label; it won’t tell you the focus ring is invisible on a blue background. This is the manual pass we run before any form ships:

1. Unplug the mouse. Tab through every field, check every radio group with arrow keys, submit with Enter, trigger an error, and confirm the summary takes focus.
2. Zoom to 200% in Firefox. Nothing overlaps, nothing is cut off, no horizontal scroll.
3. Toggle forced-colors: active in DevTools rendering panel. Every checkbox, radio and focus ring must still be visible.
4. Turn on VoiceOver or NVDA, tab into one field, and listen. You should hear label, type, required state, hint. If you hear “edit text, blank”, your aria-describedby is broken.
5. Submit the form empty. Count how many seconds it takes to work out what to fix.
6. Check the border contrast of an unfocused input with a colour picker. 3:1 or it fails.

Step three catches the most bugs per minute. It’s the fastest way to find out whether your form’s state lives in CSS the OS is allowed to override.