40 ms·
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 ke
by catapart 1y ago
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.
- huimang 1y agoThis breaks translation. Text must be selectable.
- catapart 1y agoGood 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.
- odo1242 1y agoWhat would be your ideal solution to the described problem? (Clicking on UI elements selecting text instead of processing the click)
- catapart 1y agoI 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.
- 1718627440 1y agoIt does give you the search this text option.
- djtango 1y agoI personally like to click text absent mindedly when I'm reading a bit like holding your finger while reading Also if you're a non native speaker you want to be able to select the text so you can translate it
- catapart 1y agoWhy would you want to translate "My Account" into another language? And, more pertinently, why should I support it, at the expense of keyboard-only users?
- Ghoelian 1y ago> Why would you want to translate "My Account" into another language? When you don't know the language or what "My Account" means? Not everyone speaks English.
- catapart 1y agoAnd you also can't understand the icon? And the context? And the translations I provided?
- Ukv 1y agoA 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.)
- catapart 1y agoAh, so the website had bad UX? I think we've found the issue!
- 1y ago
- whstl 1y agoWhat's that behavior? Do you have an example of a website where selectable text makes keyboard navigation not possible? Could this be a browser problem? I can tab between links here in HN and it's perfectly also selectable.
- catapart 1y agoUse 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.
- whstl 1y agoThen I don't think the article is advocating for what you think it is. You are saying "tab headers, buttons, or even text-sparse tiles [...] should, prevent text selection". The website is advocating for not disabling selection, not for enabling in random places.
- catapart 1y agoI 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.
- whstl 1y agoNope. I am saying the web should work the way it is, like Hacker News does, as I already have brought up elsewhere. You are saying "tab headers, buttons, or even text-sparse tiles [...] should, prevent text selection". The article is saying the same thing I am. Basically don't do `user-select: none;`. The example is itself in the article's CSS.