Session 2: Forms & Accessibility

A form is a collection of inputs inside a `<form>` element, with an action saying where the data goes and a method saying how. `POST` sends the data in the request body and is right for anything sensitive or that changes something; `GET` puts it in the URL, which is visible, bookmarkable and limited in length — fine for a search, wrong for a password.

Each input needs a `name`, because that is the key the data arrives under. An input without a name is invisible to the server however it looks on the page, which is a common and confusing bug: the form appears to work, the user types something, and nothing arrives.

Then the input types, which are not cosmetic. `type="email"` gives a phone an email keyboard and basic format checking. `type="tel"` gives a numeric pad. `type="date"` gives a date picker instead of a free-text box the user has to guess the format of. `type="password"` hides the characters. Using `type="text"` for everything works and is worse in every way, particularly on a phone, where the wrong keyboard is a real obstacle.

Every input needs a `<label>`, connected to it by matching `for` and `id` attributes. This is not a formality: the label is what a screen reader announces, it is what makes the field findable, and it makes the whole label clickable to focus the input — which matters enormously on a phone, where tapping a small checkbox is fiddly and tapping its label is easy.

The common wrong way is placeholder-as-label: an input with no label whose purpose is written in grey text inside it. It fails in three ways at once. The text disappears the moment someone starts typing, so they cannot remember what the field was for. It is usually too low-contrast to read comfortably. And some assistive technology does not announce it at all. Placeholder text is for examples — 'for example, 0803 000 0000' — never for labels.

Then the related requirements. Group related controls with `<fieldset>` and `<legend>` — a set of radio buttons needs a legend saying what the choice is about, because the individual options ('Yes', 'No') mean nothing alone. Mark required fields with `required`, which gives free browser validation. And for anything else, use `aria-describedby` to point at helper text so it is announced with the field rather than sitting nearby unseen.

Use a `<button>` for anything that does something. The two elements that look interchangeable are not: `<button type="submit">` inside a form submits it, `<button type="button">` does not submit and is for JavaScript actions, and `<a>` navigates somewhere. Styling a link to look like a button produces something a keyboard user activates differently and a screen reader announces wrongly.

Then do not disable the submit button while submitting without a way back. It is a well-meant pattern — prevent double submission — that traps people when the request fails, because the button stays disabled and there is no way to try again. Better: keep it enabled, show a loading state, and handle failure by telling the user what happened.

And tell the user what happened. A form that submits silently gives no confirmation, so people submit twice or assume it failed. Show a clear success message, and on error say which field is wrong and what to do about it — 'Email address is missing the @ symbol' rather than 'Invalid input'. Error messages that only mark a field red are useless to anyone who cannot see the colour.

A great many people cannot use a mouse — people with motor impairments, people using a screen reader, people whose mouse is broken. Everything must be reachable and operable with a keyboard alone, and the test takes thirty seconds: put your mouse down and tab through the page. If you cannot reach something, or reach it and cannot tell where you are, it is broken.

Three things make this work. Focus must be visible — the outline showing which element has focus must never be removed. `outline: none` is one of the most damaging lines of CSS there is, and it is usually added because someone thought the default outline was ugly. Restyle it; do not remove it. Tab order must be logical, following the visual order of the page; a tab order that jumps around is worse than none.

Then do not build interactive elements out of divs. A `<div onclick>` is invisible to a keyboard: it cannot be focused, cannot be activated with Enter or Space, and is not announced as a button. Use `<button>` and you get all of that for free. And provide a skip link at the top of the page so a keyboard user is not forced to tab through the entire navigation on every single page load — which for a site with twenty nav items is genuinely unusable.

Colour contrast is the most common failure and the easiest to check. Text needs a contrast ratio of at least 4.5:1 against its background for normal text and 3:1 for large text. Light grey on white — the aesthetic choice behind a great many modern sites — frequently fails badly and makes text unreadable for people with low vision, and for anyone in bright sunlight, which is most of Nigeria.

Never convey information by colour alone. 'Required fields are in red' tells a colour-blind user nothing, and 'errors are highlighted red' is invisible to them. Add a text indicator — an asterisk with an explanation, an icon, the word 'error' — so the meaning survives without the colour.

Then text that can be resized, meaningful link text, alt text on images, a page title that says what the page is, and a language declared on the `<html>` element so assistive technology pronounces it correctly. None of these is difficult. Together they are the difference between a site that most people can use and one that a significant minority cannot, and they cost minutes rather than hours if you do them as you build rather than retrofitting.