An ARIA control named only by aria-label (role=option, role=button on a span) renders empty or vanishes #108

A control that is not an a/button/summary and whose only name is its own aria-label reaches the Markdown either empty or not at all, even though it carries an actionable ref.

Observed

Found driving bahn.de's journey search through umwelt (markanywhere 0.4.2).
The station autocomplete is a standard ARIA combobox whose options keep their visible text in an aria-hidden span and are named by aria-label alone:

<input role="combobox" aria-expanded="true" ref="20">
<span role="button" aria-label="Delete entry" ref="21"></span>
<ul role="listbox" ref="22">
  <li role="option" aria-label="Berlin Hbf. " ref="23">
    <span data-icon="station" aria-hidden="true"></span>
    <span aria-hidden="true">Berlin Hbf</span>
  </li>
  <li role="option" aria-label="Berlin Südkreuz. " ref="24">
    <span aria-hidden="true">Berlin Südkreuz</span>
  </li>
</ul>

Minimal repro (semanticEvents(tagged = true) { … } of the above, with AccessibilityAnnotations.REF, through transformHtmlToMarkdown().renderMarkdown()) yields:

<input aria-expanded="true" ref="20">

<span ref="21"></span>

• The whole listbox is gone: refs 22–24 exist in the capture (umwelt events shows every option) but none reaches the Markdown, so an agent cannot see or pick a suggestion.
• The clear button survives as an empty <span ref="21"></span>, with nothing saying what it does.

The same page's date-picker day grid appears to vanish the same way (not separately verified).

Cause

applyAccessibility correctly drops the aria-hidden spans, leaving each <li role="option"> empty.
labelActionableElements exists to restore exactly this — an accessible name for a control that would otherwise render no label — but it only considers ACTIONABLE_TAGS = setOf("a", "button", "summary") (LabelActionableElements.kt).
A role="option"/role="button" element is never held or labelled, so it stays empty; the empty list items (and then the empty list) are subsequently dropped.

Suggested behaviour

Decide "actionable" by what the element is rather than its tag name: anything carrying AccessibilityAnnotations.REF, or an interactive ARIA role (option, button, link, menuitem, menuitemcheckbox, menuitemradio, tab, checkbox, radio, switch, treeitem, gridcell, …).
Then the same name order applies (own aria-label/title, then a descendant's), and the expected output is something like:

<span ref="21">Delete entry</span>

- <li ref="23">Berlin Hbf</li>
- <li ref="24">Berlin Südkreuz</li>

(exact shape open — the point is that each option survives with its name and its ref).

A combobox suggestion list hidden behind aria-hidden text is common (Vue/React select components), so this blocks any agent from completing a typical search form.

Related but distinct: #51 (computedName during capture — here the name is already captured), #49 (recovering structure from roles), #89 (heading wrapping a button).