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

[TreeView] Add disabled prop #20133

Merged
merged 16 commits into from
Aug 1, 2020
Merged

Conversation

netochaves
Copy link
Contributor

Closes #19975
This PR adds a new disabled prop to TreeItem
image

@mui-pr-bot
Copy link

mui-pr-bot commented Mar 15, 2020

@material-ui/lab: parsed: +0.35% , gzip: +0.33%

Details of bundle changes

Generated by 🚫 dangerJS against 8cec22f

@oliviertassinari oliviertassinari added the component: tree view TreeView, TreeItem. This is the name of the generic UI component, not the React module! label Mar 15, 2020
Copy link
Member

@oliviertassinari oliviertassinari left a comment

Choose a reason for hiding this comment

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

Thanks for working on this problem. I believe we can extend the reflection of #19967 to this case.

packages/material-ui-lab/src/TreeItem/TreeItem.js Outdated Show resolved Hide resolved
@netochaves
Copy link
Contributor Author

@oliviertassinari Sure, you want to set this as the default behavior or create a new prop as it was done in #19967? I believe that in this second case, it should be done in a separated PR

@tonyhallett
Copy link
Contributor

You have not applied the aria-disabled attribute.

aria-disabled (state)§
Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable. See related aria-hidden and aria-readonly.

For example, irrelevant options in a radio group may be disabled. Disabled elements might not receive focus from the tab order. For some disabled elements, applications might choose not to support navigation to descendants. In addition to setting the aria-disabled attribute, authors SHOULD change the appearance (grayed out, etc.) to indicate that the item has been disabled.

The state of being disabled applies to the current element and all focusable descendant elements of the element on which the aria-disabled attribute is applied.

You can still select with the keyboard.

Perhaps use context to pass disabled through for when disabling a parent node ?

@eps1lon
Copy link
Member

eps1lon commented Mar 27, 2020

The state of being disabled applies to the current element and all focusable descendant elements of the element on which the aria-disabled attribute is applied.

That's an important point that is currently not tested in this PR. @netochaves Would be nice if you could test behavior of child treeitems of a disabled treeitems.

You can still select with the keyboard.

This seems rather restrictive. Is this quoted from somewhere? We currently disable navigation in all our components. I think we can rethink this later similar to https://github.com/mui-org/material-ui/pull/19967/files

@eps1lon eps1lon added the new feature New feature or request label Mar 27, 2020
@eps1lon eps1lon changed the title [TreeView] disabled-prop [TreeView] Add disabled prop Mar 27, 2020
@tonyhallett
Copy link
Contributor

You can still select with the keyboard.

This seems rather restrictive. Is this quoted from somewhere? We currently disable navigation in all our components. I think we can rethink this later similar to https://github.com/mui-org/material-ui/pull/19967/files

I was referring to https://github.com/mui-org/material-ui/blob/f1a2ec4ebab84d1ffe7b71e9e31904a44efc26c1/packages/material-ui-lab/src/TreeItem/TreeItem.js#L403

<div
        className={classes.content}
        onClick={!disabled ? handleClick : null}

This is the only place where behaviour changes due to the disabled prop being true ( all other changes are styling). This prevents focus by click, toggling expansion and selection. Yet, with the keyboard, you can focus, toggle expansion and select.

@netochaves
Copy link
Contributor Author

That's an important point that is currently not tested in this PR. @netochaves Would be nice if you could test behavior of child treeitems of a disabled treeitems.

Should we disable the expansion of a parent treeItem when it is disabled?

@eps1lon
Copy link
Member

eps1lon commented Mar 28, 2020

Should we disable the expansion of a parent treeItem when it is disabled?

I think so. disabled usually disables interaction. Since expansion is triggered by interaction it should not be possible.

@netochaves netochaves force-pushed the TreeView/disabled-prop branch 2 times, most recently from a39f870 to a648641 Compare April 5, 2020 19:41
@netochaves
Copy link
Contributor Author

Hey guys, there's still work to be done here? please let me know.

@joshwooding joshwooding removed the request for review from dimitropoulos July 26, 2020 00:14
@joshwooding joshwooding changed the base branch from master to next July 26, 2020 00:16
@joshwooding
Copy link
Member

@netochaves Thanks for the head start. I've updated the PR with some more use cases and added some tests. Still need to add a demo with some wording and make sure the styling is working.

@@ -459,14 +479,12 @@ const TreeView = React.forwardRef(function TreeView(props, ref) {

const selectRange = (event, nodes, stacked = false) => {
const { start = lastSelectedNode.current, end, current } = nodes;
if (start != null && end != null) {
Copy link
Member

Choose a reason for hiding this comment

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

Was preventing arrow down + shift from working without an already selected node.

@joshwooding
Copy link
Member

Keeping disabled nodes focusable was easier (and more correct in my opinion)

Copy link
Member

@oliviertassinari oliviertassinari left a comment

Choose a reason for hiding this comment

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

I think that we should demonstrate this in the documentation. I'm not sure about using the first basic demo as it's not a frequent use case. Maybe we could have a new demo, just before the last a11y section?

@joshwooding
Copy link
Member

@oliviertassinari I agree. I don’t think the first demo should be re-used either.

@eps1lon
Copy link
Member

eps1lon commented Jul 26, 2020

Keeping disabled nodes focusable was easier (and more correct in my opinion)

It's definitely an option but we never did this before. Just like selection follows focus we should make this configurable since you don't know if it makes more sense to keep a disabled item in tab order. The authoring practices encourage a consistent set of rules and this would go against it.

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

-- https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_focus_activedescendant

We can definitely rethink our current set of rules but breaking them because it's easier for us is not really a helpful rationale.

If it's hard to get right in a first PR we should definitely add a warning for now. But if we don't have a viable plan to make it work later we should rethink this feature. It seems to me that the path of least resistance is chosen and justified after the fact.

@joshwooding joshwooding requested a review from eps1lon July 26, 2020 15:44
@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged label Jul 29, 2020
@joshwooding joshwooding requested a review from eps1lon July 29, 2020 20:46
@github-actions github-actions bot removed the PR: out-of-date The pull request has merge conflicts and can't be merged label Jul 29, 2020
Copy link
Member

@eps1lon eps1lon left a comment

Choose a reason for hiding this comment

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

Great catches!

Co-authored-by: Sebastian Silbermann <silbermann.sebastian@gmail.com>
@joshwooding
Copy link
Member

NVDA logs for when you can focus disabled items.

image

@joshwooding joshwooding merged commit 08d7334 into mui:next Aug 1, 2020
@joshwooding
Copy link
Member

joshwooding commented Aug 1, 2020

Thanks for the head start @netochaves

kodai3 pushed a commit to kodai3/material-ui that referenced this pull request Aug 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: tree view TreeView, TreeItem. This is the name of the generic UI component, not the React module! new feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[TreeView] Add disabled support
6 participants