Asking update plans for AriaMixin types

[h-joo]

Hello, while upgrading Google to new TS compiler versions(4,4, 4.5, 4.6), we had some confusions on the type changes and we'd like to ask about your future plans around ARIAMixin.

In TypeScript 4.4 in ARIAMixin interface was brought in to default typings by this PR and Element type started to extend from it.

Due to this change we've seen lots of new errors because this new properties in Element was colliding with the custom ARIAMixin implementations. We've tried to get away with the required changes by modifying lib.dom.d.ts and ARIAMixin, by allowing them to be string|undefined and kept that custom change even for 4.5.

While the attempt to upgrade google's TypeScript to 4.6, we've seen this issue again because now the type is string|null, but not string|undefined which the change was done here. But this change indeed seems to reflect the spec version 1.2.

And in the newest spec adds confusion with a note of a potential to change some properties back to be non-nullable in this section:

However, in a future draft, the ARIA Working Group intends to change several ARIA attributes to non-nullable DOMStrings, and seek implementations.

May I ask if the TypeScript team would have a concrete plan on how to deal with these changes?

I guess the biggest part of the confusion is coming from the spec being unstable and bouncing back and forth (non-nullable->nullable->non-nullable again).

• Also, the spec is sometimes different from how it's like on different browsers e.g. document.createElement('div').ariaHidden returns on Chrome: null on Safari: null on Firefox: undefined

• and the IDL is different from what it's described in the section(e.g. for aria-expanded it says undefined to be a default value).

We wanted to ask whether if you would have a plan on this just for us to avoid unnecessary work.

[h-joo]

CC: @rishipal @mprobst

[orta]

In terms of special planning we haven't got anything built ahead of time to prepare for it as our tooling is mostly based the core content of the IDLs themselves.

That said, I agree with your analysis - I think we should special case these as not nullable right now (e.g. something which undoes https://github.com/microsoft/TypeScript-DOM-lib-generator/pull/1200/files ) and remove those special cases once we get to ARIA 1.3 (and that would let whatever is actually declared as nullable change to be so)

I think we'd be be open to PRs for that, whether the TS team choose to get it in and updated during the 4.6rc is a @sandersn / @DanielRosenwasser

[saschanaz]

on Firefox: undefined

This is because currently Firefox does not support the attributes at all. (It's behind accessibility.ARIAReflection.enabled)