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.

Sign up for GitHub

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

Jump to bottom

[New] no-disabled rule #830

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from
Draft

[New] no-disabled rule #830

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
c95e07b
[New] no-disabled rule
Jan 26, 2022
aa41427
Only target specific elements to run eslint rule on
Jan 26, 2022
1d89958
Added tests, and switched rule from erroring to warning
Jan 27, 2022
b2cfb4b
Typo
Jan 27, 2022
b95ebd2
Updated wording, added additional tests
Jan 27, 2022
167c235
Add elements to rule config so they can be overriden
Feb 10, 2022
a556263
Added rule details cautioning the usage of disabled
Feb 11, 2022
23d6ef9
Added rule details cautioning the usage of disabled
Feb 11, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
3 changes: 1 addition & 2 deletions docs/rules/no-disabled.md
View file
Open in desktop
Expand Up @@ -3,8 +3,7 @@
Rule that `disabled` prop should be cautioned on elements. Disabling interactive elements removes the element from the accessibility tree. Consider using `aria-disabled`.

## Rule details

Warns usage of `disabled` property.
The general consensus is that `disabled` should be used with specific intent. It goes against intuition since `disabled` is a native HTML attribute, which disables. However, from a usability stand-point it is not a good UX for screen readers: It removes the element from the a11y tree, and may omit critical information. It is best to use `aria-disabled` and add the additional JS logic to "disable" the element.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The general consensus is that `disabled` should be used with specific intent. It goes against intuition since `disabled` is a native HTML attribute, which disables. However, from a usability stand-point it is not a good UX for screen readers: It removes the element from the a11y tree, and may omit critical information. It is best to use `aria-disabled` and add the additional JS logic to "disable" the element.
The general consensus is that `disabled` should be used with specific intent. It goes against intuition since `disabled` is a native HTML attribute, which disables. However, from a usability standpoint it is not a good UX for screen readers: it removes the element from the a11y tree, and may omit critical information. It is best to use `aria-disabled` and add additional JS logic to "disable" the element.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to be a bit more prescriptive here with this text. Apologies for the heavy-handed editing:

"The disabled attribute renders an HTML form element inoperable -- it cannot be focused or pressed. Disabled elements are visually rendered with lighter backgrounds and borders, indicating through visual affordance that they are present but inoperable. Unfortunately, an HTML form element with the disabled attribute is not rendered to the Accessibility Tree, so if a user cannot perceive the interface visually, they will not perceive the disabled form elements.

For this reason, we recommend that authors not use the disabled HTML attribute, which admittedly goes against the common best practice to use semantic HTML. Instead, use aria-disabled to indicate to assistive technology agents that an element is disabled. Additionally, use CSS to alter the appearance of an element to give it the visual appearance of a disabled state and use JavaScript to prevent the default behaviors of the element."


### Succeed
```jsx
Expand Down