[DatePicker] Strange black border in the calendar

[Angelk90]

Steps to reproduce

• I open the link in question
• Click on input Mobile start
• The calendar opens as shown

Live example: https://v4-0-0-alpha-5.material-ui-pickers.dev/demo/daterangepicker#responsiveness

Bugs

• Mobile fixe in Better recognition of touch devices material-ui-pickers#1653:

• Dekstop:

Environment

Tech	Version
@material-ui/lab	v5.0.0-alpha.16

[oliviertassinari]

@Angelk90 Thanks for opening the issue. We have two possible ways forward, by order of personal preference:

1. ✅ We remove the container from the focus ring [TrapFocus] Make possible to avoid focusing wrapper #19651, if it gets focused, we move it to the first focusable element inside the popup. It will help with a11y at the same time.
2. We only trigger the outline when the modality is keyboard, we have a useFocusVisible.js helper in the core.

[oliviertassinari]

While the issue describes the issue on mobile here is the one we can witness on desktop:

[dmtrKovalenko]

This behavior should be fixed in core by #19651

And if it will be done changes from mui/material-ui-pickers#1653 will not be needed at all. But for now we need to properly visualize focused element for a11y.

[oliviertassinari]

@dmtrKovalenko Right, so we agree 1. sounds like the best direction :).

In #19651, without more context, I would be in favor of making it a non-default behavior to be more resilient. I believe in order to implement the logic, we will need to determine the list of focusable elements in the element, this logic has limitations and ask for a non-negligeable amount of bundle size: https://bundlephobia.com/[email protected]

[dmtrKovalenko]

So what do you propose? Close this issue by fixing this border in most of cases (for mobile), or left it open while it not will be fixed at all?

[oliviertassinari]

@dmtrKovalenko I think that hiding the outline on touch devices is a great step in the right direction.

Now, I suspect that most people are using Material-UI on the desktop. I wish we had more data to see clearly in the mobile vs desktop split. My best guess is 1/3 mobile and 2/3 desktop. Some of the imperfect data we have available:

• The last date picker survey: https://www.surveymonkey.com/results/SM-ZR2PJF7Q7/. Desktop support is important, but we don't have mobile support to compare, unfortunately.

• In the current Material-UI survey (still running), people are mostly building enterprise application, I'm not sure this frequently includes a mobile version of it. Unfortunately, we didn't ask if people target mobile, desktop, or both.

Going forward, I think that we will be able to collect this data by looking at the behavior of our documentation. We could have a standalone demo / API pages for mobile and one for desktop. For instance, I think that we could learn a great deal from the number of sessions comparing a https://material-ui.com/api/mobile-date-picker vs https://material-ui.com/api/desktop-date-picker. Soon or later, we will get this information :).

---

Sorry, back to your initial question. I think that we have an opportunity to solve the problem at 100% so I would be in favor of keeping it open until it's resolved for mobile and desktop.

[ravi-poonia]

@oliviertassinari The strange border is still there for MobilePicker

[dmtrKovalenko]

@ravi-poonia this is expected behaviour because for people with poor vision using datepicker on mobile is extremely required to
understand where the focus is right now.

[ravi-poonia]

I'm planning to use the MobilePicker for desktop due to some design constraints, so it doesn't look that good. Is there any way to disable it?

[dmtrKovalenko]

You could pass outline: none to the DatePicker root

[ravi-poonia]

I tried to do that but it's still happening, @dmtrKovalenko can you provide a simple code sample