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.
