Skip to content

Conversation

@DanailH
Copy link
Member

@DanailH DanailH commented Feb 23, 2021

Fixes #881
Fixes #882

@DanailH DanailH added type: bug It doesn't behave as expected. accessibility a11y scope: data grid Changes related to the data grid. labels Feb 23, 2021
@DanailH DanailH self-assigned this Feb 23, 2021
<Paper>
<ClickAwayListener onClickAway={onClickAway}>{children}</ClickAwayListener>
<ClickAwayListener onClickAway={onClickAway}>
<div>{children}</div>
Copy link
Member

@oliviertassinari oliviertassinari Feb 23, 2021

Choose a reason for hiding this comment

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

I think that it should aways be a MenuList as a first child (can be coming from {children}). Why is it not working in HEAD?

Copy link
Member Author

@DanailH DanailH Feb 23, 2021

Choose a reason for hiding this comment

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

It's weird, it works for the export and the density but it doesn't for the column menu, by not working I mean it throws a warning in the console.

The error is that the passed children need to be able to hold a ref. This fixes the issue for all cases we currently have and I can't see any regressions.

Copy link
Member

@oliviertassinari oliviertassinari Feb 24, 2021

Choose a reason for hiding this comment

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

Ok, I had a look. Any weird behavior is an invitation for exploration :). The GridColumnMenu component isn't forwarding its ref, not the extra props to the MenuList component. It could be solved easily but, there a bunch of extra props (the GridBaseComponentProps) and it's not versatile.

Instead, I have pushed a commit to reorganize the composition order. Grow doesn't host any div, it needs to apply props to its children, same for ClickAwayListener. We save one DOM node.

In the process, I have found an improvement opportunity in the core, ClickAwayListener could forward its props to the children, it doesn't.

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.

Things I have seen, we aren't too far:

  • There are two approved suggestions that were only partially applied in the changes.
  • As far as I know, Tab should prevent default, there is a native behavior (it scrolls the page before the focus moves back to where it should be) we want to disable. On the other hand, Escape has no native behavior hence we don't need to prevent default. It seems to be how the Menu in the core behaves. It makes me think of mui/material-ui#13470 (comment)
  • The focus isn't moving to the first item in the list. Related to mui/material-ui#17571.
  • I don't understand what we do with useId. Did you look at what the hook is doing and the requirement for the id to work correctly? In the current usage, using the hook or not changes nothing.

<Paper>
<ClickAwayListener onClickAway={onClickAway}>{children}</ClickAwayListener>
<ClickAwayListener onClickAway={onClickAway}>
<div>{children}</div>
Copy link
Member

@oliviertassinari oliviertassinari Feb 24, 2021

Choose a reason for hiding this comment

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

Ok, I had a look. Any weird behavior is an invitation for exploration :). The GridColumnMenu component isn't forwarding its ref, not the extra props to the MenuList component. It could be solved easily but, there a bunch of extra props (the GridBaseComponentProps) and it's not versatile.

Instead, I have pushed a commit to reorganize the composition order. Grow doesn't host any div, it needs to apply props to its children, same for ClickAwayListener. We save one DOM node.

In the process, I have found an improvement opportunity in the core, ClickAwayListener could forward its props to the children, it doesn't.

@DanailH
Copy link
Member Author

DanailH commented Feb 25, 2021

Things I have seen, we aren't too far:

  • There are two approved suggestions that were only partially applied in the changes.
  • As far as I know, Tab should prevent default, there is a native behavior (it scrolls the page before the focus moves back to where it should be) we want to disable. On the other hand, Escape has no native behavior hence we don't need to prevent default. It seems to be how the Menu in the core behaves. It makes me think of mui-org/material-ui#13470 (comment)
  • The focus isn't moving to the first item in the list. Related to mui-org/material-ui#17571.
  • I don't understand what we do with useId. Did you look at what the hook is doing and the requirement for the id to work correctly? In the current usage, using the hook or not changes nothing.

Alright, I pushed the changes requested.

A couple of things, I'll keep autoFocus for the GridColumnMenu because the autoFocusItem is not working due to the current structure (needs refactoring if we want to make it work). It's still accessible via the keyboard. The drawback is that the focus is not on the first element but on the wrapper and you need one arrow to click to select the first or last element in the menu.
Another thing was the ids for the columne menu and the 3dot button - went for the option of keeping them in the state for the time being (there was already a columnMenu section in the state that holds the field so I added the id and the labelledby as well).

* @param labelledby
*/
showColumnMenu: (field: string) => void;
showColumnMenu: (field: string, id: string, labelledby: string) => void;
Copy link
Contributor

Choose a reason for hiding this comment

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

why do we need id and labelledBy to show the column menu? And how can consumers get them?

Copy link
Member Author

@DanailH DanailH Feb 25, 2021

Choose a reason for hiding this comment

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

We need them so that the labelledby and the controlledby are hooked up correctly. I had to do it like this because they that the menu and the button are set up that is the only option. In terms of how users can get them -> there are in the state while the menu is opened.

Copy link
Contributor

Choose a reason for hiding this comment

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

ShowColumnMenu should only show the menu when one click on the 3 dots icon next to the column title.
Is that still the case?

there are in the state while the menu is opened.

Well showColumnMenu opens the menu so how can we know the labelledBy before we call the showColumnMenu. Chicken and egg situation? :)

Copy link
Member Author

@DanailH DanailH Feb 25, 2021

Choose a reason for hiding this comment

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

I mean the existing functionality still works the same. Also, why do we need to know the ID beforehand it is for hooking up the accessibility, there are no functionalities or styles attached to it?

Copy link
Member Author

Choose a reason for hiding this comment

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

@dtassone can I merge this, it would be nice to include the fix in the upcoming release 🙃

Copy link
Contributor

Choose a reason for hiding this comment

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

how do you render the grid with the menu open. Imagine if the user want to put a custom component...

Copy link
Contributor

Choose a reason for hiding this comment

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

How is it harmful?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think that would be an issue, they can still open it right, it's just that the id and the labelledBy won't be set

Copy link
Member

@oliviertassinari oliviertassinari Feb 26, 2021

Choose a reason for hiding this comment

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

How is it harmful?

It could prevent us to improve the internal: e.g. this very discussion. I don't understand the use cases for a developer to programmatically open a column menu from outside the normal end-user flows. Wouldn't it be better to say a temporary NO and wait for a developer to come up with a valid use case?

they can still open it right, it's just that the id and the labelledBy won't be set

So the a11y would be broken?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think that would be an issue, they can still open it right, it's just that the id and the labelledBy won't be set

why not make them optional?
Also why calling it id? Something like menuElementId or whatever a bit more specific so it's more understandable

@DanailH DanailH merged commit 635dbb2 into mui:master Feb 26, 2021
@oliviertassinari oliviertassinari changed the title [DataGrid] Make GridMenu accessible [DataGrid] Fix menu accessible Feb 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

accessibility a11y scope: data grid Changes related to the data grid. type: bug It doesn't behave as expected.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[DataGrid] The column menu isn't accessible [DataGrid] The density selector isn't accessible

3 participants