How can I make a date picker work without pointer input?

Start by treating the text field and calendar as two ways to enter a date, rather than making the calendar the only route. The WAI-ARIA Authoring Practices example pairs a date text input with a button that opens a calendar dialog. It also associates date-format help with the input. [S1]

For a keyboard-operated calendar grid, use a consistent movement model. In that example, the arrow keys move by day or week, Home and End go to the start or end of the week, and Page Up or Page Down changes month while retaining a corresponding day where possible. Shift with Page Up or Page Down changes year. Enter or Space selects a date and updates the text field; Escape closes the dialog. [S1]

These are example behaviors, not proof that a particular implementation will work in every browser or with every assistive technology. W3C warns that its example is not production-ready and calls for testing. [S1]

Keep the date field available as a genuine alternative: a person should be able to enter a date without first opening the calendar. Explain the accepted format next to the field or make the help available from it; the cited example associates format help with its input. [S1]

For example, if your interface accepts day/month/year, say so in the field’s help. Use that format only if it is actually the one your product accepts. The source establishes that a text-entry alternative and format help are part of its example; it does not establish validation rules or accepted formats for your application. [S1]

Assume the field accepts a date format documented by your product and the calendar opens in a dialog. Without using a pointer, focus the field and enter a date directly. Then open the calendar, use its documented keys to move to another date, and press Enter or Space to select it. Confirm the selected date appears in the text field. If the calendar is a dialog, check that Escape closes it. These steps follow the cited example’s interaction model; the accepted format and dates depend on your product. [S1]

Also review what happens when the month or year changes. The example reports those changes. Decide how your implementation will make them understandable, and test the result with your intended browser and assistive technology. The source cautions that support gaps exist and testing is needed; it does not certify any particular combination. [S1]

Use it as a reference for interaction ideas, not as a drop-in specification or an assurance of accessibility: W3C labels the example illustrative and not production-ready. [S1] Adapt the behavior to your interface, then test the complete task with the browsers and assistive technologies relevant to your audience. Record confusing or unsupported behavior rather than assuming the example guarantees compatibility.

A compact review should cover both routes into a date—the text field and the calendar—and the transitions between them. Note the expected key, the result, and whether the user can tell what changed. That can help reveal gaps such as a calendar that opens from a button but cannot be operated or dismissed from the keyboard.