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

SC 2.1.2 Tab looping #4185

Open
Que-tin opened this issue Dec 24, 2024 · 1 comment
Open

SC 2.1.2 Tab looping #4185

Que-tin opened this issue Dec 24, 2024 · 1 comment

Comments

@Que-tin
Copy link

Que-tin commented Dec 24, 2024

There is a problem with the following example that leads to major differences between the browser and open source implementations for the dialogs:

When the dialog has been opened, focus is trapped within the dialog; tabbing from the last control in the dialog takes focus to the first control in the dialog. The dialog is dismissed by activating the Cancel button or the OK button.

imo there is too much room for interpretation and clearer guidance is needed that defines a "Best Practice" for this specific scenario. Otherwise it leads to further inconsitency between implementations.

The native <dialog> doesn't support tab looping at all while most open source libraries are on the other extrema and don't provide an option to disable it.

With clearer guidance one or the other would need to be adjusted to fulfil the Level A requirements.

@fstrr
Copy link
Contributor

fstrr commented Dec 27, 2024

It looks like this relates to No Keyboard Trap.

You say "The native <dialog> doesn't support tab looping at all", which isn't the case—see this quick demo where, when the dialog is open, it's not possible to navigate to the elements on the underlying page. It does allow the user to navigate to the browser's "chrome", which is fine, and then back into the open modal dialog.

It looks like the example hasn't been updated since the native dialog element became fully supported. It could be updated to clarify that both trapping inside a modal dialog and allowing the user to access the browser's chrome is fine, as long as there's an accessible method to close the modal dialog. Does that work for you?

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

No branches or pull requests

2 participants