The Gift Message Field Your Screen Reader Cannot Find

A gift message field looks like the smallest feature on a checkout. For a screen reader user it is a trap: a field that is not labelled, not announced, and not reachable by keyboard. The fix is small, and the failure is total.

The field that is not there

A gift message field is usually added late in a checkout build, after the address and payment steps are done, and it shows. The field arrives as a plain text area with a placeholder that reads gift message, no label element, no describedby hint, and a toggle that reveals it on click. A sighted mouse user sees it and types. A screen reader user tabs to it and hears edit, blank, or nothing at all. The field is, for that user, not there.

The fix is one label and one attribute. Give the field a visible label element linked with a for attribute to the field id, and the screen reader announces gift message when the field gets focus. If the design cannot show a visible label, use aria-label with the same text. Either way, the label has to be tied to the field in the markup, not sitting next to it in the layout. A label that is visually adjacent but programmatically unlinked is decoration.

The error summary post covered the same class of failure from the other direction: an error that is visible on screen but never announced. A gift message field that is visible but not labelled is the same bug wearing a different label. Both are fixed by tying the text to the field in the markup.

The toggle has to be a button

Most gift message fields hide behind a toggle: add a gift message, with a checkbox or a link that reveals the text area. If that toggle is a div with an onClick handler, a keyboard user cannot reach it at all, and a screen reader user does not know it exists. The toggle has to be a real button element, or an element with a button role and a keydown handler, with a visible focus indicator. This is not a nice-to-have. If the toggle is not a button, the field is unreachable for a whole class of users.

When the toggle opens the field, focus should move to the field, and the screen reader should announce it. When it closes, focus should return to the toggle. This is the same focus management pattern as a modal, and it is the pattern the focus order post laid out for the payment step. A gift message field is small, but it is a modal in miniature, and it needs the same care.

The character limit is the hidden trap

Gift message fields usually have a character limit, often 200 characters, and the counter is usually a small grey number next to the field. A screen reader user does not see the counter, and if the counter is not a live region, they do not hear it either. They type a message, hit the limit, and the field stops accepting input with no explanation. The fix is to link the counter with aria-describedby so it is announced with the field, and to make the counter a polite live region so it updates as the user types.

WCAG 2.2 Success Criterion 3.3.1, Error Identification, requires that an error be identified in text, and 3.3.3, Error Suggestion, requires that a suggestion be provided where possible. A field that silently stops accepting characters fails both. The gift message field is a good place to start an accessibility audit, because it is small, it is usually broken, and fixing it teaches the team the pattern that fixes the rest of the checkout. The quantity stepper post showed the same lesson on a different control: the small field is where the big failures hide.

Frequently asked questions

What is the most common screen reader failure in a gift message field?

The most common failure is a missing label: the field has a placeholder that says gift message but no associated label element, so a screen reader announces it as an empty text field or an edit box with no purpose. A visible label linked with a for attribute, or an aria-label, fixes it in one line.

Is a placeholder enough of a label for a gift message field?

No. The label has to be tied to the field with a for attribute or an aria-labelledby reference, so a screen reader announces the label when the field gets focus. A placeholder is not a label, and it disappears when the user starts typing, which leaves the field anonymous at exactly the moment the user needs the label most.

How should a character limit be announced to screen reader users?

Use aria-describedby to link the field to the hint, so the screen reader announces both the label and the limit. The character counter should be a live region that updates as the user types, so a screen reader user hears the count without hunting for it.

Does a gift message toggle need to work with a keyboard?

Yes. If a shopper can add a gift message, they have to be able to do it with a keyboard alone, and the toggle that reveals the field has to be a real button with a visible focus state. A div that opens on click is not reachable by keyboard and is invisible to a screen reader.