consider to scope ARIA idl interfaces

[asurkov]

@annevk raised a point at https://bugzilla.mozilla.org/show_bug.cgi?id=1628418#5 that ARIA idl interfaces should be probably scoped by HTMLOrForeignElement mixin (aka HTMLElement, MathMLElement, SVGElement) or even more tightly, because the only small amount of attributes like id, class are super global, and perhaps it doesn't make sense to do the same for ARIA.

Not quite confident what scope the spec defines for ARIA itself, I always assumed that ARIA attributes can be applied to any element for any namespace (which matches both Firefox and Chrome implementations), but not sure if it has any practical meaning.

Anyway, I suppose ARIA and ARIA idl scopes should match, but not sure about what could make the best scope for them.

[domenic]

FWIW I was only able to find rules for applying ARIA to HTML elements, not to SVG or MathML elements. (In https://w3c.github.io/html-aam/.)

[jnurthen]

Try:

• https://w3c.github.io/svg-aam/
• https://w3c.github.io/mathml-aam/

[annevk]

And elements in arbitrary namespaces? As per OP that's what Chrome/Firefox currently do. (But perhaps that should stop.)

[hsivonen]

We discussed this within Gecko's DOM Core team.

Even though elements that are from XML Namespaces other than HTML/SVG/MathML aren't that relevant on the Web these days, browsers still support rendering such elements with CSS. It seems bad if visual customization via CSS is supported but the AT exposure couldn't be customized. Therefore, ARIA on Element makes sense. Also, ARIA on Element is unlikely to clash with other vocabularies, because it's namespaced under aria- even if it isn't Namespaced under aria: as originally proposed. ARIA needs id as referent, and id has already been hoisted to Element (along with class) despite contradicting XML theory.

For completeness, it would be logical to hoist tabindex/tabIndex to Element, but keeping ARIA on Element doesn't need to have a hard dependency on such a change.