What happens
In @cratis/components 4.1.0, editable DatePicker segments emitted as role="spinbutton" have default effective targets of about 7.8 px by 24 px with 0 px safe spacing. A current consumer's axe-core 4.12 browser scan reports six serious target-size failures across populated, invalid, and end-date segments.
Evidence
The evidence is bound to exact tag v4.1.0 (c4c4cc9a13c6416eb3ab31701546e961b4e9da72):
DatePickerInputImplementation.tsx renders each editable DateSegment as the stable data-cratis-part='segment' part.DatePickerInput.css gives that part only padding: 0 0.1rem, removes its outline, and defines no minimum target dimension or sufficient spacing.- The measured failures each report approximately
7.8px by 24px and a safe clickable-space diameter of 0px rather than 24px.
- Exact-tag DatePicker specs cover props, semantic states, invalid state, naming, and bounds, but do not exercise real-browser target geometry.
What it costs a consumer
The consumer passes ordinary DatePicker value, state, identity, bounds, and accessible-name props and does not replace segment geometry. Its accessibility scan therefore fails on package-emitted nodes. The only local workaround would be a selector against package DOM/CSS, duplicating package ownership and leaving other consumers with the same default defect.
Suggested fix — the seam
Give the stable DatePicker segment part at least 24 by 24 px of effective target geometry, or sufficient safe spacing that meets the same target-size boundary, while preserving segmented keyboard entry. Add a real-browser package regression over populated and empty segmented dates and demonstrate that removing the geometry makes it fail.
What is explicitly not being asked for
- No change to or removal of segmented date entry.
- No prescribed CSS bytes and no demand for a 44 px target.
- No package change for the consumer's separate external clear/calendar-trigger spacing residual.
- No requirement for consumers to target React Aria internals or add permanent wrapper CSS.
Related, not duplicate
#211 is broad cross-browser and assistive-technology certification work. It is related, but it does not describe or settle this atomic DatePicker segment-geometry defect.
What happens
In
@cratis/components4.1.0, editable DatePicker segments emitted asrole="spinbutton"have default effective targets of about 7.8 px by 24 px with 0 px safe spacing. A current consumer's axe-core 4.12 browser scan reports six serioustarget-sizefailures across populated, invalid, and end-date segments.Evidence
The evidence is bound to exact tag
v4.1.0(c4c4cc9a13c6416eb3ab31701546e961b4e9da72):DatePickerInputImplementation.tsxrenders each editableDateSegmentas the stabledata-cratis-part='segment'part.DatePickerInput.cssgives that part onlypadding: 0 0.1rem, removes its outline, and defines no minimum target dimension or sufficient spacing.7.8px by 24pxand a safe clickable-space diameter of0pxrather than24px.What it costs a consumer
The consumer passes ordinary DatePicker value, state, identity, bounds, and accessible-name props and does not replace segment geometry. Its accessibility scan therefore fails on package-emitted nodes. The only local workaround would be a selector against package DOM/CSS, duplicating package ownership and leaving other consumers with the same default defect.
Suggested fix — the seam
Give the stable DatePicker segment part at least 24 by 24 px of effective target geometry, or sufficient safe spacing that meets the same target-size boundary, while preserving segmented keyboard entry. Add a real-browser package regression over populated and empty segmented dates and demonstrate that removing the geometry makes it fail.
What is explicitly not being asked for
Related, not duplicate
#211 is broad cross-browser and assistive-technology certification work. It is related, but it does not describe or settle this atomic DatePicker segment-geometry defect.