Dev-mode guard: warn when one of this package's named controls renders with no accessible name
at all.
This is the recorded answer to the prevention question raised in #3860 and resolved in #4116: an
unnamed control is silent, which is why the defect survived as long as it did. Without a feedback
loop, every dropdown or combobox added tomorrow ships unnamed and silent again. It follows the two
guards already shipping in this package — mjButton's icon-only warning and mjClickable's —
rather than inventing a third shape: dev-mode only, once per rendered control, never throwing, and
always logging the offending element so it is one click to find.
What counts as a name here is what the accessible-name computation would actually resolve on
the element: an aria-labelledby whose ids resolve to real elements, aria-label, an associated
<label for>, title, and — only where UnnamedControlGuardOptions.PlaceholderIsName says
so — a placeholder. A dangling aria-labelledby does NOT count: an idref pointing at an element
that was renamed or is not rendered yet computes to an empty name, and that silent half-wiring is
exactly the failure this guard is for.
It does not judge name quality beyond that, because a guard that fires on a merely-imperfect
name gets muted and then the empty ones go unnoticed too.
Text content is not counted. None of these controls take their name from their contents: a
div[role=combobox]'s text is the selected value and a role=switch's is its state, so counting
it would make the guard fall silent for exactly the controls it exists to catch.
Known limitation, shared with the two existing guards: it runs once, after the view
initializes, so a name bound to data that arrives later ([AriaLabel]="record?.Name"), or one
pointing at a label that a later change detection renders, warns spuriously on that first pass.
Parameters
element: HTMLElement|null|undefined
the control's focusable element — the one the name has to land on
selector: string
the control's tag, for the message prefix (mj-combobox)
Dev-mode guard: warn when one of this package's named controls renders with no accessible name at all.
This is the recorded answer to the prevention question raised in #3860 and resolved in #4116: an unnamed control is silent, which is why the defect survived as long as it did. Without a feedback loop, every dropdown or combobox added tomorrow ships unnamed and silent again. It follows the two guards already shipping in this package —
mjButton's icon-only warning andmjClickable's — rather than inventing a third shape: dev-mode only, once per rendered control, never throwing, and always logging the offending element so it is one click to find.What counts as a name here is what the accessible-name computation would actually resolve on the element: an
aria-labelledbywhose ids resolve to real elements,aria-label, an associated<label for>,title, and — only where UnnamedControlGuardOptions.PlaceholderIsName says so — aplaceholder. A danglingaria-labelledbydoes NOT count: an idref pointing at an element that was renamed or is not rendered yet computes to an empty name, and that silent half-wiring is exactly the failure this guard is for.It does not judge name quality beyond that, because a guard that fires on a merely-imperfect name gets muted and then the empty ones go unnoticed too.
Text content is not counted. None of these controls take their name from their contents: a
div[role=combobox]'s text is the selected value and arole=switch's is its state, so counting it would make the guard fall silent for exactly the controls it exists to catch.Known limitation, shared with the two existing guards: it runs once, after the view initializes, so a name bound to data that arrives later (
[AriaLabel]="record?.Name"), or one pointing at a label that a later change detection renders, warns spuriously on that first pass.