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

[no-noninteractive-element-interactions] should accept the dialog role #932

Open
sangikhan29 opened this issue May 16, 2023 · 11 comments
Open
Assignees

Comments

@sangikhan29
Copy link

sangikhan29 commented May 16, 2023

Dialog has to handle events such as moving or resizing so dialog should be able to accept event handler.

If the dialog can be moved or resized, ensure that these actions must be performable by keyboard users as well as mouse users.
reference

Also refer to a similar previous issue about listening to esc to dismiss a dialog

@jessebeach
Copy link
Collaborator

Good points, let me investigate a bit.

@ckundo
Copy link

ckundo commented Jun 7, 2023

👋 @jessebeach any more thoughts on this? anything we can do to help?

@jessebeach
Copy link
Collaborator

I'm consulting the ARIA oracle ☺️

@jessebeach
Copy link
Collaborator

jessebeach commented Jun 8, 2023

So, @mcking65 and I had a chat. Here are his thoughts:

An "ARIA window" is interactive.

However, there are some nuances related to dialog.

We normally expect interactive elements to be focusable. If not directly focusable, referenceable via activedescendant.

A significant contingent of people (including me) assert that from a screen reader perspective, making dialogs focusable is problematic. However, we conceded to allow browsers to focus dialogs as a fallback.

Browser devs need a place to put focus when an HTML dialog opens. There are several ways that authors can set focus and some options for when they don’t. The issue that held up HTML dialog was what browsers should do when authors don’t set focus and the dialog does not contain a focusable element. In this situation, it would be bad if focus were “lost” (e.g., set to the document. Thus, dialogs are “allowed” to be focus. But, this should only happen when necessary as a recovery mechanism.

This is the primary difference between a window and other interactive elements.

So, only roles descended from roletype > widget are considered interactive:

https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/blob/main/src/util/isInteractiveRole.js#L11

The change that we will make is, including roles descended from roletype > window, which will include dialog and alertdialog.

To be determined how we deal with the focus issue in this plugin, if at all.

How does that all sound?

@ckundo
Copy link

ckundo commented Jun 8, 2023

@jessebeach sounds great! thank you for the background and careful consideration. let me know if you want review or a PR!

@sangikhan29
Copy link
Author

Thank you @jessebeach for looking into this! It sounds like a reasonable approach for me as well.

@jessebeach
Copy link
Collaborator

Thank you @jessebeach for looking into this! It sounds like a reasonable approach for me as well.

@sangikhan29, a million apologies! I should have addressed you as well as @ckundo in my responses. This is after all your issue; you brought it up.

@ckundo
Copy link

ckundo commented Jun 16, 2023

@jessebeach @ljharb would you like us to take a stab at a PR? cc @sangikhan29

@ljharb
Copy link
Member

ljharb commented Jun 16, 2023

Yes please :-) that’s what the help wanted label means.

@jessebeach
Copy link
Collaborator

Start with the files in the utility, such as isInteractive.

@jessebeach
Copy link
Collaborator

Set the 'window' role to be interactive.

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

4 participants