Accessibility violation: Tippy.js adds aria-expanded to <span> with role="tooltip"

I am not sure this is resolvable. Changing the tooltip's HTML tag will cause visual regression on the sites targeting the SPAN tags. You might have to use the patch AS-IS.

My understanding is that the patch specifically does not change the tag. (Changing the tag to a <button> was proposed as the "proper" alternate solution, but the approach in the patch as currently written does not change the tag, just removes the inappropriate aria-expanded.

rakesh.regar → made their first commit to this issue’s fork.

The patch removes the expanded attribute which I think improves the accessiblity for screen readers.

Even though a machine/automated review says the tag + attributes is invalid, it does not mean we should remove the attribute to pass an automated test.

the expanded attribute [...] improves the accessiblity for screen readers.

This is true, but the ARIA5 rules say that to be able to use the aria- attributes, you have to have an element with the correct role. By default, <span> has no semantic meaning—it's effectively role="presentation" or role="none" in ARIA terms unless styled or scripted to behave otherwise.

Ideally, we'd switch to a <button>, but that could break themes that (incorrectly) target the <span> directly instead of using a class. Would changing the tag—and potentially breaking CSS—be considered an API change requiring a major version bump?

If so, to resolve the issue, keep screen readers and machines happy, and avoid a major bump, what if we simply add role="button" to the <span> and ensure it behaves like a native button, including being focusable (tabindex="0") and keyboard-interactive (handling Enter/Space key events).

References:
WCAG 2.2: Technique ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component