feat(commons/aria): support ARIA element internals properties

[straker]

Updates the commons/aria directory to use the new getAriaValue, hasAriaValue, and getResolvedRefs functions where it makes sense.

Here's a report of the full directory:

• commons/aria/arialabel-text - aria-label → getAriaValue
• commons/aria/arialabelledby-text - aria-labelledby: .attr() check → hasAriaValue; idrefs() → getResolvedRefs; since getResolvedRefs returns VirtualNodes, switched accessibleText(elm) to accessibleTextVirtual(elm) for the direct VirtualNode
• commons/aria/get-owned-virtual - aria-owns: .hasAttr() → hasAriaValue; idrefs(actualNode, ...) + getNodeFromTree() → getResolvedRefs (already returns VirtualNodes, so getNodeFromTree is no longer needed)
• commons/aria/label-virtual - aria-labelledby: .attr() check → hasAriaValue; idrefs() + getNodeFromTree() → getResolvedRefs; aria-label → getAriaValue
• commons/aria/validate-attr-value - validates attrs, no conversion at this time
• commons/aria/get-accessible-refs - uses node.hasAttribute('for') on raw DOM node for HTML for attribute, not an ARIA prop
• commons/aria/get-aria-value - this is the new function being adopted
• commons/aria/get-element-unallowed-roles - checks role attribute, not an ARIA prop
• commons/aria/get-role - matching browser support and not using internals global attrs to check for role resolution, and also not running implicit role for role resolution if it's a custom element
• commons/aria/has-aria-value - this is the new function being adopted
• commons/aria/lookup-table - deprecated
• commons/aria/allowed-attr / get-explicit-role / get-role-type / get-roles-by-type / get-roles-with-name-from-contents / implicit-role / implicit-nodes / is-accessible-ref / is-aria-role-allowed-on-element / is-combobox-popup / is-unsupported-role / is-valid-role / label / named-from-contents / required-attr / required-context / required-owned / validate-attr - no ARIA attr value access

Closes: #5140

[chutchins25]

Looks good to me.

[WilcoFiers]

We need to look at presentational inheritance.

[WilcoFiers]

There's another interesting scenario here we didn't talk about:

Suggested change

	});
	it('handles presentation role inheritance on an ElementInternal role', () => {
	fixture.innerHTML =
	'<ul role="none"><testutils-element with-role="listitem" id="target"></testutils-element></ul>';
	flatTreeSetup(fixture);
	const node = fixture.querySelector('#target');
	assert.equal(aria.getRole(node), 'presentation');
	});
	it('does not set presentation role when ElementInternals isn\'t an allowed child', () => {
	fixture.innerHTML =
	'<ul role="none"><testutils-element with-role="button" id="target"></testutils-element></ul>';
	flatTreeSetup(fixture);
	const node = fixture.querySelector('#target');
	assert.equal(aria.getRole(node), 'button');
	});

I'm not actually sure this is how it works in practice. But role=none on ul SHOULD set its child listitems to presentational as well. We should test this I think, and maybe raise a case for in WPT if they don't already have one.

[chutchins25]

Tried to verify the actual behavior:
getRole returns listitem (and button stays button).
Presentational inheritance is keyed off the HTML tag name (li, td, …) in inheritsPresentationChain, not the computed role, so a testutils-element never matches.

Added two tests documenting this current behavior. Re-keying inheritance off computed role is a broader change (also affects <div role="listitem"> etc.) and a genuine spec/WPT question, so I've split it into a follow-up: #5181.

[chutchins25]

Verified actual browser behavior for this exact case. Both Chrome and Firefox leave the custom element as listitem — neither applies presentational inheritance to an internal role (Chrome strips a native <li> to none, Firefox to generic, but both keep the custom element as listitem). So the current tests document the behavior that matches browsers.

This is the same spec-ahead-of-browsers gap as #5162 (internal-role conflict resolution — Chrome/Firefox/Safari/WPT bugs already filed there), so I've folded the follow-up into #5162 and closed #5181 rather than tracking it separately. Let me know if you're good with matching browsers here.

[pkra]

@WilcoFiers

But role=none on ul SHOULD set its child listitems to presentational as well.

I think ARIA only requires inheritance for (host-language-)required child elements that do not have explicit roles. (Though I spotted some odd phrasing that seems to have been introduced accidentally - I've filed w3c/aria#2832 to clarify.)

(Then again ul > test-element is invalid HTML and its repair is not specified anywhere, I think.)