[New] no-disabled rule #830

courtyenn · 2022-01-26T21:38:46Z

I didn't see a contribution guideline. I still need to test this out, but just thought I'd submit a PR with the proposed changes.

According to MDN:

The disabled Boolean attribute provides CSS styles and semantics and removes the ability to click or focus while not disabling hover. By removing the ability to focus and removing it from the accessibility tree, it makes it invisible to assistive technology users. For good user experience, you want to make sure everyone can access all the visible content, no matter how they access the web. It is important to be aware that using the disabled attribute can harm usability.

Sources:

codecov · 2022-01-26T21:40:56Z

Codecov Report

Merging #830 (b95ebd2) into main (566011b) will increase coverage by 0.00%.
The diff coverage is 100.00%.

❗ Current head b95ebd2 differs from pull request most recent head 23d6ef9. Consider uploading reports for the commit 23d6ef9 to get more accurate results

@@           Coverage Diff           @@
##             main     #830   +/-   ##
=======================================
  Coverage   99.22%   99.22%           
=======================================
  Files          98       99    +1     
  Lines        1419     1428    +9     
  Branches      479      481    +2     
=======================================
+ Hits         1408     1417    +9     
  Misses         11       11

Impacted Files	Coverage Δ
src/index.js	`100.00% <ø> (ø)`
src/rules/no-disabled.js	`100.00% <100.00%> (ø)`

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 566011b...23d6ef9. Read the comment docs.

ljharb · 2022-01-26T21:46:00Z

Can you elaborate on this? There's many perfectly reasonable cases where it's better to have an input be disabled.

courtyenn · 2022-01-26T21:53:04Z

@ljharb

Can you elaborate on this? There's many perfectly reasonable cases where it's better to have an input be disabled.

I am simply going off MDN on this:

The disabled Boolean attribute provides CSS styles and semantics and removes the ability to click or focus while not disabling hover. By removing the ability to focus and removing it from the accessibility tree, it makes it invisible to assistive technology users. For good user experience, you want to make sure everyone can access all the visible content, no matter how they access the web. It is important to be aware that using the disabled attribute can harm usability.

ljharb · 2022-01-26T21:56:39Z

I did read that, and that is the first time in my entire career I've heard that advice - and it seems a VERY strong position.

Are there other references, a11y guidelines, ecosystem adoption, that confirm the opinion on MDN?

courtyenn · 2022-01-26T21:58:20Z

@ljharb I can certainly do additional digging, but do you think there is a place for this plugin where maybe we warn others of this? I just learned of it today and I would prefer to give this concern exposure.

ljharb · 2022-01-26T22:05:52Z

I absolutely think that this PR is the correct place/way to handle this, assuming the concern is as urgent and valid as MDN implies.

andreasmcdermott · 2022-01-26T22:12:01Z

W3's best practices lists a few specific cases where disabled should be avoided.

Removing focusability from disabled elements can offer users both advantages and disadvantages. Allowing keyboard users to skip disabled elements usually reduces the number of key presses required to complete a task. However, preventing focus from moving to disabled elements can hide their presence from screen reader users who "see" by moving the focus.

Authors are encouraged to adopt a consistent set of conventions for the focusability of disabled elements. The examples in this guide adopt the following conventions, which both reflect common practice and attempt to balance competing concerns.

For elements that are in the tab sequence when enabled, remove them from the tab sequence when disabled.
For the following composite widget elements, keep them focusable when disabled:

Options in a Listbox

Menu items in a Menu or menu bar

Tab elements in a set of Tabs

Tree items in a Tree View

ljharb · 2022-01-26T22:13:25Z

That suggests that it'd be better to forbid "disabled" by default only on those four kinds of elements (altho an option to forbid it "everywhere" is fine). Thoughts?

andreasmcdermott · 2022-01-26T22:28:47Z

To me, two key take-aways from WAI-Aria's section:

Authors are encouraged to adopt a consistent set of conventions for the focusability of disabled elements.
[...] make them focusable if discoverability is a concern.

The second bullet refers to elements in a toolbar, but it seems like it could apply to any element. Eg I've seen it recommended that submit-buttons that are "disabled" until all required fields are completed should be focusable to ensure users can find it even before they complete the fields.

I'm not sure what the eslint rule should be though.. Maybe it is reasonable to only default to the four types of composite widgets mentioned in the WAI-Aria section. But I'm not sure that it's intended to be a complete list.

courtyenn · 2022-01-26T23:10:16Z

W3 states,

Authors are encouraged to adopt a consistent set of conventions for the focusability of disabled elements.

I think that means disabled is up for interpretation, but whatever it is, it should be adhered to. I believe assistive technology users should know about form elements, whether they are disabled or not. (Assuming this content is visible) Same goes for buttons that may be disabled due to permission. (Tabs, buttons, etc.) They ought to know. No?

To me a question I'd like answered is if the input isn’t hidden for visual users (when disabled); why hide it for non-visual users?

**Edit: (when disabled)

ljharb · 2022-01-27T04:31:13Z

There’s a lot of things visually on a page that are hidden for non-visual users - borders, aspects of how a button looks, background colors and images - it doesn’t automatically make sense for something to be in the a11y tree just because it’s visible.

That said, i can imagine a good chunk of the places I’ve used the disabled attribute in the past are things whose presence would be useful for a non-visual user to know about. To be honest, this really feels like a bug/flaw in the way the a11y tree is built - ie, that it shouldn’t be omitting these elements. To be forced to use an aria attribute seems pretty absurd; their purpose is to provide additional info, or to hack around non-semantic html.

courtyenn · 2022-01-27T04:59:28Z

The attribute was brought up in a code review session today.

I have a list of actions I'd like the user to take to onboard. However, they are not able to manually click on these checkboxes, but are there to serve as a visual cue if the user completed the actions. In this case, I chose to use disabled but that would hide the completion status from the screen-reader, so I chose to use aria-disabled instead.

ljharb · 2022-01-27T05:07:52Z

The choice is meaningful and important; but it really does seem like the default should be to include them, and the aria override should be to hide them.

jessebeach · 2022-01-31T03:27:17Z

That suggests that it'd be better to forbid "disabled" by default only on those four kinds of elements (altho an option to forbid it "everywhere" is fine). Thoughts?

To be honest, this really feels like a bug/flaw in the way the a11y tree is built - ie, that it shouldn’t be omitting these elements.

Great conversation here. This came up at work the other day and Matt King also recommended not using the disabled attribute because, as folks have noted here, it knocks the elements out of the AX Tree. Instead, authors should use aria-disabled, which conveys the disabled-ness of the element, but leaves the element in the AX Tree so it can be perceived. @courtyenn notes this approach above, as well.

I'm in favor of this rule. Let me review the code. I think we should get it in.

jessebeach

@courtyenn this is really fantastic! It's close, just a few nits to clean up. The basic logic is there. This is a great idea. Thank you for proposing it!

docs/rules/no-disabled.md

src/rules/no-disabled.js

jessebeach · 2022-01-31T03:49:35Z

src/rules/no-disabled.js

+    JSXAttribute: (attribute) => {
+      // Only monitor eligible elements for "disabled".
+      const type = elementType(attribute.parent);
+      if (!DEFAULT_ELEMENTS.includes(type)) {


I recall that we have support issues with includes and older versions of Node. Could you rewrite this as a for loop?

@ljharb do you have an issue with includes?

I have a much larger issue with loops :-) we support down to eslint 3, which requires node 4+, which lacks .includes. However, we can and should use the array-includes package for this, which will prefer the native method when available.

Got it. I will endeavor to commit this detail to memory for the next time =D

ljharb · 2022-01-31T05:21:52Z

@jessebeach is there any effort to fix this in browsers? semantic non-aria attributes are supposed to be the best approach, and this seems like the odd one out.

jessebeach · 2022-01-31T20:10:28Z

is there any effort to fix this in browsers? semantic non-aria attributes are supposed to be the best approach, and this seems like the odd one out.

Agreed. I haven't heard any rumblings of changing this behavior and my sense here is that this horse is long out of the barn, never to return. I think they just got the default behavior wrong here, probably because this attribute predates or is contemporaneous with assistive tech cursor traversal.

@courtyenn I think what @ljharb is insinuating, is that this rule is encouraging counter-intuitive behavior. It runs contrary to the general heuristic "Use semantic HTML first; ARIA second or not at all". So the explanation for this rule should acknowledge that this behavior runs counter to the general advice: https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/pull/830/files#diff-1cf5c60cfe95228a04407905406f8fc98a66b9b0d0bc27f474e23a8976f8b206R3

ljharb · 2022-02-11T04:19:31Z

docs/rules/no-disabled.md

@@ -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.


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.

jessebeach

@courtyenn this is really close! Just a few copy changes to tighten up the documentation. This is really good stuff!

jessebeach · 2022-02-12T02:04:23Z

docs/rules/no-disabled.md

+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
+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.


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."

jessebeach · 2022-02-12T02:11:19Z

src/rules/no-disabled.js

+  generateObjSchema,
+} from '../util/schemas';
+
+const warningMessage = 'The disabled prop removes the element from being detected by screen readers.';


"The disabled attribute makes the element imperceivable to assistive technology agents, like screen readers."

Just a small nit that an attribute is a HTML feature, whereas a prop is a DOM concept. In this case, we are detecting the presence of an attribute, not a prop.

Also, we should avoid being screen-reader-centric. There are many assistive technology agents. Screen readers are common and probably what a developer is familiar with, so it helps to mention them. We just want to be sure we leave room for the full spectrum of agents that we need to support.

jessebeach · 2022-02-16T19:45:29Z

@courtyenn it looks like the JS error in the tests is caused by the changes you introduced. Could you have a look?

Courtney Nguyen added 2 commits January 26, 2022 11:54

[New] no-disabled rule

c95e07b

Only target specific elements to run eslint rule on

aa41427

Courtney Nguyen added 3 commits January 26, 2022 21:21

Added tests, and switched rule from erroring to warning

1d89958

Typo

b2cfb4b

Updated wording, added additional tests

b95ebd2

jessebeach requested changes Jan 31, 2022

View reviewed changes

Add elements to rule config so they can be overriden

167c235

ljharb added the new-rule label Feb 10, 2022

Courtney Nguyen added 2 commits February 10, 2022 20:31

Added rule details cautioning the usage of disabled

a556263

Added rule details cautioning the usage of disabled

23d6ef9

ljharb reviewed Feb 11, 2022

View reviewed changes

jessebeach requested changes Feb 12, 2022

View reviewed changes

huyenltnguyen mentioned this pull request Mar 25, 2024

feature(UI): Help modal form freeCodeCamp/freeCodeCamp#53824

Merged

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[New] no-disabled rule #830

[New] no-disabled rule #830

courtyenn commented Jan 26, 2022 •

edited

codecov bot commented Jan 26, 2022 •

edited

ljharb commented Jan 26, 2022

courtyenn commented Jan 26, 2022

ljharb commented Jan 26, 2022

courtyenn commented Jan 26, 2022

ljharb commented Jan 26, 2022

andreasmcdermott commented Jan 26, 2022

ljharb commented Jan 26, 2022

andreasmcdermott commented Jan 26, 2022

courtyenn commented Jan 26, 2022 •

edited

ljharb commented Jan 27, 2022

courtyenn commented Jan 27, 2022

ljharb commented Jan 27, 2022

jessebeach commented Jan 31, 2022

jessebeach left a comment

jessebeach Jan 31, 2022

jessebeach Jan 31, 2022

ljharb Jan 31, 2022

jessebeach Jan 31, 2022

ljharb commented Jan 31, 2022

jessebeach commented Jan 31, 2022

ljharb Feb 11, 2022

jessebeach left a comment

jessebeach Feb 12, 2022

jessebeach Feb 12, 2022

jessebeach commented Feb 16, 2022

[New] no-disabled rule #830

Are you sure you want to change the base?

[New] no-disabled rule #830

Conversation

courtyenn commented Jan 26, 2022 • edited

codecov bot commented Jan 26, 2022 • edited

Codecov Report

ljharb commented Jan 26, 2022

courtyenn commented Jan 26, 2022

ljharb commented Jan 26, 2022

courtyenn commented Jan 26, 2022

ljharb commented Jan 26, 2022

andreasmcdermott commented Jan 26, 2022

ljharb commented Jan 26, 2022

andreasmcdermott commented Jan 26, 2022

courtyenn commented Jan 26, 2022 • edited

ljharb commented Jan 27, 2022

courtyenn commented Jan 27, 2022

ljharb commented Jan 27, 2022

jessebeach commented Jan 31, 2022

jessebeach left a comment

Choose a reason for hiding this comment

jessebeach Jan 31, 2022

Choose a reason for hiding this comment

jessebeach Jan 31, 2022

Choose a reason for hiding this comment

ljharb Jan 31, 2022

Choose a reason for hiding this comment

jessebeach Jan 31, 2022

Choose a reason for hiding this comment

ljharb commented Jan 31, 2022

jessebeach commented Jan 31, 2022

ljharb Feb 11, 2022

Choose a reason for hiding this comment

jessebeach left a comment

Choose a reason for hiding this comment

jessebeach Feb 12, 2022

Choose a reason for hiding this comment

jessebeach Feb 12, 2022

Choose a reason for hiding this comment

jessebeach commented Feb 16, 2022

courtyenn commented Jan 26, 2022 •

edited

codecov bot commented Jan 26, 2022 •

edited

courtyenn commented Jan 26, 2022 •

edited