Accessible Checkout Forms: Labels, Errors and Focus

An accessible checkout form does three things before a shopper pays: it labels every field in plain words, it states the format and the required fields up front, and it explains each error in text with a fix. When one piece is missing, a shopper who uses a screen reader or a keyboard can stall at the last step, with a full cart and no clear next move. This article works through labels, instructions, errors, focus and autocomplete, with code you can adapt to your own checkout.

Key takeaways

• Give every field a visible, programmatic label, never placeholder text alone.
• State the format and required fields before the shopper types.
• Describe each error in text, name the field, and say how to fix it.
• On a failed submit, move focus to the first error, and offer a review step before payment.
• Add autocomplete tokens to name, address, email and card fields.

Label every field before the shopper types

A label is the name of a field. The W3C WAI forms tutorial says to use the label element to identify each form control, with other mechanisms only in specific cases. In code, a label with a for attribute must match the id of the input, and the visible label and the programmatic label should use the same wording.

Placeholder text is not a label. It disappears when the shopper starts typing, so the field name is gone at the exact moment it is needed most.

Failing version, with placeholder text only:

<input type="email" id="email" name="email" placeholder="Email address">

Passing version, with a real label:

<label for="email">Email address</label>
<input type="email" id="email" name="email">

Group related fields, too. Use fieldset with a legend for a delivery method group, so a screen reader user hears the group name with each choice. Check your checkout field by field: every input, select list, checkbox and radio button should have a label in the code.

State the format and the required fields up front

WCAG success criterion 3.3.2, Labels or Instructions, is Level A, and it calls for labels or instructions when content requires user input. For a checkout, instructions mean which fields are required, and what format each field expects.

Mark required fields in the label text itself, such as "Card number (required)". Pick one rule and use it on every field. Do not leave required status only in a color or a star with no text meaning.

State the format in helper text beside the field, before the shopper submits. "Expiry date, MM/YY" prevents a rejection that a bare "Expiry date" label invites. Tie the helper text to the input with aria-describedby, so a screen reader user hears the format when the field receives focus.

<label for="expiry">Expiry date (required)</label>
<input type="text" id="expiry" name="expiry" aria-describedby="expiry-help">
<p id="expiry-help">Enter the expiry date as MM/YY, as shown on the card.</p>

Accessible checkout form: errors in text, with a fix

WCAG success criterion 3.3.1, Error Identification, is Level A. If an input error is automatically detected, the item in error is identified and the error is described to the user in text. Success criterion 3.3.3, Error Suggestion, is Level AA, and it adds the fix: when a correction is known, suggest it, unless doing so would jeopardize the security or purpose of the content.

Levels to note: 3.3.1 is Level A, 3.3.2 is Level A, 3.3.3 is Level AA, and 1.3.5 is Level AA.

A red border alone does not meet 3.3.1, because the error is not described in text. A message that reads "Invalid input" names no field and offers no fix. A useful message names the field, states the problem, and gives the correction in one sentence.

Stronger version, tied to the field:

<label for="card-number">Card number (required)</label>
<input type="text" id="card-number" name="card-number" aria-invalid="true" aria-describedby="card-error">
<p id="card-error">Card number: enter the 16 digits shown on the card, without spaces.</p>

Here, aria-invalid marks the field in error, and aria-describedby ties the error text to it. For a security code field, do not reveal the correct value; state the expected format only. When a submit fails with more than one error, add an error summary at the top, link each item to its field, and keep the wording identical to the inline message.

Move focus to the first error, and keep a review step

An error message far from the shopper's current position is easy to miss. After a failed submit, move keyboard focus to the error summary, or to the first field in error if there is no summary. The shopper should land on the problem, not at the top of a long page with no sign that anything changed.

Test this with a keyboard only: Tab through the checkout, submit it empty, and try the payment step, noting any spot where Tab stops working or focus does not land on an error.

A checkout is a financial transaction, so WCAG success criterion 3.3.4, Error Prevention (Legal, Financial, Data), at Level AA, matters here. For a page that causes a financial transaction, at least one of three options must hold: the submission is reversible, the data is checked with a chance to correct it, or the shopper can review, confirm and correct the information before finalizing it. A review page before the final payment button is the plainest way to offer that last option, showing items, address, delivery choice and total, with a way back to edit each part. If the order summary uses a table, give it proper header cells, as the accessible pricing table guide shows.

Add autocomplete so browsers can fill known fields

WCAG success criterion 1.3.5, Identify Input Purpose, is Level AA. It asks that the purpose of each input field collecting information about the user can be programmatically determined, when the field serves a listed input purpose. In HTML, the practical way to do that is the autocomplete attribute, with a token that names the expected data.

Checkout field	Token
Full name, one field	name
First name, split names	given-name
Last name, split names	family-name
Email address	email
Street address	street-address
Postal code	postal-code
Card number	cc-number
Card expiry	cc-exp

Autocomplete does not replace a label. It adds machine readable purpose on top of the visible label, so a browser or assistive technology can offer the saved value.

<label for="full-name">Full name (required)</label>
<input type="text" id="full-name" name="full-name" autocomplete="name">
<label for="card-number">Card number (required)</label>
<input type="text" id="card-number" name="card-number" autocomplete="cc-number" inputmode="numeric">

Do not switch autocomplete off on checkout fields as a default: it helps many shoppers complete a long form with fewer keystrokes.

How Axeazy helps with this exact issue

Axeazy lists form labels among the 14 fix categories it works on. Read the honest scope on the capabilities page, and read how the scan works to see how findings are recorded with a date and time.

A scan can flag a missing or unlinked label in your own page code. For a site with its own GitHub repository, fixes arrive as a real pull request with a visible code diff for review and merge. For other sites, the scan gives computed fix values and a guided checklist.

Be clear about the limit for payments: Axeazy does not scan content behind logins or on third party hosted embeds the scanner cannot reach, so hosted card fields sit outside that scan. Your own checkout fields still stay with you, and a quick manual keyboard check after any scan is part of good practice.

Want a quick read on your own site? Run Axeazy's free 60 second scan . It needs no signup.

Last checked: October 28, 2026.

FAQ

Can placeholder text act as the label for a checkout field?

No. Placeholder text disappears when the shopper starts typing, and it is not a substitute for a label element linked to the input. Give every field a visible label with a for attribute matching the input id.

Should an error message appear only after the shopper submits the form?

No, it should not wait until the end when the problem is clear earlier. Inline errors tied to the field help a shopper fix a field at once, and an error summary after a failed submit helps when several fields need work. Keep both wordings the same.

What if the card number field sits inside a hosted payment frame?

Test that frame with a keyboard only: check that focus can enter it, that the field can be completed, and that focus can leave it again. Keep your own checkout fields in good shape, since those stay under your control. If the hosted frame blocks keyboard use, raise that with the payment provider.

Does autocomplete replace the need for a visible label?

No. Autocomplete adds machine readable purpose to a field, so browsers and assistive technology can identify what kind of data it expects. The visible label still tells the shopper what to enter, and it is what a screen reader announces as the field name. Use both.

Sources

• W3C Understanding Success Criterion 3.3.1: Error Identification, checked October 28, 2026
• W3C Understanding Success Criterion 3.3.2: Labels or Instructions, checked October 28, 2026
• W3C Understanding Success Criterion 1.3.5: Identify Input Purpose, checked October 28, 2026
• NYU Accessibility Testing Standards: 3.3.3 Error Suggestion, checked October 28, 2026
• W3C WAI Forms Tutorial, checked October 28, 2026