As a web dev, I fully agree with this, but with a huge exception: clickable text.
Anything that is meant to be read as content should absolutely, without fail, be selectable and copyable (assuming appropriate permissions).
But stuff like tab headers, buttons, or even text-sparse tiles - things meant for the user to click on - can, and usually should, prevent text selection. It is super annoying to be clicking back and forth through tabs only to have some text erroneously highlight and then stay that way.
Exceptions to every rule, and to every exception of that rule, of course. But for the most part, allowing text highlighting in those clickable areas is a rough UX.
* note that I did not include anchor links; those are meant to be inline within text content and should therefore be selectable.
Real-world example I use nearly daily: Selecting the nav header that's the ticket number in our ticketing system. I copy-paste the number elsewhere.
Of course there are many other bad design decisions that go into requiring me to do this, but it's still a real example of why all text should be selectable.
Something I absolutely loved while working at Meta was that basically every internal system has some kind of ticket ID, and more importantly, wherever it's displayed near the top of the page you very likely can click-to-copy it. And the click-to-copy gives you a rich version of the ticket ID that you could paste into Google Docs and have the link to the ticket page embedded already. Really small feature that improved the life of engineers a lot considering how much you're copy/pasting IDs around. It's the type of UX care that I expect ServiceNow type third party systems will never have.
Recently I've been considering simple click-to-copy button is a bad ux since it can destroy one's clipboard (granted, I'm not using clipboard manager). This might be mitigated with a confirmation before actually replacing the clipboard, but I haven't encountered such implementation. Maybe due to ctc more often appear in tech-related websites.
Instead of click-to-copy, you could do click-to-highlight, so that "right-click > Copy" highlights the text on right-click if it's not initially selected. There is some subtlety in the logic, because it shouldn't interfere when the user manually selects a substring.
I'm aware of that gesture, but I think it shows the point that it requires extra intention from the user to do select+copy on an input-looking field with copy button attached, instead of being part if the default ctc button experience.
Not that I am searching, but I wonder if there's already tog/nielson/other ux research on this specific interaction.
I highly recommend getting a clipboard manager! They keep a (usually configurable) history of your most recent clipboard items and allow switching the active selection between them.
Surely. First time I used clipboard management was long time ago somewhen in windows xp era. But growing older make me not really incentivized on trying myself to relearn clipboard history gestures. I might do that someday though.
The difference is now I know git and text editor with hot-save support; with mostly textual clipboard, the texts usually just land in either git/editor.
I don't want a good-faith workaround for a website hijacking my clipboard. I want the website and its developers to stop doing things that are stupid and wrong.
Hover shows icon for copy rich link
Clicking shows menu with copy plain text, copy rich link, search for backlinks, etc
Element itself is a link that can be ⌘-clicked, right clicked etc
Then all those nav headers need to have a little button on the side to open a floating div with copy-pasteable content. Or, if needed - different versions of copy-pasteable content (as a command line for copy-pasting into the terminal, json, etc.)
This is a standard UI convention used by all internal dev tools at my current company.
Gitlab has killed this with their slide in issues. If you have an issue open, and you copy the address, it's just a huge unique ID context thing. So you have to scroll to the top and use the little copy link button at the top of the page.
No, text should be selectable, even when links. The amount of times I've accidentally highlighted instead of clicking? Maybe a couple? The amount of times that frustrated or confused me? Absolutely zero.
I want to select the text of a link and copy the text of a link. I want to do this but I run into issues _daily_, esp. on mobile. PagerDuty app, I'm looking at you! Mobile seems to assume that you, in no world ever, could ever want to select text.
Being unable to select text out of a link is absolutely infuriating when you want to just copy a piece of it, either because it's a reference number or something, or you want to translate it. Mobile is nearly impossible, and desktop is also fiddly in many cases.
Often when translating it's easier to just OCR the area with the dictionary app, which is madness when it started as text.
The user base of the application I develop is non-technical. Most of them double click or drag EVERYTHING. It ends up highlighting stuff that looks weird and now they are dragging and dropping things with a quarter of the screen highlighted in a different color and it just looks messy and obscures data behind the text on pages with visual diagrams.
A designer pointed this out and requested we disable highlighting on button text and draggable handles, and honestly it's a good idea and those problems are now fixed. The downside is that someone can no longer highlight the text on the draggable button that says "Instruction Node" and that's a totally fine tradeoff.
This seems fine to me. For example in inkscape if I drag on the File menu at the top (or double click), I can't start highlighting the "Fi" in the "File" menu label and I'm totally fine with that, same thing here.
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.
I sometimes shop on Japanese webstores for CDs and merch. Many of these sites are actually where natives buy stuff, so few to no translations are available there. It's a routine for me to copy the Japanese on the nav bar to a translator, then get a list like "Cart <tab> Orders <tab> Account <tab> Help".
Another example for buttons. Assuming I don't speak Chinese, how could I know what "下单" and "返回" mean without copy-pasting them into a translator?
Copy-paste obviously makes things easier, but it should be noted that many translate tools let you draw characters these days, and many OCR services can read Chinese characters. But I agree that those are annoying extra steps.
It's definitely not the easiest thing, but I imagine that someone working with Chinese characters often would have learned enough about radicals and stroke order to do it in a pinch. The hardest part is memorizing the characters; the OCR in, say, Google Translate, is quite good at picking out what you meant.
...OCR, as I said. But handwriting skills and radical knowledge are nice to have in case those services go down or you're dealing with bad handwriting.
It doesn't. It should, in an ideal world, but it definitely isn't the goal of people who design human-computer interfaces to allow everyone who interacts with a computer to be happy with the way it functions.
It's always bothered me that links on webpages are single click to open. They should require double clicking to open (like just about everything else on a computer) and single click should be used to start selecting text, like everywhere else on a computer.
When you run an app from the taskbar or start menu, you single-click on the app icon, or single-click on the Start menu button and then single-click on the app.
Sure, icons on the desktop, or just about anything in a file/app explorer window, require a double-click by default, because the lineage of the main desktop area is just a file explorer window without the window decorations.
I think it might be about stakeholders wanting the web to "feel" more native and interactive. Double-clicking to "go" feels too much like you're interacting with the web as if it's a file browser. They want it to feel more immediate?
In principle I'd prefer the consistency of double-click or double-tap everywhere, but I'm used to adjusting based on context. Wouldn't double-tapping annoy everyone who primarily uses mobile devices?
You make some good points here. Even in file managers, one can usually highlight with a single click then use either a context menu or a menu at the top of the application to single-click on things like run, move, copy, or rename. I think the idea of making hyperlinks in hypertext more like a menu than like filesystem resources does make some sense, especially since the browser is an application and single-click within user applications has been pretty normal for a long time. Still, I agree it might have been better if this had gone the other way.
A double-click would better represent intent/consent, too, which the web has had long had issues with. Accidentally clicking things is too easy and frequent.
Why would you take the most common interaction on the web and change it to require double the actions with very specific timing?
If consistency between systems is more important than usability, it probably makes more sense to use single click to open in the OS (which has been an option in Windows for 30 years).
You know, I've often wondered how much simpler UX would be if this had been the case from the start. Hard to make any predictions, but one can optimistically dream...
I'm guessing it would be much more disruptive for touch devices. It would definitely reduce the number of erroneous clicks when just trying to touch to scroll the screen.
Selecting a link's text is secondary to opening it, so it makes sense that it takes a less direct action to do it. At least on Windows, just hold the "ALT" key to select without a click registering; not so bad, although intuition tells me most people don't know about it.
Double-clicking is much more difficult to do correctly, and distinguishing repeated single clicks from double clicks is another minefield (manifesting itself in e.g. the mouse gesture needed to rename a file on Windows - you must single click it once to select, and then single click the name again to edit it, but if you do it too fast, it's treated as a double click).
The real problem IMO is that we have effectively standardized on two-button mice as the baseline, with all UX then designed around that even though many mice have 5+ buttons these days. The three basic actions that desktop UI has ultimately converged on are: select; activate; show additional actions (context menu). These should logically map to three independent buttons, such that the two most common actions are mapped to buttons that have fingers resting on them in neutral position - e.g. left = activate, right = select, middle = context menu.
Doesn't the click cause the browser to "go" on mouseUp? Selecting is clicking then dragging - this seems like a clear enough difference to me that I've never had problems. In fact, sometimes I will click, and think, "oh I actually don't want to go there" and will drag off the link and release the mouse button and it doesn't take me there.
Most buttons do not require double-click. In fact, it's only Explorer and related things which have single click select, double click action, isn't it?
At one point round about Win98 Windows took inspiration in the other direction, with Active Desktop: you could change a setting and have single-click to action in Explorer.
I am sure that this would have been user tested many decades ago when mice had balls and three buttons. They might have even tested opening links on mouse over, which would be a bit too trigger happy.
Users of just the web are not fully computer literate. The interface is super easy compared to actual programs where you need things like menus, right clicks and full hotkey support.
If I think back to how my mother struggled with computers and how her friends were just as useless, I think they would be stumped with having to double click. Arthritis comes along too, so that generation needed all the help they could get. Generally it was only the advent of online shopping that enabled them to persevere with giving things a go.
Double-clicking originated with the Macintosh because Jobs wanted a single-button mouse above all else. We're used to it now, but they had training exercises to teach people to double-click because it's undiscoverable and takes practice.
A case can be made for graphic like elements like buttons, but for text: treat it like text even if it's clickable.
In the Web version of Outlook, there are regularly times where the location of an appointment is a street address. That text is typically clickable. But the click action doesn't correspond to the choice of mapping service I might want to use in any one instance or to the fact that I might have other actions, like copying the address into another email/sms/etc. Outlook followed your philosophy. You can't select and copy that text, save for going through several auxiliary clicks just to get to a spot where you can. It's the most annoying behavior I can imagine.
That you think that you sitting in a meeting room talking it over with colleagues, or perhaps I'm a meeting in your own mind can assign legitimate uses and not, when something other than say security might be at stake, is just wrongheaded.
And by the way, that address being the link that it is is great 60%, 70% of the time. But when it's not it's clearly a design mistake.
The point isn't that the developer should disable text selection whenever he thinks it's unnecessary, which would indeed be silly. It's that sometimes the user interface rules for navigating selectable text conflict or interfere with the user interface rules for navigating, say, a set of tab panes. In that situation, making the tab titles selectable will cause grief.
I agree with your address example. That is user data, and it should be selectable.
I don't think we disagree, too much. tab panes matches the "button" example.
However, I am sympathetic to those arguing translation. Sometimes I'll visit Japanese or Chinese websites. With some frequency, even if most of the site has an English edition, I'll find some UI element not translated, including buttons and the like... OK I think it was the commenter that I responded to, in a different reply said... just Google it if it's a single word. Great! But I don't even know where to begin to get the right characters from my old fashioned US keyboard. So now I have to Google for how to use my keyboard to get the characters I want, which also may need pre-requisite knowledge of the language I'm trying to translate (radicals and all that jazz)... that's a heavier lift than may be anticipated and where a simple copy/paste into an appropriate translator would make things much, much easier.
I would suggest this: make everything buttons, links, tabs, etc. selectable and copyable unless there is a real explicit and compelling reason to do otherwise. Now to be fair, I'm old enough to have been "online" in some fashion or another since before general public internet access availability was a thing... so my expectations for butter-like user experiences are low and my desire to do any damn thing I want high... but even today, there are probably still more websites which don't stop you from copying anything than there are searching for that polished experience where only the right things can be selected. The discontinuity and the deviation from the expectation that I can copy anything I also find as something which diminishes the user experience, even if occasionally I'm annoyed by over selecting things.
I disagree. In a lot of cases text will be clickable, but will also contain content that you want to copy/paste into Wikipedia or a search engine etc. Think annotations (click on this text for more information) or headers/titles that are a proper noun that references something public... like a person's name or a place or a type of object or something.
I don't think that's an "exception." I think that's common enough to make me ask: "please don't make that text not selectable ever."
It is super annoying to be clicking back and forth through tabs only to have some text erroneously highlight and then stay that way.
It's more annoying when your web site won't let me copy a package tracking number to paste into my chosen package tracking program. Maybe I don't want to use your system. Maybe the program I have is better.
Just because a web dev can't think of any reasons someone would want to copy text doesn't mean the reasons don't exist. It just means the developer lacks imagination.
That is not what they meant and you know it. They were talking about buttons labelled "OK", "Back", or "Confirm". Buttons that wouldn’t be selectable in a native app either, but somehow we don’t complaints about that here.
I do not want to have to go into the dev console to copy the text of some random thing you think shouldn't be clickable. It's happened way too many times.
I agree. The closer to a traditional desktop U.I. you get, the jankier selecting clickable text becomes. For a simple web form, leaving labels selectable is no big deal and probably a win. But for something trying to behave like a tabbed dialog box, it breaks navigation left and right.
> But stuff like tab headers, buttons, or even text-sparse tiles - things meant for the user to click on - can, and usually should, prevent text selection. It is super annoying to be clicking back and forth through tabs only to have some text erroneously highlight and then stay that way.
No.
Outlook mail for example is full of your principle, which means copying a mail address becomes a «hover over the not-selectable mail address to pop up a contact card, scroll down the contact card to where the mail address shows up again, but is again unselectable, click the "copy to clipboard" icon»
Instead of disallowing selection on the text with CSS, call `event.preventDefault()` in the click handler. This keeps a click that you handle from triggering the built-in text selection path, but you can still click-and-drag to select text.
There are often button which do important things, I want to double check the meaning of before clicking them. Selecting the text to copy/paste into a translator is absolutely beneficial.
And in Japan, the general layout of the "Go back to previous screen" and "confirm and continue" (left and right, respectively), is reversed from what English readers might be used to.
So if I can't select the text... I open up a hand-drawing-chinese-characters app and slowly draw out each character? I'd rather be able to select the text.
Note: unfortunately, so many button in Japanese UIs are actually .png files. I know this from experience of using and building apps and websites here.
As a long-time web user, some push back. I just want text. Give me clickable links if needed. HTMLv2 was enough for most information, most of the rest is eye candy.
As long as you still offer an easy way to highlight the button text.
Triple-click (at least in FF on Linux) highlights paragraphs or other block-elements contents; it should be allowed on things where a single-click does navigation. This would be very out of the way for normal users, but would allow easily and quickly highlighting (and copying) parts of the interface.
Counterpoint to that is the bizarre "everything must be a link!" state of things on modern websites. Heck, even on hn - click on a user's name in these replies, it goes to their profile page. great! then on that profile page, the user's name is... a link back to the same page.
Strong disagree. I often want to grab the contents of a page, tab headers and all, and paste that into a text editor for subsequent manipulation. Please don't design your pages in a way that makes unilateral decisions on behalf of the user.
All text should be selectable (and therefore readable) to support accessibility tools - at least if you’re app or site is Section 508 compliant or similar.
When text becomes selected, instead of allowing the control to work as expected, the focus cannot move between the elements as expected. It breaks the UX for keyboard-only users. I can appreciate that this is not something everyone has to contend with, but for accessibility's sake, the default behavior should at the very least be mitigated. So you're advocating for either hurting the keyboard experience or injecting javascript to over-manage the experience.
To each their own, but I'd rather neither of those things at the expense of not being able to select "Home", "My Account", "Settings", etc. Shit that nobody actually needs to select anyway.
Use a mouse to click inside of a word link (like "threads") in the HN header. Try to drag to highlight. Note that the link tries to drag instead of highlighting. This is default behavior for anchors because of the issues that it would otherwise cause with the whole selection API.
Alternatively, set your cursor at the end of the header in the empty space, and drag your mouse backward to highlight the items. At that point, you can highlight the text, because you started in a non-user-select-limited area.
Note that this is default browser behavior. Inspect the styles and see that they have applied no selection styling to those anchors. This is the thing I'm advocating for. Make the web work like the web works, and disregard people telling you that "everything must be selectable" not because it shouldn't be, but because there are features that expect certain functionality to work well with the other features of the web.
I don't think you understand the technical applications that the website is advocating for. I can appreciate that the technicalities are frustrating, but the web works the way it works, for better or worse.
You broke the site guidelines quite badly in this thread, including (such as here) with personal attacks. Could you please review them and stick to them in the future? We'd appreciate it.
In your original post you say "But stuff like tab headers, buttons, or even text-sparse tiles - things meant for the user to click on - can, and usually should, prevent text selection" and you explicitly mention that you leave out anchors.
So far no reply to me has talked about problems causing by having selectable "tab headers, buttons, or even text-sparse tiles".
I am still 100% open to hearing about it. But I can do away with the personal attacks and sarcasm.
> Use a mouse to click inside of a word link (like "threads") in the HN header. Try to drag to highlight. Note that the link tries to drag instead of highlighting. This is default behavior for anchors because of the issues that it would otherwise cause with the whole selection API.
You can drag slightly above/below to select it, or use shift + arrow keys. I personally use a plugin[0] to allow dragging within the text too, and haven't noticed any issues.
> Note that this is default browser behavior [...] This is the thing I'm advocating for.
If you're just advocating for the default browser behaviour, which does somewhat allow selection of link text, then that may be worth clarifying above - since I think people are interpreting your comments as advocating for those buttons that prevent text selection entirely (and I'm not really sure how else to interpret "the default behavior should at the very least be mitigated").
I made myself clear to the other development professionals I was talking to as evidenced by their feedback.
The people who seem to have the most trouble understanding what I'm advocating for are the people who seem to only be taking a user-centric approach to the situation, rather than grappling with the practicalities of the web environment.
At this point, I'm over trying to make anyone understand anything. They'll either get it, when it is relevant for them to get it, or they won't and it won't matter to me or anyone else at all.
In a year, we might have better web functionality or a new built-in browser or OS feature, or any number of other things that could mitigate this specific gripe, so I'm not super concerned about any of it. Those that understand what I'm saying will have better UX for heeding the advice with appropriate exception. And those that don't won't make UX worth using. No worries either way!
I asked "Do you have an example of a website where selectable text makes keyboard navigation not possible" and you provided an website with non-selectable text.
Good UX means including translations for supported languages, not telling the user "do it yourself by highlighting content".
Not translating entire articles to a language you don't support has the easy remedy of letting people select the text and use third party tools to support their specific use-cases. But not including translations for your clickable content for languages that aren't supported are the literal practical limits of ability. I would rather my apps work for people in languages I do support, with full accessibility (and minimal scripting overhead), than to have them work poorly for keyboard-only users in all languages, regardless of my app's support for them.
Again, we're talking about the stuff that should be iconic. Things that can literally be represented by icons. Buttons and tab headings. Things that you shouldn't actually need translated AT ALL, much less into every single language there is.
Even when the language is supported I have had GDPR popups block that language selection. The text in the popup was also not selectable which made it very hard to read what I was or was not agreeing to.
I know you're not asking me, but I would really love the "copy" feature added to ALL context menus.
Right clicking a standard anchor element gives you the "copy link" option, but you don't get to copy the word without having it selected. Would be nice to just have a "copy word" feature, for starters. Could even be expanded so that it auto-selects the text after copying it so that if you wanted to copy more than just one word, you could expand the highlight (with the little widgets on mobile, or with keyboard/mouse selection in that one state on desktop) and then get a "copy text" option that copies all of the selected content.
A menu with "我的帳戶" in it, and often a generic icon or no icon at all, doesn't really have sufficient context to determine what the button means. If the website is already translated into your language then great, but many websites aren't (because it's a small site, or you don't speak one of the most common languages, or it's aimed at a different audience, etc.)
Bad UX is the result, from the combination of disabling text selection and being in a language you don't understand. Ideally both would be fixed - since unselectable text causes UX issues even when in a language I understand (when I want to select as I'm reading to keep place, or copy a partial link, or right click -> search/define a technical term, or copy-paste to tell someone what button to click, etc.)
Did you provide translations for all of those? If we expand to the immediate vicinity you can also throw in Thai and Vietnamese as well. Plenty of Japanese and Korean people live in Singapore too.
If you want to experience the frustration of text not being text, take a look at one of the main train ticket booking websites in China https://www.12306.cn/index/
Plain old text that can be selected is always going to be the most user friendly to non-native speaker users.
The question then is on the balance of trade offs which user group experience is the one you want to cater more to, non native speakers or keyboard-only users.
Edit: I love how one of the icons is 票 - perfectly self explanatory to Chinese speakers. Good luck if you don't speak Chinese which goes to show that icons are cultural to some degree
I think we can admit that Chinese always does it in its special way, so it's not really a great example. Not many Chinese people would use their web client to book tickets, the mobile app is much more user-friendly - as long as you have ample knowledge to navigate through the system.
It's not? Just checked a Chrome instance I had handy, it has all three options in the context menu - "Copy", "Copy link address" and "Copy link to highlight". First one copies text in between <a> ... </a>, second one copies the href attribute, and third one copies the link to page you're on with that weird URL framgment-based arbitrary text anchor/highlight scheme.
Anything that is meant to be read as content should absolutely, without fail, be selectable and copyable (assuming appropriate permissions).
But stuff like tab headers, buttons, or even text-sparse tiles - things meant for the user to click on - can, and usually should, prevent text selection. It is super annoying to be clicking back and forth through tabs only to have some text erroneously highlight and then stay that way.
Exceptions to every rule, and to every exception of that rule, of course. But for the most part, allowing text highlighting in those clickable areas is a rough UX.
* note that I did not include anchor links; those are meant to be inline within text content and should therefore be selectable.