A whitespace-only tile title survives into accessible names

[BorisTyshkevich]

Spotted during the #471 review; deliberately not fixed there (it changes title semantics for every consumer, not just the new action).

What

src/dashboard/application/dashboard-viewer-session.ts:550:

const title = (typeof tile.title === 'string' && tile.title) || (query ? queryName(query) : tile.queryId) || tile.id;

A non-empty but whitespace-only tile.title (e.g. " "") is truthy, so it wins the ||chain unfiltered — unlikequeryName()on the line above, which trims before falling back toUntitled. dashboardTileV1.titlecarries nominLengthinschemas/`, so such a document is schema-legal.

ts.title then composes accessible names directly:

• 'Remove ' + ts.title + ' from the dashboard' (the delete button, pre-existing)
• 'Open ' + ts.title + ' in Workbench' (Replace the Dashboard-level Query button with per-tile “Open in Workbench” actions #471's tile action)

A screen reader announces "Open, — , in Workbench". The visible .dash-tile-name is equally blank, so the tile also loses its heading.

Why it is deferred, not urgent

No shipped UI writes tile.title today — it is reachable only through a hand-authored or imported document. It becomes user-reachable the moment a rename-tile affordance ships (#429 / #463 territory).

Fix

Trim before the fallback chain, so a whitespace-only title behaves like an absent one:

const authored = typeof tile.title === 'string' ? tile.title.trim() : '';
const title = authored || (query ? queryName(query) : tile.queryId) || tile.id;

That is a behavior change for existing documents carrying such a title (they would start showing the query name), which is why it wants its own change and a test rather than riding along in #471.

[BorisTyshkevich]

Absorbed into #429 and closed — owner decision (2026-07-27), as part of
consolidating Dashboard-tree management and title authoring there.

The reason it belongs to #429 specifically is the one this issue already
identified: "it becomes user-reachable the moment a rename-tile affordance ships
(#429 / #463 territory)." #429 is the change that first lets a user author a
title through the UI, and it already carried a requirement that
"blank title follows current schema/validation requirements and safe fallback
rules" — the same rule, stated twice in two issues. Settling it once, in the
change that introduces the authoring UI, is cheaper than fixing the fallback and
then re-deciding it inside the dialog.

Carried over into #429's "Blank means blank — trim before the fallback (absorbs
#476)" subsection, with your facts intact: the truthy whitespace-only
tile.title winning the || chain at
dashboard-viewer-session.ts:550 unlike queryName() which trims first; no
minLength on dashboardTileV1.title in schemas/, so such a document is
schema-legal; and the composed accessible names ('Remove … from the dashboard'
pre-existing, 'Open … in Workbench' from #471) announcing "Open, — , in
Workbench" while .dash-tile-name loses its heading.

Your suggested fix is the requirement verbatim, plus one addition: the same rule
applies to any title #429's new pencils write, so a user cannot author a
blank-but-truthy title in the first place. Your caveat is retained too — this is a
behaviour change for existing documents carrying such a title, so it gets its own
test rather than riding along; and since no shipped UI writes tile.title today,
only hand-authored or imported documents are affected.

Nothing dropped; closing as absorbed, not as rejected.