{"id":"l-a11y-2-3","courseId":"web-accessibility","lang":"en","kind":"lesson","summary":"Build a checkout form where every field has a label, related options are grouped, browsers can autofill, and errors are announced and fixable without sight.","html":"

Ticketly loses a quarter of its customers at checkout, and the analytics can’t say why. Run the form with a screen reader and the reason is obvious: the fields announce “edit text, edit text, edit text”, the ticket-type radios announce “Standing, radio button” with no question, and when payment fails a red border appears that nobody without sight can perceive. Forms are where accessibility turns directly into money.

\n

Every field gets a label

\n

A <label> connected to an input does three things: it gives the field its accessible name, it shows sighted users what to type even after they start typing, and it makes the label text clickable, which enlarges the target.

\n
ticketly/checkout.html
<label for=\"full-name\">Full name</label>\n<input id=\"full-name\" name=\"fullName\" autocomplete=\"name\">\n\n<label>\n  Email\n  <input type=\"email\" name=\"email\" autocomplete=\"email\" required>\n</label>
\n

Both forms work: for pointing at an id, or the input nested inside the label. You can confirm the link in the console: document.querySelector('#full-name').labels.length should be 1.

\n\n

Group related choices

\n

Radio buttons and checkboxes have two layers of meaning: each option, and the question they answer together. <fieldset> and <legend> carry the question:

\n
HTML
<fieldset>\n  <legend>Ticket type</legend>\n  <label><input type=\"radio\" name=\"ticket\" value=\"standing\"> Standing</label>\n  <label><input type=\"radio\" name=\"ticket\" value=\"seated\"> Seated</label>\n  <label><input type=\"radio\" name=\"ticket\" value=\"vip\"> VIP lounge</label>\n</fieldset>
\n

When focus enters the group, NVDA reads “Ticket type, grouping, Standing, radio button, not checked, 1 of 3”. Use the same pattern for a billing address block or a set of “notify me by” checkboxes.

\n

Help people and browsers fill it in

\n

Two attributes save a lot of typing, which matters most to people with motor or memory impairments.

\n

The right type brings up the right keyboard on phones and gives basic validation: type="email", type="tel", inputmode="numeric" for a card number.

\n

The autocomplete attribute declares what the field is for, so the browser can fill it from saved data. WCAG 1.3.5 Identify Input Purpose (AA) requires it for fields about the user. Common tokens: name, given-name, family-name, email, tel, street-address, postal-code, country, cc-name, cc-number, cc-exp, cc-csc, username, current-password, new-password.

\n

Mark required fields with the required attribute, which screen readers announce, and with visible text such as “(required)”, not only an asterisk. And don’t ask twice: if the user typed their email at step 1, prefill it at step 3 (3.3.7 Redundant Entry).

\n

Errors people can find and fix

\n

This is where most forms fail. A good error has four parts, and the diagram shows how they connect:

\n
\n A label element gives the input its name through the for attribute. The input carries aria-invalid true, and aria-describedby points to a hint and an error message, which become its description. Focus moves to the input after a failed submit.\n \n <label for>\n \n <input>\n aria-invalid=\"true\"\n \n Hint text\n \n Error message\n \n name\n \n \n described by\n focus lands here on error\n
The parts of an accessible field
\n
    \n
  1. Say which field is wrong, in text (3.3.1 Error Identification).
    2. \n
  2. Say how to fix it (3.3.3 Error Suggestion): “Enter an email address like name@example.com”, not “Invalid input”.
    3. \n
  3. Connect it programmatically: aria-invalid="true" on the field and aria-describedby pointing at the message.
    4. \n
  4. Move focus to the first invalid field (or to an error summary at the top for long forms) so the user lands on the problem.
    5. \n
\n
HTML
<label for=\"email\">Email</label>\n<input id=\"email\" type=\"email\" autocomplete=\"email\" required>\n<p id=\"email-error\" class=\"error\" hidden></p>
\n
ticketly/checkout.js
const form = document.querySelector('#checkout');\nconst email = form.querySelector('#email');\nconst error = form.querySelector('#email-error');\n\nform.addEventListener('submit', (event) => {\n  if (email.value.includes('@')) {\n    email.removeAttribute('aria-invalid');\n    email.removeAttribute('aria-describedby');\n    error.hidden = true;\n    return;\n  }\n  event.preventDefault();\n  error.textContent = 'Enter an email address like name@example.com';\n  error.hidden = false;\n  email.setAttribute('aria-invalid', 'true');\n  email.setAttribute('aria-describedby', 'email-error');\n  email.focus();\n});
\n

The form uses novalidate in Ticketly’s markup (<form id="checkout" novalidate>) so this custom message replaces the browser’s built-in bubble, which varies between browsers and disappears quickly. That is a common choice; keeping native validation is also fine if you are happy with its messages.

\n\n

For a long form with several errors, add an error summary at the top: a heading such as “There are 2 problems”, followed by a list of links, each pointing to the field it describes (<a href="#email">Enter an email address</a>). Move focus to the summary after a failed submit. Users hear how many problems there are, and each link takes them straight to a field.

\n

Validate on submit or when the user leaves a field, not on every keystroke. Shouting “invalid email” while someone is still typing the first letters is noise for everyone and a flood of announcements for screen reader users.

\n

Ticketly’s forms now speak clearly. The last piece of Section 2 covers content that isn’t text at all: images, icons and the data tables on the pricing page.

\n","toc":[{"id":"sec-1","text":"Every field gets a label","level":2},{"id":"sec-2","text":"Group related choices","level":2},{"id":"sec-3","text":"Help people and browsers fill it in","level":2},{"id":"sec-4","text":"Errors people can find and fix","level":2}],"takeaways":["Every input needs a programmatic label; a placeholder disappears on typing and is not a reliable name.","Group radio buttons and checkboxes in a fieldset whose legend asks the question.","Autocomplete tokens such as name, email and cc-number let browsers fill fields and satisfy 1.3.5 Identify Input Purpose.","On an error, set aria-invalid, connect the message with aria-describedby, describe how to fix it, and move focus to the first invalid field."],"further":[{"title":"W3C WAI: Forms Tutorial","url":"https://www.w3.org/WAI/tutorials/forms/"},{"title":"MDN: HTML autocomplete attribute","url":"https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete"},{"title":"MDN: The Fieldset element","url":"https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/fieldset"}],"quiz":[{"q":"

What does a screen reader announce when focus reaches this field?

\n
HTML
<input type=\"email\" id=\"email\" placeholder=\"Email\">
\n","options":[{"text":"“Email, edit text” in most browsers, until the user types, and then the cue on screen is gone","why":"Correct. Browsers fall back to the placeholder as a name, but once the user types the visual hint vanishes, and some tools don’t use it. A real label fixes both."},{"text":"“Edit text” with no name in every browser and screen reader","why":"Most browsers do use the placeholder as a last-resort name. The problem is that it is fragile and disappears visually, not that it is always silent."},{"text":"“Email, required, edit text”","why":"Nothing marks the field as required. That needs the required attribute."}],"answer":0},{"q":"

Ticketly asks “Ticket type” with three radio buttons. How should the question be marked up?

","options":[{"text":"A paragraph with the question text above the radios","why":"A paragraph isn’t programmatically tied to the radios, so moving into the group doesn’t announce the question."},{"text":"A fieldset containing the radios, with a legend that says “Ticket type”","why":"Correct. Screen readers announce the legend when focus enters the group, so users hear “Ticket type, grouping, Standing, radio button, 1 of 3”."},{"text":"An aria-label=“Ticket type” on each radio button","why":"That replaces each option’s own name, so every radio would be announced as “Ticket type” and users couldn’t tell them apart."}],"answer":1},{"q":"

After a failed submit, which change helps a screen reader user most?

","options":[{"text":"Turning the invalid field’s border red","why":"Colour alone isn’t perceivable to screen reader users or many color-blind users, and it fails 1.4.1 Use of Color."},{"text":"Showing a toast “Form has errors” for three seconds","why":"A short-lived toast far from the field is easy to miss and doesn’t say which field is wrong or how to fix it."},{"text":"Setting aria-invalid on the field, linking the message with aria-describedby, and moving focus to the field","why":"Correct. Focus lands on the problem, and the screen reader reads “Email, invalid entry, Enter an email address like name@example.com”."}],"answer":2},{"q":"

Which autocomplete value is correct for the cardholder’s name on Ticketly’s payment step?

","options":[{"text":"autocomplete="name"","why":"name is for the user’s own full name. It may fill correctly by luck, but the token for the name on a card is more specific."},{"text":"autocomplete="cc-name"","why":"Correct. cc-name is the token for the name printed on the payment card, alongside cc-number, cc-exp and cc-csc."},{"text":"autocomplete="on"","why":"on lets the browser guess but declares no purpose, so it doesn’t meet 1.3.5 Identify Input Purpose."}],"answer":1}],"exercise":{"kind":"web","mode":"dom","starter":{"html":"
\n \n \n \n\n

Ticket type

\n Standing\n Seated\n\n \n
","css":"form { display: grid; gap: 6px; max-width: 320px; }\ninput:not([type=\"radio\"]) { font: inherit; padding: 6px 8px; border: 1px solid #77708f; border-radius: 6px; }\nfieldset { border: 1px solid #c9c4dc; border-radius: 8px; padding: 8px 12px; }\n.error { color: #b3261e; margin: 0; }\n[aria-invalid=\"true\"] { border-color: #b3261e; border-width: 2px; }\nbutton { justify-self: start; font: inherit; padding: 8px 16px; border-radius: 8px; border: 0; background: #5b3cc4; color: #fff; }\n","js":"const email = document.querySelector('#email');\nconst error = document.querySelector('#email-error');\n\n// The playground blocks real form submission, so validation runs on the\n// submit button's click. That click also fires when Enter is pressed in a field.\ndocument.querySelector('#pay').addEventListener('click', (event) => {\n event.preventDefault();\n if (email.value.includes('@')) {\n error.hidden = true;\n return;\n }\n error.textContent = 'Enter an email address like name@example.com';\n error.hidden = false;\n});\n"},"solution":{"html":"
\n \n \n \n \n \n\n
\n Ticket type\n \n \n
\n\n \n
","css":"form { display: grid; gap: 6px; max-width: 320px; }\ninput:not([type=\"radio\"]) { font: inherit; padding: 6px 8px; border: 1px solid #77708f; border-radius: 6px; }\nfieldset { border: 1px solid #c9c4dc; border-radius: 8px; padding: 8px 12px; }\n.error { color: #b3261e; margin: 0; }\n[aria-invalid=\"true\"] { border-color: #b3261e; border-width: 2px; }\nbutton { justify-self: start; font: inherit; padding: 8px 16px; border-radius: 8px; border: 0; background: #5b3cc4; color: #fff; }\n","js":"const email = document.querySelector('#email');\nconst error = document.querySelector('#email-error');\n\n// The playground blocks real form submission, so validation runs on the\n// submit button's click. That click also fires when Enter is pressed in a field.\ndocument.querySelector('#pay').addEventListener('click', (event) => {\n event.preventDefault();\n if (email.value.includes('@')) {\n error.hidden = true;\n email.removeAttribute('aria-invalid');\n email.removeAttribute('aria-describedby');\n return;\n }\n error.textContent = 'Enter an email address like name@example.com';\n error.hidden = false;\n email.setAttribute('aria-invalid', 'true');\n email.setAttribute('aria-describedby', 'email-error');\n email.focus();\n});\n"},"checks":[{"id":"labels","test":"const lbl = (el) => [...(el.labels || [])].map((l) => l.textContent).join(' ').replace(/\\s+/g, ' ').trim(); const fields = $$('input'); return fields.length === 4 && fields.every((f) => lbl(f).length > 0) && /full name/i.test(lbl($('#full-name'))) && /email/i.test(lbl($('#email'))) && /standing/i.test(lbl($('#t-standing'))) && /seated/i.test(lbl($('#t-seated')));"},{"id":"fieldset","test":"const radios = $$('input[type=\"radio\"]'); const fs = radios[0] && radios[0].closest('fieldset'); if (!fs || !radios.every((r) => fs.contains(r))) return false; const lg = fs.querySelector('legend'); return !!lg && fs.firstElementChild === lg && /ticket type/i.test(lg.textContent);"},{"id":"autocomplete","test":"return $('#full-name').getAttribute('autocomplete') === 'name' && $('#email').getAttribute('autocomplete') === 'email' && $('#email').type === 'email';"},{"id":"error-linked","test":"const email = $('#email'); await input(email, 'samir.example.com'); await click('#pay'); if (email.getAttribute('aria-invalid') !== 'true') return false; const ids = (email.getAttribute('aria-describedby') || '').split(/\\s+/).filter(Boolean); return ids.some((id) => { const el = document.getElementById(id); return el && !el.hidden && /enter an email/i.test(el.textContent); });"},{"id":"error-focus","test":"return document.activeElement === $('#email');"},{"id":"error-clears","test":"const email = $('#email'); await input(email, 'samir@example.com'); await click('#pay'); if (email.getAttribute('aria-invalid') === 'true') return false; const ids = (email.getAttribute('aria-describedby') || '').split(/\\s+/).filter(Boolean); return !ids.some((id) => { const el = document.getElementById(id); return el && /enter an email/i.test(el.textContent) && !el.hidden; }) && $('#email-error').hidden;"}],"title":"Repair Ticketly's checkout form","prompt":"

The checkout form relies on placeholders, floats a question above unlabelled radios, and shows an email error that only sighted users notice. Fix it:

\n
    \n
  1. Give #full-name, #email and both radios a real <label> (“Full name”, “Email”, “Standing”, “Seated”).
    2. \n
  2. Group the radios in a <fieldset> whose <legend> is “Ticket type”.
    3. \n
  3. Add autocomplete="name" and autocomplete="email", and make the email field type="email".
    4. \n
  4. In the script, when the email is invalid: set aria-invalid="true", point aria-describedby at #email-error, and move focus to the email field. When it becomes valid, remove both attributes.
    5. \n
\n","hints":["Either before the input, or wrap the radio in .","The legend must be the first child of the fieldset.","In the invalid branch: email.setAttribute(‘aria-invalid’, ‘true’); email.setAttribute(‘aria-describedby’, ‘email-error’); email.focus();"],"explanation":"

Labels give every field a name that survives typing, and the fieldset lets screen readers announce “Ticket type, grouping” before the options. The autocomplete tokens let browsers and password managers fill the form, which is what 1.3.5 asks for. The script now connects the error in three ways: aria-invalid says the field is wrong, aria-describedby makes the message its description, and focus() takes the user straight to it, so NVDA reads “Email, edit text, invalid entry, Enter an email address like name@example.com”. Removing both attributes on success stops the old error being read again, because a referenced element is announced even while hidden.

\n","checkLabels":{"labels":"All four inputs have labels with the right text","fieldset":"The radios sit in a fieldset whose first child is the legend “Ticket type”","autocomplete":"Name and email have autocomplete tokens, and email is type=“email”","error-linked":"An invalid email sets aria-invalid and links the visible error with aria-describedby","error-focus":"Focus moves to the email field after the failed attempt","error-clears":"A valid email removes aria-invalid and hides the error"}},"words":735,"readMinutes":4}