Not everyone is fluent in every language, and not every website works perfectly with the browser's translator.
There will be situations where people will want to translate that ONE word that is actually in a button or tab, and isn't selectable because someone thought they knew better.
In Firefox my tabs have text, and I frequently rearrange tabs with my cursor. I think this is a pretty common usage pattern (I do it on a daily basis). It would be an enormous pain if most of the area on the tab turned my arrow cursor into an I-beam cursor that I couldn't move the tab with. I checked Chrome and it looks like the tabs work the same way.
While having the text in the tabs is very useful to know what is under them, I don't think I've ever needed to actually copy the tab text. It would be a huge UX downgrade for me (and I think most people) if the tab text was selectable.
Some people might need it to be selectable for accessibility reasons and there should be a toggle for that, but I don't think "absolutely all text everywhere is selectable" is a good default.
The example I am answering to was prefaced as being by a web dev, so I am only talking about websites here.
For Apps agree, as I can install different ones and pick the language regardless of where I am traveling, etc. And page titles (that go on browser tabs) rarely need selection/translation.
The essential case where it makes sense for text to be non-selectable is on objects that can be dragged around. You definitely don't want to get the text selected when the user wanted to move its container.
Typically application tabs can be moved or recorded by dragging, and tabs in web pages can't; that would justify a different treatment. But it's because of the different behaviour of the tabs, not the different media
> should non-draggable elements in native apps be selectable?
Definitely yes. I hate it when I see an error message or a button label and I can't select the text to copy it for searching comments for it on the web.
That's arguably the problem of the common interaction patterns in GUIs being non-modal. Could've been easily solved early on by having a convention like "holding Meta (Alt) makes all text on screen selectable" and sticking with it.
At this point, it's not even a technical problem anymore - it's a social one. Even if somehow OS and browser vendors all agreed on a scheme like this, copyright industry and security people would scream bloody murder and prevent it from being implemented.
It's not just about translations, either. Sometimes you want to document or describe to someone where something is on a site. "Click on FooBar, then in the popup saying <<Are you sure FooBar is the right Frob>> check the <<Cheesy Cheese Burger>> checkbox and click OK.
It's much less frustrating when you can copy-paste the damned labels straight off the site/app, than retyping them and hoping you didn't misspell FooBar as FooBaz, leading the other person into deeper trouble rather than helping.
And since I don't do webdev for a living, most of my quite frequent use of Developer Tools is to work around this kind of nonsense - non-copyable text, obscured text, layout breakage, etc. Second biggest use case is to unbreak web forms that fail silently or for bogus reasons. This happens surprisingly often.
That is a i18n issue with the website itself? Or are you saying you know a good portion of a language, but you aren't fluent, so you read it in whatever the default language is, by default, without translating the page or using it in your native language?
Depends. Sometimes I know the language partially, sometimes I can move around using pure context, and other times translation is possible in most pages.
Disabling selection in non-textual parts of websites is unfortunately something that happens quite frequently, but people rarely notice.
This is naturally for websites without i18n. Very common especially in government and public websites.
This sounds perhaps a bit rude but it isnt possible to optimize for every possible use case someone somewhere may have. At the end of the day, a line has to be drawn.
It's not about optimizing, it's about not doing additional work just to break the expected behavior of the web platform. So far there was no explanation of where default behavior breaks keyboard usage, for example, only opinions.
I meant optimizing every possible usecase. Did you know the button on this very site is not selectable? When you use real semantic html with submit inputs, not buttons, there is text that is not selectable. But it is a button? See what I mean? Draw the line somewhere.
As mentioned in other comment, not all html which looks like a button is a button. It does in fact take extra work to make everything selectable. On native apps it is even harder because the frameworks do not have selection as built in.
To be clear, I HATE that almost everything isn't selectable. It is one of many reasons why I never use mobile apps. Still, somewhere there has to be a line to ship anything.
I think this is where semantic HTML comes in. Doing other wack or bespoke things is, IMO, not just bad form - it's more work. Just do things the easy way and it'll work.
isn't selectable because it breaks the UX for keyboard-only users.
Has nothing to do with "thinking" anything. It's about testing with accessibility parameters and knowing* what practical problems occur.
If you really need to translate ONE WORD, it's not that onerous to type it. You're bringing edge-case hypotheticals to a discussion about practical functionality.
I already asked below, how and where does it break?
Hacker News is fully selectable, and still fully useable with the keyboard.
> it's not that onerous to type it.
Yes it is, if I don't even know what the letters are. Not every country uses the latin alphabet. And not every people coming to latin-alphabet countries know what those letters are.
Yeah, I removed the "glyphs" thing from my comment, because I realized they were SVG backgrounds, not actually text, but that is a common place to use user-select: none, on elements with font faces that are symbols.
I am curious what operating system you can select text from the buttons on though. I might spin up browserstack to experiment.
Yeah, I just tried to select text in the button element and translate it specifically or copy it, and it doesn't work. You can highlight it, but you aren't selecting the text.
This is what is copied from the login page, you can see that the button text is missing:
Sorry, you're correct. It was the link not the button. My brain gets confused talking to people using technical words correctly instead of normies that call the link a button
Give me an example of a real-world use case where this caused you an issue, and I'll show you where their UX design is poorly made, rather than a need for selectable text in a clickable element.
There is a certain page of one of the Bundesagentur für Arbeit websites that doesn't play well with automatic translation.
I speak B2 level German, but even then some of the technical terms are still complicated or unknown for me. This included one very long German word that was in a BIG RED button and the text in the big red button was not selectable, in the manner described in the article.
That's cheating. Terminal is in a sense the ultimate accessibility viewer, but few things work with existing terminal browsers I know of.
Makes me wonder though, if anyone tried to take a SOTA screen reader/accessibility software, and use it to re-render the page purely from the "how the screen reader sees it" perspective (obviously with selectable text)?
> If you really need to translate ONE WORD, it's not that onerous to type it.
I'm confident that I can type just a tiny fraction of all Latin characters all world languages use. I'm sure that pretty much any Vietnamese word is way beyond my keyboard layout. No clue about writing any non-Latin script. Can you type any Cyrillic, Kanji, Hebrew, Abjad, …, character you see?
There are also a bunch of characters in other languages that look identical or almost-identical to ASCII characters. It’s very difficult to tell the difference with the naked eye.
Yeah, because fuck people who require additional accessibility options, right?
On top of the real concerns around otherwise selectable text in a writing system not supported by the user's keyboard, there's also the issue of whether or not they can even operate enough of a keyboard to transcribe whatever text they want to translate.
> Yeah, because fuck people who require additional accessibility options, right?
Just do whatever you want and then listen to your actual users' feedback.
I worked on an application that I had to make button text not selectable because the old people using it kept selecting text on the buttons by mistake instead of clicking/activating the button and getting stuck during a clinical trial.
Should I have left it selectable to pass the HN accessibility shamers purity tests, or listened to the users?
> Just do whatever you want and then listen to your actual users' feedback.
That's good advice. But there's an important caveat: telemetry is not user feedback.
This is where "data driven" approach often fails in practice: telemetry isn't feedback, it's evidence you gather to help you guess the user feedback in lieu of actually getting it. When that's not understood and given proper care (which is approximately always, because everyone has too little time and too many stakeholders breathing down their necks), it's very easy to just find proof for your own preconceptions in the data stream.
Thank you! Feels great to hear from another dev whom clearly has some shared experience with me. I can't count the screen-reader and keyboard-navigation based tickets I've had to field, but when it comes to translations, I haven't had a problem one.
I empathize with translation, as I have to do it to pretty much every chipset firmware documentation I come across. So I just don't really understand where all of these issues are occurring with people not being able to translate stuff. Feels like a lot of people are maybe using a lot of websites that they aren't the target users for...
I don't even understand it; I just can recognize a character and type it in. The only time I have to do so is in looking at poorly designed firmware sites and stuff like that, but I manage when the developers do not accomodate for me.
But that's not what the topic is. The topic is HOW developers should accomodate users. And I'm simply taking the stance that preventing user selectability is a lesser evil in specific cases than universal selectability, because the former can be mitigated with less scripting overhead than the latter.
A native Chinese high school graduate is generally expected to know around 3500 characters. A middle school student, 2500-3000.
For Kanji the numbers are around 2136 and 1200 and respectively.
If you know the language, then you don't need this.
But if you're claiming that you can type a random Hanzi or Kanji character you see in an interface without speaking the language, you are either missing something here or not arguing in good faith.
It's solvable through the handwriting input, although you do need to know the approximate order and direction of strokes or you will get nowhere. I know roughly zero Chinese characters and use this often-ish.
Most importantly, you also need to find and enable the handwriting IME on your OS; which is... not a reasonable thing to ask of someone who doesn't actually type that language on a daily basis.
by screenshotting it and copying the text out of the screenshot
by putting a screenshot itself into chatgpt
I'm curious what real world scenario you've imagined yourself in with a kanji button that you don't understand within the rest of a website in kanji that you do understand, but don't know how to type kanji?
We seem to have very different concepts of either what is "easy" or fine motor skills.
I also find it rather difficult to point my phone at itself when trying to translate a word it's currently displaying; but maybe that's also a skill issue.
One involves clicking just before the button and dragging to just after the button (or vice versa).
The other involves opening a screenshot tool, selecting a rectangle, going to a website (that I might have to pay for?), pasting the image, waiting some seconds to cause global warming, getting some text back, clicking just after that text to just before that text.
How is that a similar level of effort?
The first I could walk someone who had never used a computer through over the phone in 1995. The second I wouldn't want to walk some of my coworkers through today.
I consider this a bad faith comment given the amount of detail you described taking a screenshot vs copying the text.
Anyway, it's not a noteworthy amount of effort, no. If your text selection of the button was blocked, which is the whole point of this discussion, the other methods would be a fine alternative. Or would you give up because it's too much effort?
I just tried both on the reply button for this very comment box.
> One involves clicking just before the button and dragging to just after the button (or vice versa)
This didn't work. Text is not selectable. Do you know why it doesn't work? Because user-select: none is the default user agent style on input[type=submit].
How about the screenshot?
- keyboard shortcut for screenshot
- click and drag
- click chatgpt tab
- keyboard shortcut for paste
How about the phone app?
- open translate app
- tap camera
- point at button
Again, neither of these were a noteworthy amount of effort.
I would argue that a word is typable is an edge case, especially dealing with another language. You can type words in basic latin script, sure, but you forget words with letters with diacritics, or even all words in non-latin script. In these cases OCR is also not necessarily reliable.
While I agree with you in general, keep in mind that there are plenty of languages where seeing the characters doesn't give you any info about how to type them. No copy-paste means you'd need to rely on OCR.
> If you really need to translate ONE WORD, it's not that onerous to type it.
I just spent several weeks traveling in a country where I have no ability to either type or name any of the characters in the alphabet. Yes, it'd be onerous.
Some of the websites I had to deal with also prevented text selection, or presented text as images.
It's not about keyboard use, but about people worried those pesky users all just want to steal or plagiarize the intellectual property that is the website.
Not everyone is fluent in every language, and not every website works perfectly with the browser's translator.
There will be situations where people will want to translate that ONE word that is actually in a button or tab, and isn't selectable because someone thought they knew better.