Skip to content
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

Open
rstoneIDBS opened this issue Sep 9, 2024 · 5 comments · May be fixed by #68
Open

Tab ordering issue #62

rstoneIDBS opened this issue Sep 9, 2024 · 5 comments · May be fixed by #68

Comments

@rstoneIDBS
Copy link

rstoneIDBS commented Sep 9, 2024

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 :)

@WickyNilliams
Copy link
Owner

WickyNilliams commented Sep 13, 2024

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.

@rstoneIDBS
Copy link
Author

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 ;)

@WickyNilliams
Copy link
Owner

WickyNilliams commented Nov 1, 2024

I think i'm going to extend the focus() method to allow e.g.:

calendar.focus({ target: "previous" });
calendar.focus({ target: "next" });
calendar.focus({ target: "day" }); // same as...
calendar.focus()

the target names match up with the css part names

@rstoneIDBS
Copy link
Author

I think i'm going to extend the focus() method to allow e.g.:

calendar.focus({ target: "previous" });
calendar.focus({ target: "next" });
calendar.focus({ target: "day" }); // same as...
calendar.focus()

the target names match up with the css part names

That's a nice solution - keeps the API simple and consistent

@WickyNilliams
Copy link
Owner

Just to add, the expected arg extends native FocusOptions, so it'll also allow you to do stuff like:

calendar.focus({
  target: "previous",
  preventScroll: true
})

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants