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

a11y warnings on the <dialog> element #1000

Open
matys1 opened this issue Aug 2, 2024 · 3 comments
Open

a11y warnings on the <dialog> element #1000

matys1 opened this issue Aug 2, 2024 · 3 comments

Comments

@matys1
Copy link

matys1 commented Aug 2, 2024

I want to add a <dialog> element with some content and add an onClick event handler such that when the user clicks anywhere on the backdrop the <dialog> closes but if the users clicks on the content within the <dialog> it remains open. This was straight forwards to implement so I did:

const handleSidebarBackdrop = (event: React.MouseEvent<HTMLDialogElement, MouseEvent>) => {
  if (sidebarDialogRef.current && event.target === sidebarDialogRef.current) {
    sidebarDialogRef.current.close();
    setSidebarOpen(false);
  }
};

// ...
<dialog onClick={handleSidebarBackdrop} ref={sidebarDialogRef}>

I immediately get two warnings:

  1. Visible, non-interactive elements with click handlers must have at least one keyboard listener.eslint[jsx-a11y/click-events-have-key-events](https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/tree/HEAD/docs/rules/click-events-have-key-events.md)
  2. Non-interactive elements should not be assigned mouse or keyboard event listeners.eslint[jsx-a11y/no-noninteractive-element-interactions](https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/tree/HEAD/docs/rules/no-noninteractive-element-interactions.md)

When I check MDN <dialog> page it says: "The HTML element represents a modal or non-modal dialog box or other interactive component, such as a dismissible alert, inspector, or subwindow."

Why is <dialog> treated as non-interactive when it obviously is interactive? Also I can add onKeyDown event handler to e.g. close the <dialog> on escape key presses to get rid of the first warning but the <dialog> already handles escape key presses natively so this is redundant.

Can someone explain why this is happening?

@ljharb
Copy link
Member

ljharb commented Aug 7, 2024

Why wouldn't you set this on window, so you can capture clicks outside the dialog?

@matys1
Copy link
Author

matys1 commented Aug 8, 2024

@ljharb I was considering that as well. And I suppose that would solve the issue if you don't mind the event bubbling all the way to the window and doing it on that level. Still I find it perhaps a bit limiting that dialog is treated an non-interactive element and you cannot assign any handlers on it.

@torickjdavis
Copy link

@matys1, I believe there's another open issue that's relevant to this discussion; #932.

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

No branches or pull requests

3 participants