Reviewed October 29, 2026

Delivery Instructions at Checkout: A Small Field, A Big Barrier

Leave instructions for the driver sounds like a courtesy field. For a customer who needs a step free drop off, a gate code entry, or a call on arrival instead of a knock, it is the field the whole delivery depends on. It is also routinely the worst built field in checkout: an unlabeled text area, a character limit announced only after it is exceeded, and instructions that vanish when any other field throws an error. Getting this one field right is a tidy model for accessible form design generally, because every failure it exhibits is a named WCAG failure with a known fix.

Label it like it matters, because autocomplete cannot save it

Every form field needs a visible label tied to it in code, and the delivery instructions field is often shipped with placeholder text doing the label job. Placeholders disappear while typing, are frequently low contrast, and are not reliably announced as labels by assistive technology. Write a real label, delivery instructions, and put the helpful detail, gate code, floor, or where to leave the parcel, in a short hint linked to the field so a screen reader reads it before entry. There is no autocomplete token for delivery notes, so the label and hint carry the whole burden of explaining the field. If your checkout platform renders this field from a third party delivery app, inspect the actual markup it injects; app fields are where missing labels most often hide.

Character limits and the countdown that only sighted users get

A 100 character limit is reasonable for a driver note. Announcing it is the part stores skip. A visual counter that turns red at the limit is invisible to a screen reader user and useless to anyone who cannot see color change as information. State the limit in the hint text up front, and if you keep a live counter, expose it as a polite status that reports at meaningful points rather than every keystroke. Never truncate silently mid paste and never reject the whole checkout over a long note; shorten with a message, or accept and trim with the customer knowledge. A customer pasting an address block plus a gate code will hit your limit in one action, and the error copy should say what to remove, not merely that something is invalid.

When checkout errors, the instructions must survive

The expensive failure is state loss. A payment or postcode error reloads checkout, the form flags the bad field, and every correctly completed field, including a carefully typed set of access instructions, comes back empty. For a customer who types slowly or dictates text, re entering that field is the highest cost error in the whole flow. Preserve all valid entries across error states, put focus on an error summary that lists each problem in text with links to the fields, and identify errors in words, not color alone, per WCAG 3.3.1 and 3.3.3. Test this deliberately: write a long delivery note, force an error in another field, submit, and see what survives. Many stores have never run that test on their own checkout.

What good instructions support looks like after the order

Accessible delivery does not end at the submit button. The instructions should appear, in full, on the confirmation page and in the confirmation email as plain text, so the customer can verify what the driver will see. If your fulfilment system truncates the note for the courier label, that truncation should not be a surprise discovered at the door. Internally, make sure the note reaches the party who actually delivers; a field that collects access needs and routes them nowhere is worse than no field, because it creates an expectation the operation then fails. Review a month of real instructions quarterly: they will tell you, in customers own words, where your building access, address data, and courier handoffs actually break.

Frequently asked questions

What label should the delivery instructions field use?

Use a short, plain visible label such as delivery instructions, permanently tied to the field in markup, with a separate hint for examples like gate code, floor, or a safe place to leave the parcel. Do not rely on placeholder text as the label. If the field is optional, say so in the label or hint in text, not only with an asterisk explained in a footnote. Customers using voice control need the visible words to match the accessible name, so keep the wording identical in both places.

How do we announce a character limit accessibly?

State the limit in the field hint before typing starts. If you show a remaining characters counter, make it a polite status region that updates at intervals, for example at 20 characters remaining and at the limit, rather than announcing every keystroke. When the limit is exceeded, give a text error that says by how much and what to do. Never communicate the limit by color alone, and never silently cut off pasted text without telling the customer what was removed.

Why do delivery instructions disappear when checkout has an error?

Because the checkout or the delivery app re renders the form on error and does not preserve the value of that field, even when it preserves name and address. It is a state handling bug, not a customer mistake. Fix it by storing and restoring all valid field values across the error cycle, and test it by intentionally triggering an unrelated error after filling the instructions. Until it is fixed, warn customers in the error summary that fields need checking, though that is a workaround, not a solution.

Should delivery instructions be a required field?

For most stores, no. Making it required forces customers with nothing to add to invent text, and it adds friction for everyone. Keep it optional, clearly labeled, and easy to find. The exception is a delivery model that cannot complete without specific information, such as a building access code for every address served. In that case, ask for that specific item as its own labeled field rather than burying the requirement inside a general notes box and flagging it missing at the end.