ARIA reflection polyfill should treat setting undefined the same as null

[nolanlawson]

Description

We treat setting null on aria* properties as equivalent to removing the attribute.

lwc/packages/@lwc/aria-reflection/src/polyfill.ts

Lines 19 to 20 in 1b85b46

	if (isNull(newValue)) {
	this.removeAttribute(attrName);

But Chrome/Safari treat undefined the same way (and we don't):

const div = document.createElement('div')
div.ariaLabel = undefined
div.getAttribute('aria-label') // should be null

In Firefox, using our polyfill, the above is "undefined" instead of null.

Steps to Reproduce

Repro

[git2gus]

This issue has been linked to a new work item: W-12370589

[nolanlawson]

Interestingly, it turns out this is not actually how the spec is written. I've filed a spec issue: w3c/aria#1858

However, it is consistently how Chrome/Safari behave. They treat undefined the same as null, whereas any other falsy values (0, NaN, "", etc.) do not remove the attribute.

I would vote that we align the polyfill with the de-facto implementations from Chrome/Safari. It would be bizarre if Firefox behaved differently from Chrome/Safari, or if the non-standard props like ariaLabelledBy behaved differently from the standard ones like ariaLabel. (The latter would be an observable change in all browsers, though.)

We can also wait to see if the spec authors want to push back against the browser implementations. I have a patch ready to go if we want to align with the de-facto implementation: 2f04edd