-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tab ordering issue #62
Comments
I see what you mean. Though I'm not sure changing the focus order to mismatch the visual order is a good fix, since that's a WCAG violation in itself. One solution might be to focus the popover itself? But then you're trading better tab order at the cost of some ergonomics. |
Its tricky for sure, I'm trying to avoid anything hacky/complicated that falls apart if someone looks at it wrong ;) |
I think i'm going to extend the calendar.focus({ target: "previous" });
calendar.focus({ target: "next" });
calendar.focus({ target: "day" }); // same as...
calendar.focus() the target names match up with the css |
That's a nice solution - keeps the API simple and consistent |
Just to add, the expected arg extends native calendar.focus({
target: "previous",
preventScroll: true
}) |
If I display
<calendar-date>
inside a popup (in a similar way to your Shoelace integration example) then when the popup opens I can call 'focus' on the calendar-date component to correctly set focus. This works as expected as the user is then immediately able to use the keyboard to navigate around and choose a date.The problem occurs if the user wants to tab to the 'change month' buttons, currently they have to know to use 'shift tab' to send the focus backwards. The native Chrome
input
date time picker allows the user to use just 'tab' so that focus then shifts to the 'non date selecting' controls, however with<calendar-date>
this causes focus to leave the component. You can see this exact same behaviour with your Shoelace example code.I've tried putting some form of focus trapping in to detect this and refocus the component, but this is "risky" code as it involves querying down into Cally's shadow DOM to pass focus directly to the "previous" button.
I'm not sure how this can be easily fixed, I like the default Cally behaviour of focusing the 'date' part first as I believe this is the thing a keyboard user will most likely want to change so I think it should retain the primary focus but it would be nice if the tab ordering could be "tweaked" so that the other interactive elements gain focus before it leaves the component.
See https://www.w3.org/WAI/WCAG21/Understanding/no-keyboard-trap.html (Calendar widget) for some of the motivation behind this request :)
The text was updated successfully, but these errors were encountered: