Webbo3 Level 2 · JavaScript Development · Day 13 of 20

Forms, UX and Accessibility

The day you unplug your mouse. Validation people can actually act on, and an interface that works for everybody who visits it.

This is the lesson most bootcamps skip, and skipping it is why so much of the web is unusable for a lot of people. It is also, increasingly, a legal requirement, and it is one of the few things a junior developer can be noticeably better at than the team they join. An hour today is worth a great deal later.

1. The browser validates for free

<form novalidate>
  <label for="email">Email address</label>
  <input id="email" name="email" type="email" required
         autocomplete="email" aria-describedby="email-error">
  <p id="email-error" class="error" role="alert"></p>

  <label for="phone">Phone</label>
  <input id="phone" name="phone" type="tel" inputmode="numeric"
         pattern="[0-9]{11}" autocomplete="tel">

  <button type="submit">Create account</button>
</form>

The Constraint Validation API then lets you keep the browser's checking and replace only its wording, which is the best of both.

form.addEventListener('submit', (event) => {
  event.preventDefault();
  let firstBad = null;

  for (const field of form.elements) {
    if (!field.name) continue;
    const error = document.querySelector(`#${field.name}-error`);
    if (field.validity.valid) {
      field.removeAttribute('aria-invalid');
      if (error) error.textContent = '';
      continue;
    }
    field.setAttribute('aria-invalid', 'true');
    if (error) error.textContent = messageFor(field);
    firstBad = firstBad ?? field;
  }

  if (firstBad) { firstBad.focus(); return; }    // send them to the problem
  submit();
});

function messageFor(field) {
  if (field.validity.valueMissing) return `${label(field)} is required.`;
  if (field.validity.typeMismatch) return `That does not look like an email address.`;
  if (field.validity.patternMismatch) return `Enter 11 digits, no spaces.`;
  return 'Please check this field.';
}

Error messages that help

The test: does the message tell them what to do next? "Invalid" describes your code's opinion. "Enter 11 digits" describes their next action.

2. Unplug your mouse

3. The div-that-should-be-a-button

<!-- looks like a button. Is not one. -->
<div class="btn" onclick="save()">Save</div>

<!-- is a button -->
<button type="button" class="btn">Save</button>

That div cannot be focused with Tab, does not respond to Enter or Space, is not announced as a button by a screen reader, and shows no focus ring. To make it behave you would have to add tabindex="0", a role, and keyboard handlers for two keys: four things the <button> element already does. Use the right element and accessibility is mostly free.

4. Focus, and where it goes

When a modal opens, focus must go into it. When it closes, focus must go back to whatever opened it. Otherwise a keyboard user closes a dialog and finds themselves back at the top of the document with no idea where they are.

let lastFocused = null;

function openDialog() {
  lastFocused = document.activeElement;      // remember where we came from
  dialog.hidden = false;
  dialog.querySelector('button, [href], input, select, textarea')?.focus();
  document.addEventListener('keydown', onEscape);
}

function closeDialog() {
  dialog.hidden = true;
  document.removeEventListener('keydown', onEscape);
  lastFocused?.focus();                       // put them back
}

const onEscape = (event) => { if (event.key === 'Escape') closeDialog(); };

/* never this */
button:focus { outline: none; }

/* this */
button:focus-visible {
  outline: 3px solid #0a6e6e;
  outline-offset: 2px;
}

5. Telling a screen reader what changed

When you update the page with JavaScript, a sighted user sees it. A screen reader user is told nothing at all, because nothing was navigated to. A live region fixes that: anything that appears inside it is announced.

<!-- polite: waits for a pause. Right for search result counts -->
<p id="status" role="status" aria-live="polite"></p>

<!-- assertive: interrupts. Only for genuine errors -->
<p id="error" role="alert"></p>

status.textContent = `${results.length} students found`;

• The element must already be in the DOM when the page loads. Creating the live region and its content at the same moment announces nothing.
• role="status" waits for a natural pause. role="alert" interrupts, so save it for errors: an interface that interrupts constantly is unusable.

6. The ten-minute audit

Run this on every project you ship from now on. It is not comprehensive, and it catches most of what a beginner gets wrong.

1. Tab through it. Can you reach everything, in a sensible order, and always see where you are?
2. Every image: does the alt say what it shows, or is it alt="" because it is decorative? "image1.jpg" is worse than nothing.
3. Every input: does clicking its label focus the field? If not, for and id do not match.
4. Headings: h1 then h2 then h3, in order, no skipping. A screen reader user navigates by them the way you navigate by eye.
5. Colour contrast: 4.5:1 for body text, as you learned last month. DevTools shows you the ratio when you inspect a colour.
6. Colour alone: is any information conveyed only by colour? Add an icon or a word for the eight per cent of men who are colour blind.
7. Zoom to 200%. Does anything overlap or disappear?
8. Run Lighthouse. DevTools, Lighthouse tab, tick Accessibility. It is not the whole answer and it will find real problems.

Do this now

1. Do the keyboard audit on your project and write down every problem.
2. Fix them. Expect the list to include a div that should be a button, a missing label, and a removed focus ring.
3. Rewrite every validation message so it says what to do next.
4. Add a live region announcing your result count.
5. Run Lighthouse and get Accessibility above 95. Then read what it still complains about, because the last few points teach you the most.

Checkpoint

Tomorrow, Day 14: finding bugs instead of guessing at them, and the difference between code that works and code that is fast.