Post

One minor feature of Preact 11 that we haven't talked about much is the strictly typed aria roles on HTML elements, where possible. In short, `<header role="form">` will now be a type error. Spent quite a bit of time going through the spec docs to build that out, doing our part to make the web more

6 reposts58 likes

This did already catch a few mistakes in an app at $DAY_JOB, hope it catches mistakes in other apps too! Bad aria is worse than no aria and browsers have basically no guardrails for this unfortunately. Types in JS frameworks (along with linting tools and the like) can step up to help out.

accessible. Now, there is a potential downside we're still looking out for, and would love to hear from you if it's a problem. Elements like `<input>` are not so simple as to just have a subset of roles that are applicable; instead, it relies on the input `type` attr: github.com/preactjs/pre...

github.compreact/src/dom.d.ts at 8ff8785bac0749c8129f2a76920b3f10b9d6766f · preactjs/preact⚛️ Fast 3kB React alternative with the same modern API. Components & Virtual DOM. - preactjs/preact

TypeScript's handling of discriminated unions often leaves something to be desired in terms of ergonomics and, as we discovered, perf, which unfortunately this is very susceptible to. Polymorphic inputs are especially at risk here. It's going to be something we keep a close eye on, but for the

moment, the a11y benefits seem like they outweigh the edge cases. Worst case, we'll make the strict discriminated union types opt-in, still filtering roles, but making all roles available regardless of attributes that would reduce that list further.