fix(ui): make package name selectable

[Adebesin-Cell]

Fixes #568

The package name in the header was difficult to select, especially for scoped packages, because it was split across interactive elements.

This PR refactors the header so the package name is rendered as plain text and is easy to select across all browsers. Clicking the package name still copies it to the clipboard, but the copy action is now suppressed when the user is actively selecting text, allowing normal text selection without accidental copies.

BEFORE:

Screen.Recording.2026-02-01.at.01.44.21.mov

AFTER:

Screen.Recording.2026-02-01.at.08.35.47.mov

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ready	Preview, Comment	Feb 2, 2026 7:07am
npmx.dev	Ready	Preview, Comment	Feb 2, 2026 7:07am

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
npmx-lunaria	Ignored		Feb 2, 2026 7:07am

[danielroe]

this is a good change, but I'm not wild about adding ui elements to this part of the page.

copying the package name is nice but 'discoverable' because you'd click on it anyway to copy it. can you think of another solution that isn't an extra icon/button?

[Adebesin-Cell]

this is a good change, but I'm not wild about adding ui elements to this part of the page.

copying the package name is nice but 'discoverable' because you'd click on it anyway to copy it. can you think of another solution that isn't an extra icon/button?

Good point!

I’ve updated the implementation to remove the extra icon/button entirely. The package name itself is now the click target for copying, but it’s rendered as plain text, so it can be selected normally. Let me know what you think!

[knowler]

I like that it’s more easily selectable considering before it wasn’t immediately clear that there was a button there (presentational-to-semantic mismatch). With that said, it’s still acting like a button without any of the semantics. Users navigating by keyboard now have no way to copy the name (and tabindex=0 is not a good solution here, because then we need a role which opens up another can of worms which will get you back at a <button>). A screen reader user could copy the name, but it won’t be clear to them that they can. I think more conventional accessibility wisdom would say:

• Don’t wrap any part of the package name with a <button> element (since it’s not visually presented as a button—an affordance of text is selectability).
• If a copy shortcut is being provided, include it as a button separate from the heading text to avoid making this unselectable.

We don’t have to follow that conventional wisdom, but then that’s going to take a bit more intentioned research and design.

[danielroe]

what about adding a button that's has aria-text, is in the tab order and is only visible when tabbed to, a la skip to content?

here's my thinking:

copying a package name is a minor enough benefit we don't care if users know about it - they can discover it if/when they go to try to select the text... and adding an additional button-with-icon is not worth the visual distraction in this area.

[knowler]

what about adding a button that's in the tab order but only visible when tabbed to, a la skip to content?

I think the least bad option given the current design and avoiding clutter would be to do something like this and you could even reveal said (perhaps visually labelled) button for sighted/mouse users when they hover the area. That could ensure folks could use the package scope link, select the package name, and have a distinct button to copy the package name.

Where that falls short for accessibility purposes is that you aren’t really supposed to make stuff only show up on hover for various reasons (it also affects touch users who often can’t hover). It fails the “perceivable” principle of WCAG, but like I said, I think it could be the least bad option at least for now (doing weird things with UI overlap/omitting semantics is worse IMO).

And I guess, even without a persistently visible labelled button, sighted mouse/touch users still do have the affordance of the text itself which they know they can select and copy, so it’s not like their access is being impeded.

[Adebesin-Cell]

Quick sanity check before I tweak this again, would a real copy button that’s keyboard-accessible but only visible on focus (skip-link style, maybe also on hover) be an acceptable direction?

Or would you prefer dropping the copy interaction altogether and just relying on normal text selection?

cc: @danielroe

[danielroe]

let's go for the button, for now

happy to remove the functionality later if there are a11y concerns but my reading of @knowler s comments indicates we are just about OK here

[Adebesin-Cell]

#568

Screen.Recording.2026-02-01.at.12.24.28.mov

Looks like this now!
Thinking about mobile devices, the copy button currently relies on hover/focus to appear. Do you think we should adjust the behavior for touch users, or leave it as-is for now?

[knowler]

I think that the button shouldn’t take up space when it’s visible or hidden as it’s negatively affecting the layout. It should probably be floating in some way.

I had (roughly) imagined something like this: demo (demo with “open in codepen” button)

• The technique I used does use anchor positioning (and the position-area keyword, which Firefox doesn’t support yet), but it’d be possible to achieve without it using regular absolute positioning.
• If the button floated above or below the package name, then you’d have space to include a visible label which helps with cognitive accessibility.

I’m curious to hear what others think. cc: @danielroe

Also, for situations without hover capabilities, I would just completely hide the button for now using a media query for the hover media feature. Eventually something could be added, but personally, I’d defer that and work more iteratively.

[danielroe]

exactly 👍

[knowler]

Works good! I did a quick screen reader test with NVDA + Firefox on Windows 11 and VoiceOver on macOS + Safari 26.2, and it’s working as expected (the rotor/element listing is correct the headings + the focus order + visibility is good). I have not done a code review so I’ll defer to others for that.

Thanks for rolling with the design changes for this one.

[WilcoSp]

I've just checked on mobile but on their the "copy package name" button isn't available.
Maybe an idea would be to allow (long) pressing the package name to show the copy button, for this long pressing with can use onLongPress from vueuse.

Also do we still want to use the AnnounceTooltip component when copied or align behaviour with other copy buttons like at copy install package command & copy link at code, to where the button text gets changed to "copied!" when copied?

I work till 17:00/5pm (Amsterdam time) and when I'm back home I could implement the suggestion & question above.

Further this a nice improvement

[knowler]

Replying to @WilcoSp in #594 (comment):

I've just checked on mobile but on their the "copy package name" button isn't available.

This was an intentional decision since the feature itself is really a convenience for something users can already do (i.e. select the text and copy it—which this PR sought to restore).

Maybe an idea would be to allow (long) pressing the package name to show the copy button, for this long pressing with can use onLongPress from vueuse.

For mobile, I was thinking that we would need to make a persistently visible “copy package name” button (perhaps just as an icon button). The problem with using a long press is that there’s no affordance for it (i.e. how will users know that it’s an option? it’s not a common pattern). That’s why I think we need a visible button if we want to do this on mobile, in which case, they can just press the button.

Also do we still want to use the AnnounceTooltip component when copied or align behaviour with other copy buttons like at copy install package command & copy link at code, to where the button text gets changed to "copied!" when copied?

I agree something could probably be done here and your proposed solution is worth exploring. I do have a feeling that we might want to preserve the accessible name of the button as “copy package name” but then have the “copied” text visibly show in the button and be announced in a live region. I’d need to do a bit of research on this sort of thing.

[WilcoSp]

@knowler I've also experimented, what also might be an option is to use a normal click event but check getSelection whether the current selection is within the package name, if it's not then we show the button.
This would make it that on computer it shows on hover while on mobile it shows on pressing.

this could be a (temporary) solution.

also with what Danial Roe said is in most cases a user would've pressed to select the name so that pressing either copies the name or a button shows is makes only the experience nicer.