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

Add ignoreNonDOM to jsx-a11y/no-autofocus #56

Open
thayannevls opened this issue May 27, 2020 · 7 comments
Open

Add ignoreNonDOM to jsx-a11y/no-autofocus #56

thayannevls opened this issue May 27, 2020 · 7 comments
Assignees
Labels
practices/patterns stale This will not be worked on style

Comments

@thayannevls
Copy link

thayannevls commented May 27, 2020

What is to be discussed?
At Styleguide we implement components with the autoFocus feature without using the native HTML attribute. So it's safe to ignore this rule for components created by developers.

Describe the solution you'd like
Add this argument to the de jsx-a11y/no-autofocus rule.

How we do this today?
We are ignoring this rule to be able to use the autoFocus property of our components.

@rerissondaniel
Copy link
Contributor

rerissondaniel commented May 27, 2020

I would really love an opinion of an accessibility expert, since using autofocus may reduce the actions needed to do something but I'm not sure about which impacts this has on accessibility :/

@kaisermann
Copy link
Contributor

Are you ignoring the rule in a per line basis or did you add an override in the .eslintrc?
Nevertheless, I think linting only native DOM elements should be enough, since a component could have any kind of behavior related to a autofocus prop (which is something debatable, of course).

More opinions on this matter would be great!

@thayannevls
Copy link
Author

thayannevls commented May 27, 2020

@kaisermann I only saw ignoring per line but it's very common.

@rerissondaniel About accessibility, autofocusing an element being a bad or good practice really depends on the context you are using it. For example, using autoFocus in a Form may be confusing but using in a Modal to focus on the content instead of the close button(the first element inside it) can be good. You can see the example of the modal here https://www.w3.org/TR/wai-aria-practices/#keyboard-interaction-7

@rerissondaniel
Copy link
Contributor

@rerissondaniel About accessibility, autofocusing an element being a bad or good practice really depends on the context you are using it. For example, using autoFocus in a Form may be confusing but using in a Modal to focus on the content instead of the close button(the first element inside it) can be good. You can see the example of the modal here https://www.w3.org/TR/wai-aria-practices/#keyboard-interaction-7

That's nice, thank you!

@felippenardi
Copy link

I recently implemented a property in the Styleguide <Alert> to allow the developer to choose to enable autofocus when the element appears in the screen.

I named it focusOnOpen since autoFocus was not allowed.

During this process I also implemented another property that manipulated the focus when the alert closed, and it turned out yield in a terrible accessibility experience.

It is really hard to tell when we should or shouldn't use autoFocus, so I think it is good to have that eslint rule there to prevent us from forgetting it.

Maybe we do want to ignore it everywhere we use, so we are explicitly stating we know what we are doing.

@thayannevls
Copy link
Author

@felippenardi What do you think about changing it to be a warning instead of an error?

@stale
Copy link

stale bot commented Jun 9, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this is a discussion thread, the most voted option will be final. Thank you for your contributions.

@stale stale bot added the stale This will not be worked on label Jun 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
practices/patterns stale This will not be worked on style
Projects
None yet
Development

No branches or pull requests

4 participants