NcSelect option accessible names are mangled — getByRole('option',{name}) cannot match any label of 10+ characters (fleet-wide)

[rubenvdlinde]

Summary

getByRole('option', { name: … }) cannot match any NcSelect option whose label is 10 characters or longer, in any app in the fleet. The option's accessible name has a space injected into the middle of it.

Measured on openbuild (NC 34, @nextcloud/vue 9.9.0) while fixing tests/e2e/automations-rbac.spec.ts. The application is called "RBAC Automations App". Playwright's page snapshot:

- option "RBAC Autom ations App"      # <- space inside "Automations"
  - generic "RBAC Automations App"    # correct, but only via title=
    - generic: RBAC Autom
    - generic: ations App

Cause

NcEllipsisedOption implements middle-ellipsis by splitting the label into two <span>s:

needsTruncate() { return this.name && this.name.length >= 10 }
split()         { return this.name.length - Math.min(Math.floor(this.name.length / 2), 10) }
part1 = name.slice(0, split)
part2 = name.slice(split)

The wrapper <span class="name-parts" title="{full name}"> carries the correct name, so the inner node's accessible name is right. But the option role computes its name from contents, and the accessible-name algorithm inserts a space at each element boundary — so the option announces the mangled form.

Every label of 10+ characters is affected, at index len - min(floor(len/2), 10):

label	len	announced as
RBAC Automations App	20	RBAC Autom ations App
PW Version Lifecycle	20	PW Version Lifecycle (splits at a real space, so invisible)
production	10	produ ction
development	11	develo pment

Note the third row: short, ordinary values like production are affected too, which is easy to miss.

Why this is worth a fleet-level issue

Accessibility. A screen reader reads the mangled name. WCAG 2.2 AA 4.1.2 (Name, Role, Value); arguably 2.5.3 (Label in Name) too, since the accessible name no longer contains the visible label as a contiguous string.

It has already produced two wrong issues. In openbuild the locator timed out, the timeout was read as "the fixture is missing / the editor cannot see the application", and that inference became ConductionNL/openbuild#171 and the second comment on ConductionNL/openbuild#173 — the latter an architecture issue. Both are now retracted; the API was measured directly and works. A locator that finds nothing says nothing about the API underneath it, and this is a locator that finds nothing for a reason that has no connection to the app at all.

Six other agents are writing Playwright role queries against NcSelect right now.

The honest workaround

Target the component's own record of the full name:

function selectOption(page: Page, label: string) {
  return page.getByRole('option').filter({ has: page.locator(`[title="${label}"]`) })
}

Do not relax the regex to tolerate arbitrary whitespace: that hides a real a11y defect and will match the wrong option in a longer list.

Where the fix belongs

NcEllipsisedOption is upstream @nextcloud/vue, not @conduction/nextcloud-vue, so we cannot fix it by cutting one of our own releases. The upstream fix is small — give the split wrapper an explicit aria-label (or role="text"/aria-hidden on the parts) so the accessible name is computed from the whole name rather than from the two fragments. This issue tracks (a) the fleet-wide test-authoring guidance above and (b) raising it upstream.

Confirmed by: Playwright page snapshot on a live instance, plus reading node_modules/@nextcloud/vue/dist/chunks/NcEllipsisedOption-*.mjs.

[rubenvdlinde]

Two things from the nldesign/a11y side: the exact mechanism, and an ownership correction that
changes where the fix has to go.

Ownership — this is NOT in the nc-vue we can release

I was asked to fix this in nc-vue "which you can now merge and release". The release authority and
the defect are in different repositories:

• ConductionNL/nextcloud-vue is @conduction/nextcloud-vue and ships Cn* components.
  Its only Nc* tracked files are src/components/NcSelectTags/*.js. It declares
  @nextcloud/vue as a peerDependency (^9.0.0).
• NcEllipsisedOption belongs to @nextcloud/vue, whose package.json gives
  repository: https://github.com/nextcloud-libraries/nextcloud-vue — upstream, not ours.

Confirmed by git ls-files | grep -i EllipsisedOption in ConductionNL/nextcloud-vue returning
nothing; the component exists only under node_modules/@nextcloud/vue/dist/.

So a release of @conduction/nextcloud-vue would not change what any app renders — apps get
NcSelect, and the NcEllipsisedOption it uses internally, from @nextcloud/vue. It would move a
dist-tag and fix nothing, while looking exactly like a shipped fix. I did not make that release.

The mechanism, read from the shipped component (8.39.0)

needsTruncate() { return this.name && this.name.length >= 10 }
split()         { return this.name.length - Math.min(Math.floor(this.name.length / 2), 10) }
part1()         { return this.name.slice(0, this.split) }   // one <span>
part2()         { return this.name.slice(this.split) }      // another <span>

The arithmetic reproduces both reported strings exactly:

label	length	split	part1	part2
production	10	5	produ	ction
RBAC Automations App	20	10	RBAC Autom	ations App

So this is deterministic and not environmental, and it affects every label of ≥10 characters.
The truncation is done by splitting the DOM, not by CSS text-overflow, which is why the
accessible name is mangled rather than merely visually clipped.

Suggested fix (upstream)

The split is purely presentational, so it should not reach the accessibility tree: mark both parts
aria-hidden="true" and expose the full name once on the wrapper (aria-label, or a
visually-hidden span). That repairs the screen-reader announcement and restores getByRole(..., { name }) locators, with no change to the visual behaviour.

Please keep the workaround as a workaround

The [title] matching used in openbuild is the right interim call precisely because it does not
loosen name matching — a relaxed regex would have made this defect invisible fleet-wide while the
screen-reader experience stayed broken. Worth not adopting that as the fleet's answer.

Also worth flagging for anyone reading the linked openbuild issues: a role/name locator cannot match
a mangled name, so it times out, and the timeout reads as a missing feature. openbuild#171 and #173
both rest on that inference, and a direct HTTP probe reportedly contradicts it — those should be
re-checked against the API before any product conclusion is drawn.

[rubenvdlinde]

Correction to my earlier comment — I quoted the wrong version

My previous comment quoted @nextcloud/vue 8.39.0. That was the wrong layer, and in one respect
it would have misled you: in 8.39.0 NcSelect does not reference NcEllipsisedOption at all
(grep -c → 0). Had anyone tried to reproduce this against a v8 tree they would have found the
component unreachable from NcSelect and might reasonably have concluded the report was wrong.

Re-checked against 9.8.0, which is the line Nextcloud 34 apps actually run (this repo declares
@nextcloud/vue as a peerDependency ^9.0.0):

• dist/chunks/NcSelect-*.mjs → 5 references to NcEllipsisedOption.
• The computed block in 9.8.0 is identical to 8.39.0, so the arithmetic in my earlier comment
  stands: "production" → produ/ction, "RBAC Automations App" → RBAC Autom/ations App.
• The component contains zero aria-hidden, aria-label, or visually-hidden markup — grep
  count 0. There is no accessible-name mitigation in it at all.

How it is reached — it is the DEFAULT SLOT CONTENT, not a prop

option: withCtx((option) => [
  renderSlot(_ctx.$slots, "option", ..., () => [
    createVNode(NcEllipsisedOption, { name: String(option[localLabel]), search })
  ])
]),
"selected-option": withCtx((selectedOption) => [
  renderSlot(_ctx.$slots, "selected-option", ..., () => [
    createVNode(NcEllipsisedOption, { name: ..., search })
  ])
]),

Two consequences worth having explicit:

1. There is no prop to turn it off. Every NcSelect on v9 mangles every option label of ≥10
   characters, in both the dropdown and the selected value.
2. It IS overridable per call site, because it is only the slot fallback. A consumer can pass
   #option / #selected-option and render the label plainly. That is the only mitigation
   available below the upstream fix — at the cost of losing the search-term highlighting
   (NcHighlight) that the default provides.

Suggested upstream patch (unchanged)

The split is presentational, so keep it out of the a11y tree: aria-hidden="true" on both spans and
the full name exposed once on the wrapper. Repairs the announcement and restores
getByRole(..., { name }), with no visual change.

Why I have not shipped a fix, and what I am asking for

I was asked to fix this in nc-vue "which you can now merge and release". The release authority and
the defect are in different repositories, and I want to be precise rather than ship something
inert:

• ConductionNL/nextcloud-vue = @conduction/nextcloud-vue, ships Cn* components.
  I searched all 729 remote refs with git ls-tree -r for EllipsisedOption: zero hits.
  Positive control on the same loop: CnActionButtons appears in 22 of the first 40 refs, so the
  search works.
• NcEllipsisedOption belongs to @nextcloud/vue →
  repository: https://github.com/nextcloud-libraries/nextcloud-vue.

A release of @conduction/nextcloud-vue therefore cannot change what any app renders for this
defect. It would move a dist-tag and fix nothing while looking exactly like a shipped fix, so I did
not make one. Verified nothing was published: npm view @conduction/nextcloud-vue dist-tags still
reads latest 1.0.0-beta.3 · beta 1.0.0-beta.229 · vue3 2.2.0-vue3.13, last publish 2026-08-10.

The one thing I could ship here I do not think we should do blind: 101 components in
@conduction/nextcloud-vue use NcSelect, so slot overrides across all of them would work — but
that is 101 call sites in a library shipping to the whole fleet, it silently drops search
highlighting everywhere, and it is a heavier workaround than the [title] one it would replace.
That needs a deliberate decision, not a drive-by from the nldesign task.

Recommendation: file upstream at nextcloud-libraries/nextcloud-vue with the patch shape above,
keep openbuild's [title] locator as the interim, and do not relax name matching fleet-wide — a
loosened regex would make this invisible while the screen-reader experience stayed broken.

[rubenvdlinde]

Filed upstream: nextcloud-libraries/nextcloud-vue#8840.

Two corrections to this issue's premise, both measured:

1. NcEllipsisedOption is not ours to fix. ConductionNL/nextcloud-vue is @conduction/nextcloud-vue and ships Cn* components; it declares @nextcloud/vue as a peer dependency. A search of all 729 remote refs for EllipsisedOption returned zero hits, with a positive control (CnActionButtons, found in 22 of 40 refs). Publishing @conduction/nextcloud-vue for this would move a dist-tag and change nothing any app renders.

2. It is reached by default, not opt-in. NcSelect renders NcEllipsisedOption as the fallback content of both the option and selected-option slots, confirmed in the shipped 9.9.0 bundle (and 9.8.0, and 8.39.0 — so both the Vue 2 and Vue 3 lines).

Mechanism, from the shipped component:

needsTruncate() { return this.name && this.name.length >= 10 }
split()         { return this.name.length - Math.min(Math.floor(this.name.length / 2), 10) }

The wrapper is display: flex, so the two parts are flex items and accessible-name computation joins them with a space: production → produ ction, RBAC Automations App → RBAC Autom ations App. Deterministic, not environmental.

The wrapper does carry title="{{ name }}", but title is only a fallback name source — the descendant text wins, so it does not repair the announcement. It does make [title="…"] a reliable locator.

Interim guidance for the fleet is unchanged: match with [title]. Do not loosen role/name matching — that hides a real WCAG 4.1.2 defect rather than working around it.