[RadioButton][Checkbox] Can't select (highlight) option text

[amoedoamorim]

• I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

You should be able to select text from the options labels in order to copy and paste it somewhere else.

Current Behavior

It's not possible to select/highlight the text in the option labels. What happens when you try to click and drag over the text is the option gets selected and nothing else.

Steps to Reproduce (for bugs)

1. Have a form with Checkbox or RadioButton controls.
2. Click and drag over the option labels text attempting to select the text
3. Text does not get selected

Context

Users cannot copy and paste text from option labels in order to google/research/translate or do whatever they may need with such string. Please note that such behavior is possible on Google forms, as per screenshot: https://imgur.com/Fa5B6oO

Your Environment

Tech	Version
Material-UI	0.18.7
React	15.6.2
browser	Chrome 61.0.3163.91

[oliviertassinari]

After benchmarking the other libraries, I think that you are right, they no real motivation for preventing the text selection. We can safely remove this line:
https://github.com/mui-org/material-ui/blob/ddde3c93235f170d2781749a8907005fc12372eb/src/Form/FormControlLabel.js#L24

[mbrookes]

@oliviertassinari I can think of a couple of reasons:

Selecting and then unselecting a checkbox by clicking on the label will highlight the label text (as if it has been double-clicked).

Users with lower motor control or using assitive input devices may find themselves unintentionally selecting the text.

ISTR we had fairly detailed discussion about this when this was introduced on v0, and I believe we are followin best practice.

@amoedoamorim Is free to override this behaviour in his application.

[Chopinsky]

I think alternatively, we can use right click instead of double click to select the checked option, this may not be the most intuitive behavior, but should resolve the concern @mbrookes has raised.

[oliviertassinari]

@mbrookes Some benchmark:

Allow selection: 😀

• native input + label
• https://material-components-web.appspot.com/checkbox.html
• https://material.angular.io/components/radio/overview
• http://getbootstrap.com/docs/4.0/components/forms/#default-stacked

Don't allow selection:

• https://next.vuetifyjs.com/components/selection-controls

[mbrookes]

I looked at lots more - it's more like 50/50. The usability concerns are real, but @Chopinsky's requirement is pretty unique. No-one else has asked for this.

He can easily do that for his use case: https://material-ui.com/customization/overrides.

[oliviertassinari]

@mbrookes How is the native <label>, Bootstrap and material-web-components behaving this way not a signal strong enough? Do you have an example of a serious library doing it the other way around?

[mbrookes]

Let's consult the most visited website in the world:
https://www.google.com/preferences

(OTOH, youtube.com does the opposite...)

Here are a few frameworks:

• http://react-toolbox.io/#/components/checkbox
• http://materializecss.com/forms.html
• https://vuetifyjs.com/components/selection-controls
• https://react.semantic-ui.com/modules/checkbox

All of these are intentionally applying user-select: none;. Those that aren't may simply not have given it any thought - we don't know that they're intentionally not applying it.

So, the jury is out. I suggest we wait for upvotes rather than changing this to accomodate one user.

[oliviertassinari]

it's more like 50/50.

@mbrookes It's the whole point, there is enough signal out there. It's telling us that being opinionated about the default behavior is wrong. To date, the components I have best-seen implementing accessibility are the native elements. So maybe they are wrong, but I think that we would be better off not taking any bet and relying on the default browser behavior:

• Google Chrome: chrome://settings/
  
• native <label>
  
• react-toolbox
  
• ant design
  
• YouTube
  
• Bootstrap
  

[mbrookes]

Dude, I can paste just as many screenshots where you can't accidentally select the label, and where we know this is an intentional design choice. We don't know that any of your examples are by design, or whether it just simply hasn't been considered. I posted signal, you posted noise.

I'll grant you native does this - if it didn't, it wouldn't be the default for those libraries that haven't given it any thought, but here's just one of the problems:

If we're going to follow native, that affects a whole lot more than just user-select.

Further, a primary use-case of Material-UI is mobile apps. Please show me any Material Design (or other) mobile app where you can accidentally select form label text by tapping it twice, or unintentionally swiping?

[oliviertassinari]

Further, a primary use-case of Material-UI is mobile apps. Please show me any Material Design (or other) mobile app where you can accidentally select form label text by tapping it twice, or unintentionally swiping?

@mbrookes I would say it's a different concern. I think that the problem should be solved this way with mobile applications. It has to be global:

html {
  user-select: none;
}

[oliviertassinari]

@mui-org/core-contributors Guys, what do you want to do on this issue? We can't reach a consensus. Either we wait for more user feedback, or you can speak up.

[amoedoamorim]

Let me add that the Google Forms allow the behaviors to coexist. You can both select the option and highlight the text by clicking on the label. One thing does not exclude the other. Right clicking to select sounds weird and pretty unnatural.

[amoedoamorim]

Can I ask for help here on how to override this behavior in my app?

I tried passing labelStyle={{ userSelect: 'all' }} to the RadioButton without success.

[oliviertassinari]

I have no clue with v0.x. The issue was fixed for v1.x.