Required state needs a cue both visual and non-visual

What it is

If an item is required, people who can see must be able to tell from the label, and assistive technology must hear required state on entering the field. Both channels means both are present: a visible mark or the word “required,” plus programmatic required state. A star with no state, and reader users skip required items as optional until submit fails. State with nothing on screen, and sighted users skip too. Marking the minority, and writing a legend for the asterisk, is how the visible mark is designed. Here the demand is that visible and non-visible appear as a pair. How error descriptions attach is after failure.

Why it happens

Required is control state, not decoration. The visual channel uses a mark for search; the non-visual channel uses a state bit, and the reader says “required” after the name. Build only one, and the other group’s search strategy fails. A second layer: state and visible mark must name the same set. Screen marked required, programmatic not—or the reverse—and the two groups reach opposite conclusions about what may be blank; at submit one group is suddenly blocked. When optional becomes required dynamically (tax ID after choosing a company), both channels must update on the same beat, preferably with a short announcement, or reader users still skip on the old state. The HTML required attribute usually contributes both validation and accessible state. Custom controls have no such hook and must expose state explicitly; a painted star is not enough.

Studying it

Build “star only,” “programmatic required only,” “both, copy agrees,” and “the two disagree.” Sighted users mark what may be blank; reader users listen for which items say required. Then dynamically turn optional into required.

Independent variables: visible mark present, programmatic state present, whether they agree, whether state updates with a condition. Dependent variables: whether the two groups’ “skippable set” matches, which group is surprised at submit, whether the reader still speaks the old state after a dynamic change.

A WCAG audit can list this as a check, but pass requires paired looking and listening. A legend that explains the star does not replace programmatic state—the legend decodes the star for people who can see it.

Where it stops holding

When the whole form is required and the header already says so, visible marks can recede, but each control should still expose required state, because reader users may not hear the header. A legal-consent checkbox that is required is also agreement; both state and visible copy should say “must be checked,” not only a star. Optional programmatic state is simply not marked required, not a third “optional” state—most platforms have no optional bit; the visible word “optional” is enough. Print keeps only the visual channel.

Applying it

• Required fields have both a visible cue (a word, or a mark already explained) and programmatic required state. Neither alone may ship.
• When a condition makes a field required, update the visible cue and the state on the same beat; announce briefly “this item is now required” if needed.
• Do not let the on-screen required set differ from the required set in the tree; list the diff with automation.
• Verify: a reader entering required hears required, entering optional does not. With AT covered, sighted users mark the same set from the screen alone. After tax ID becomes required, the star (or “required”) appears and the reader switches to required. Use star-without-state as a control that reader users will skip.

Related

• Within the group: H1.15.1 Every input needs a programmatic association with its visible label · H1.15.2 A placeholder used as a label loses the field’s meaning once filled · H1.15.3 Error messages must be tied to the field through accessibility properties
• Adjacent: H1.03 Required and optional markers · J5.10 Name, role, and state · H1.14 Conditional fields and dynamic reveal
• Search terms: aria-required · required field · accessible state