chore: support elements not in tree for get/hasAriaValue

[straker]

Found this when tying to update our matches functions.

There's a few times when we traverse up the DOM tree (getComposedParent, just a loop, etc.) and we want to get an ARIA attribute from it (e.g. aria-hidden-focus-matches.js walks up the tree looking for any ancestor with aria-hidden). Currently it's a bit clunky to have to handle both elements that could or could not be part of the tree as getAriaValue assumes vNode, so you have to do something like this:

const vNode = getNodeFromTree(el);
const ariaHidden = vNode
  ? getAriaValue(vNode, 'aria-hidden', { lowercase: true })?.value
  : (el.getAttribute('aria-hidden') || '').toLowerCase();

This is also a problem if the element we want to look at is a custom element outside the tree, as we won't be able to look at the element internals of it.

This fixes that by allowing the two get/has aria value functions to fallback to DOM nodes if the node is not in the tree.

[chutchins25]

Nice work — the nodeLookup normalization reads cleanly and the in-tree path stays behavior-preserving. One question on the idref(s) fallback in getAttributeValue (inline).

Resolved

[chutchins25]

Approving — this resolves the getPropertyValue issue I flagged on the prior commit: getAttributeValue now passes node (not the stale, out-of-tree-undefined vNode) into the idref(s) empty-attribute fallback, and the new out-of-tree idref/idrefs property tests guard that path. The nodeLookup(node).domNode swap is behavior-preserving for in-tree and SerialVirtualNode inputs, and out-of-tree support reads cleanly.

One optional, non-blocking polish nit (no action required): in has-aria-value.js, hasInternalValue computes getElementInternals(domNode) before the prop check, so for ARIA attributes with no associated prop it does the full internals lookup on out-of-tree nodes only to discard it. Its sibling getInternalValue in get-aria-value.js short-circuits with if (!prop) return null; first. Reordering hasInternalValue to check prop first would match that and skip the wasted work — purely a consistency/micro-perf thing, fine to leave.

[WilcoFiers]

Left a suggestion. I'm okay with it either way.

[WilcoFiers]

Same here, need to put the feature flag gate in. Or maybe put that into getElementInternals directly?

[straker]

We didn't want to put it directly into getElementInternals as it's used by the gather-internals script and that couldn't really use a global axe due to the extensions needing it.

Resolved