Improve handling of focus

[basham]

Improve handling of focus

[gpbl]

Ah! Let me understand. Said the focus is on an element right before the widget, then:

• press TAB: focus the first day cell → press RIGHT ARROW: it focus the next day → press ENTER or SPACEBAR (eventually) fire the onClick event → press TAB: focus the next focusable element (e.g. exit from the widget)
• how should the navigation between months work, then? Now, using the arrow keys you can switch between the months when the widget is focused. if we remove tabindex from .DayPicker[role="widget"] this won't work anymore (related: #41)

[basham]

press TAB: focus the first day cell → press RIGHT ARROW: it focus the next day → press ENTER or SPACEBAR (eventually) fire the onClick event → press TAB: focus the next focusable element (e.g. exit from the widget)

You are correct about the preferred behavior.

---

how should the navigation between months work, then? Now, using the arrow keys you can switch between the months when the widget is focused. if we remove tabindex from .DayPicker[role="widget"] this won't work anymore

I've likewise been ponder that. With react-widgets Calendar widget, keying CONTROL + ARROW LEFT or CONTROL + ARROW RIGHT navigates between adjacent months, and focus moves to the same day on the new month. It makes sense to try to navigate to a similar place in different months to both retain orientation and potentially save key strokes. It is common and not unreasonable to require the use of the CONTROL key. Behavior in the Calendar widget certainly gets interesting when navigating to months with different number of days:

1. January 31 is in focus
2. Key CONTROL + RIGHT ARROW
3. February 28 is in focus
4. Key CONTROL + RIGHT ARROW
5. March 28 is in focus

If a day is outside of a range of a given month, it snaps to the closest day within the new range. To me, this seems reasonable, but this assumes that every day is focusable and that only one month is shown at a time.

We have two big issues to resolve that's a little more unique to the features of this widget:

1. What happens when a group of months are shown? Does CONTROL + ARROW LEFT|RIGHT navigate the group or does it navigate each month within a group? What's the best behavior to accomplish both? The DHTML Style Guide date picker may be a good starting point to think about alternative keys, but it still assumes one month at a time.
2. How do the .DayPicker-Day states of focus and disabled (aria-disabled="true", #34) work in conjunction, and how does that relate to navigating among days, months, or month groups? It's not common for disabled interactive elements (or static elements) to receive focus. Therefore, navigating between focusable days should skip disabled days. By extension, how do you decide which new day receives focus on a month you're navigating to, when there could be no focusable day in that month? That gets really tricky, and I'm unsure what's sensible right now.

[basham]

I am starting to think that the current strategy for managing focus (i.e. managing focus among descendants, instead of using aria-activedescendant) paired with removing focus on .DayPicker[role="widget"] is a mistake, since this assumes that there will always be a .DayPicker-Day with the ability to have focus. The [basic calendar example](http://www.gpbl.org/react-day-picker/#examples/Basic calendar) is already a counterargument to this approach. If there's no focusable .DayPicker-Day, then there's no ability to control or even navigate to the widget.

Therefore, I now propose that aria-activedescendant is the only sensible strategy moving forward. Leave focus on .DayPicker[role="widget"] and if any descendant element is naturally interactive, then it should never receive focus (tabindex="-1"). Add .DayPicker-Day--active class modifier to visually align with the value of aria-activedescendant. aria-activedescendant should only refer to .DayPicker-Day elements, not to other descendants.

[gpbl]

Hey @basham could you better explain how would the aria-activedescendant strategy work? Would that just require to change the attribute, or the way the user interacts with the keyboard too?

[basham]

After a little more research on aria-activedescendant, things will have to change a little more than I initial thought in #33.

Because we currently want only one active descendant per range of rendered months, aria-activedescendant should be placed on some element encompassing all months. In our case, it should be .DayPicker. However, aria-activedescendant can't be paired with role="widget" because that's too generic of a role type. The container's role must logically pair with the active descendant's role. A calendar with role="grid" is absolutely best in paired with days of role="gridcell". Therefore, adjusting the original recommendation in #33:

• Add role="grid" to .DayPicker, not to .DayPicker-Month
• Add aria-readonly="true" to .DayPicker, not to .DayPicker-Month
• Add aria-activedescendant to .DayPicker, not to .DayPicker-Month
• It's probably fine to leave .DayPicker-Month's aria-label pointing to its respective .DayPicker-Caption; I could see it alternatively pointing to .DayPicker-Body, but that would need confirmation

In regard to getting aria-activedescendant working:

• It's value should be an id of a .DayPicker-Day[role="gridcell"]
• If no .DayPicker-Day is active, then either remove the attribute altogether or make its value undefined (aria-activedescendant="")
• When the active day changes via user interaction, then update the id value of aria-activedescendant to match; you should also be good to add other class modifiers elsewhere to reinforce what's happening (#44)
• Because there could be multiple instances of this widget implemented, it may be best to dynamically generate and assign ids, such as using a hash

References

• Why There are Only Two Ways to Make ARIA Widgets Programmatically Focusable for Screen Reader Users

[basham]

Regarding keyboard behavior, this is a very excellent date picker demo, which should be used as an exemplar:

http://oaa-accessibility.org/example/15/

[gpbl]

Added #35 for the keyboard. I should organize better the code or is going to be difficult to test :)

[gpbl]

Added #51 for the keyboard. I should organize better the code or is going to be difficult to test :)

[smithaitufe]

@basham How can I use separate buttons for changing months in the daypicker

[basham]

@smithaitufe I'll follow up with you via email. We don't need to start an aside discussion on this GitHub issue.