[Component Audit] DateRangeInput: keep range state truthful

[cixzhang]

User impact

People using DateRangeInput with assistive technology can now hear required state without invalid ARIA, hear the same pending range that is visible while a change saves, and reopen a cleared calendar without the previous range appearing selected.

Problem and solution fit

Three state seams drifted apart:

• the range trigger is a button, but it carried aria-required, which is not valid on that role;
• its accessible name read the accepted value while the visible trigger read the optimistic value;
• clearing passed undefined to Calendar, allowing Calendar to fall back to its old internal range.

The fix keeps the existing button contract. Required state uses the established localized hidden-description pattern, the trigger name and Calendar both consume the optimistic controlled value, and Calendar documents null as its explicit controlled-empty value.

Expected behavior and authority

• DateRangeInput FR1 requires one controlled range without a competing selected range.
• family:input-fields FR6 requires optimistic value feedback during changeAction.
• The existing FileInput button-trigger pattern supplies required state through a localized aria-describedby target rather than unsupported aria-required.

Smallest restoration

• Preserve the released button role, Enter/Space behavior, props, defaults, visuals, and theme targets.
• Add no new caller decision. Calendar.value only widens its type to admit the null controlled-empty state already handled at runtime.
• Remove the now-obsolete critical axe baseline entry.

Credit: this repair incorporates the problem reports and implementation evidence from #4689 and #6935.

Audit score

Rubric 1.16.6:

• Before: 80.3 / C — 3 BLOCKs: invalid required-state ARIA, stale pending accessible name, and stale selected days after clear.
• After: 93.1 / A — 0 open BLOCKs. Exact-head Actions will confirm the rendered/a11y/RTL sections before merge.

Changed sections: accessibility 2.5→4.5, behavior 3→5, testing 4→5. Other section scores are unchanged.

Evidence

• Reproduction before the change: all three new DateRangeInput regressions fail against the base behavior; the required story also has the existing aria-allowed-attr baseline row.
• Result after the change: 170/170 focused Calendar, DateRangeInput, and PowerSearch tests pass.
• Representative unchanged path: ordinary range selection, preset selection, disabled reasons, and PowerSearch range rendering remain covered.
• Independent exact-head private review: CLEAN at 94f81034f22306ca4329c111c6c2df0224ef1cfe.

Scope

• One restoration: keep the field's required, pending, and selected range state truthful.
• Separable role/keyboard and audit-fixture changes were removed.
• No incompatible public API, visual representation, default, or interaction model is hidden under the bug-fix label.
• Public text and artifacts contain no internal Meta context.

Testing

• pnpm lint:strict
• pnpm build
• Core and Storybook typechecks
• Storybook production build
• 170 focused assertions
• Full Vitest suite with bounded workers: changed paths pass; transient CLI timeouts pass when rerun serially. Five unrelated current-main/environment failures remain in untouched Storybook taxonomy tests and GNU-specific setup-workspace tests. Exact-head Linux CI is the merge gate.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
astryx	Ready	Preview	Oct 10, 2026 11:50am UTC

[astracat-bot]

AI review status for this pull request.

Review status	Updated
🟢 Reviewed (for maintainers only)	Oct 10, 2026, 12:01 PM UTC

[github-actions]

PR Analysis Report

Previews ready: Storybook and Sandbox were built with this PR's docsite. CI evidence will be added when available.

View Storybook for this PR · View Sandbox for this PR

[astracat-bot]

Thanks — this keeps DateRangeInput's range state truthful in three places that had drifted apart. Required state is now announced through a valid description on the button trigger (with the obsolete axe baseline exemption removed), the trigger's accessible name and the calendar follow the optimistic value while a save is pending, and clearing the field no longer brings the old selection back when the calendar reopens.

Calendar's newly documented value={null} controlled-empty state is additive and matches what the runtime already did, so existing calls are unaffected. I verified the focused Calendar/DateRangeInput and PowerSearch tests, the core typecheck, and before/after rendered axe results on the Required story; no blocking findings from me.

[Automated review]