🧩 Custom Form Controls

Why (and Why Not) Go Custom

HTML's built-in controls are the result of decades of accessibility and usability work. A native <input type="checkbox"> already handles focus, keyboard toggling, screen-reader announcements, form submission, and the browser's high-contrast modes — none of which you had to write. So the first rule of custom controls is: be sure you actually need one.

Legitimate reasons include a design a native control can't produce (a sliding toggle, a star strip), an interaction the platform lacks (a tag/token input, a multi-thumb slider), or a widget that must look identical across every browser.

💡 An analogy: Custom controls are like bespoke furniture. A mass-produced chair is tested, comfortable, and cheap. A hand-built one can fit your room perfectly — but you're now responsible for the ergonomics, the joinery, and making sure nobody gets a splinter. Only commission the bespoke piece when the standard one truly won't fit.

Native vs. Custom Trade-offs

💡 Analogy: Native controls are a dependable commuter car — efficient and low-maintenance. A custom control is a modified vehicle: powerful and eye-catching, but it needs a mechanic who knows exactly what they're doing.

Progressive Enhancement

Progressive enhancement means starting from working HTML and layering improvements on top, so that if the JavaScript or CSS fails, the user still has a usable form. Build the native control first; enhance it second.

.visually-hidden {
  position: absolute;
  width: 1px; height: 1px;
  padding: 0; margin: -1px;
  overflow: hidden;
  clip: rect(0 0 0 0);
  white-space: nowrap;
  border: 0;
}

The Hidden-Input Pattern

The most robust custom-control technique keeps a real form control doing the data work while a styled interface sits on top. There are two flavors:

• Label-and-checkbox: a visually-hidden native <input> paired with a <label> you style. The browser handles state, keyboard, and submission — you just draw the skin with CSS (often no JS at all). Best for checkboxes, radios, and toggles.
• Hidden value + widget: an <input type="hidden"> holds the value, and JavaScript updates it as the user interacts with a fully custom widget. Best for star ratings, tags, and other things with no native equivalent.

Either way, the payoff is the same: form.submit(), FormData, validation, and reset all keep working, because a genuine form field is always present.

Widget 1: Toggle Switch (CSS-only)

A toggle switch is just a checkbox in a nicer coat. Because a real checkbox drives it, this needs zero JavaScript — the browser gives us focus, Space-to-toggle, and submission for free. The label wraps everything so clicking anywhere flips the state.

<label class="switch">
  <input type="checkbox" name="notifications" class="switch-input">
  <span class="switch-track"><span class="switch-thumb"></span></span>
  <span class="switch-text">Email notifications</span>
</label>

.switch { display: inline-flex; align-items: center; gap: .6rem; cursor: pointer; }

/* Hide the checkbox but keep it accessible & focusable */
.switch-input {
  position: absolute; opacity: 0;
  width: 1px; height: 1px;
}

.switch-track {
  width: 48px; height: 26px;
  background: #ccc; border-radius: 13px;
  position: relative; transition: background .2s;
}
.switch-thumb {
  position: absolute; top: 3px; left: 3px;
  width: 20px; height: 20px;
  background: #fff; border-radius: 50%;
  transition: transform .2s;
}

/* State driven entirely by the real checkbox */
.switch-input:checked + .switch-track { background: #16a34a; }
.switch-input:checked + .switch-track .switch-thumb { transform: translateX(22px); }

/* Focus ring for keyboard users */
.switch-input:focus-visible + .switch-track {
  outline: 3px solid rgba(37, 99, 235, .5); outline-offset: 2px;
}

Widget 2: Star Rating

There's no native "1–5 stars" control, so this one earns its custom status. The cleanest accessible approach is a radio group styled as stars — again mostly CSS — but here we'll show the hidden-value + role="radiogroup" approach to illustrate wiring ARIA and keyboard support by hand, since you'll meet that pattern constantly.

<div class="rating">
  <span id="rating-label">Rate your experience</span>
  <input type="hidden" name="rating" id="rating-value" value="0">
  <div class="stars" role="radiogroup" aria-labelledby="rating-label">
    <button type="button" class="star" role="radio"
            aria-checked="false" data-value="1" aria-label="1 star">★</button>
    <button type="button" class="star" role="radio"
            aria-checked="false" data-value="2" aria-label="2 stars">★</button>
    <button type="button" class="star" role="radio"
            aria-checked="false" data-value="3" aria-label="3 stars">★</button>
    <button type="button" class="star" role="radio"
            aria-checked="false" data-value="4" aria-label="4 stars">★</button>
    <button type="button" class="star" role="radio"
            aria-checked="false" data-value="5" aria-label="5 stars">★</button>
  </div>
</div>

The script keeps three things in sync: the hidden input's value, the visual fill, and the ARIA state — plus full arrow-key navigation, which is what a real radio group provides.

const group = document.querySelector('.stars');
const stars = [...group.querySelectorAll('.star')];
const hidden = document.querySelector('#rating-value');

function select(value) {
  hidden.value = value;
  stars.forEach(star => {
    const starValue = Number(star.dataset.value);
    star.classList.toggle('filled', starValue <= value);
    star.setAttribute('aria-checked', String(starValue === value));
    // Only the selected star stays in the tab order (roving tabindex)
    star.tabIndex = starValue === value ? 0 : -1;
  });
}

// Click to rate
stars.forEach(star => {
  star.addEventListener('click', () => {
    select(Number(star.dataset.value));
    star.focus();
  });
});

// Arrow keys move through the group, like native radios
group.addEventListener('keydown', (event) => {
  const current = Number(hidden.value) || 1;
  let next = current;
  if (event.key === 'ArrowRight' || event.key === 'ArrowUp')   next = Math.min(5, current + 1);
  if (event.key === 'ArrowLeft'  || event.key === 'ArrowDown') next = Math.max(1, current - 1);
  if (next !== current) {
    event.preventDefault();
    select(next);
    stars[next - 1].focus();
  }
});

// Make the first star reachable by Tab before any selection
stars[0].tabIndex = 0;

Widget 3: Tag Input

A tag (or token) input lets users build a list of short values — skills, keywords, recipients. There's no native equivalent, so this is a genuine custom widget. We store the final list in a hidden input as a comma-separated string for submission.

<div class="tags-field">
  <label for="tag-entry">Skills</label>
  <ul class="tag-list" id="tag-list"></ul>
  <input type="text" id="tag-entry"
         aria-describedby="tag-help" placeholder="Type and press Enter">
  <small id="tag-help">Press Enter or comma to add a tag. Backspace removes the last one.</small>
  <input type="hidden" name="skills" id="tag-value">
</div>

const entry = document.querySelector('#tag-entry');
const list = document.querySelector('#tag-list');
const hidden = document.querySelector('#tag-value');
const tags = [];

function sync() {
  hidden.value = tags.join(',');
}

function addTag(text) {
  const value = text.trim();
  if (!value || tags.includes(value)) return;   // no blanks or dupes
  tags.push(value);

  const li = document.createElement('li');
  li.className = 'tag';
  li.textContent = value;

  const remove = document.createElement('button');
  remove.type = 'button';
  remove.className = 'tag-remove';
  remove.setAttribute('aria-label', `Remove ${value}`);
  remove.textContent = '×';
  remove.addEventListener('click', () => removeTag(value));

  li.append(remove);
  list.append(li);
  sync();
}

function removeTag(value) {
  const index = tags.indexOf(value);
  if (index === -1) return;
  tags.splice(index, 1);
  list.children[index].remove();
  sync();
  entry.focus();
}

entry.addEventListener('keydown', (event) => {
  if (event.key === 'Enter' || event.key === ',') {
    event.preventDefault();
    addTag(entry.value);
    entry.value = '';
  } else if (event.key === 'Backspace' && entry.value === '' && tags.length) {
    removeTag(tags[tags.length - 1]);   // backspace on empty removes last
  }
});

skills=javascript,accessibility,css

Testing Custom Controls

A custom control isn't done when it looks right with a mouse. Run it through four checks:

• Keyboard only: unplug the mouse. Can you reach, operate, and leave the control? Are focus states visible? Do arrow keys behave like the native equivalent?
• Screen reader: test with VoiceOver, NVDA, or Narrator. Is the control's role, name, and state announced when focused and when it changes?
• Form integration: submit the form and inspect the payload. Is the value present and correct? Does reset clear it? Does pre-filling work?
• No-JS / failure: what happens if the script errors? With the hidden-input and label patterns, a native control should remain.

Hands-on Exercise

const group = document.querySelector('.stars');
const stars = [...group.querySelectorAll('.star')];
const hidden = document.querySelector('#rating-value');

function paint(value, className) {
  stars.forEach(star => {
    star.classList.toggle(className, Number(star.dataset.value) <= value);
  });
}

function commit(value) {
  hidden.value = value;
  stars.forEach(star => {
    const v = Number(star.dataset.value);
    star.classList.toggle('filled', v <= value);
    star.setAttribute('aria-checked', String(v === value));
    star.tabIndex = v === value ? 0 : -1;
  });
}

stars.forEach(star => {
  const value = Number(star.dataset.value);
  star.addEventListener('click', () => { commit(value); star.focus(); });
  // Hover preview — transient, never touches the committed value
  star.addEventListener('mouseover', () => {
    stars.forEach(s => s.classList.remove('preview'));
    paint(value, 'preview');
  });
});

group.addEventListener('mouseleave', () => {
  stars.forEach(s => s.classList.remove('preview'));
});

group.addEventListener('keydown', (event) => {
  const current = Number(hidden.value) || 1;
  let next = current;
  if (['ArrowRight', 'ArrowUp'].includes(event.key))   next = Math.min(5, current + 1);
  if (['ArrowLeft', 'ArrowDown'].includes(event.key))  next = Math.max(1, current - 1);
  if (next !== current) {
    event.preventDefault();
    commit(next);
    stars[next - 1].focus();
  }
});

stars[0].tabIndex = 0;

.star { color: var(--border-color); background: none; border: 0;
        font-size: 1.8rem; cursor: pointer; }
.star.filled  { color: #f59e0b; }   /* committed */
.star.preview { color: #fbbf24; }   /* transient hover */
.star:focus-visible { outline: 3px solid rgba(37,99,235,.5); outline-offset: 2px; }

Summary & Quiz

📚 Further Reading

• WAI-ARIA Authoring Practices Guide — patterns
• Inclusive Components — Heydon Pickering
• MDN — ARIA

🚀 What's Next?

You can now build widgets that look bespoke yet behave like first-class form controls. Next, Accessible Form Design pulls these threads together into a complete, inclusive form — labels, grouping, error handling, and focus management from start to submit.