[codeflo]

The author mentions in the article text (and re-emphasizes in a footnote) that you will want to use platform-specific APIs for improved accessibility even when this limits extensibility:

> you will want to support font fallback, input methods and screen readers, all of which require interacting with platform specific APIs and are thus much less customizable

May I ask the heretical question why of these two situations:

(a) you have one editor that makes compromises between extensibility and accessibility

(b) you have one non-accessible editor that goes all-in on extensibility, and one not-fully customizable editor that goes all-in on accessibility

one would prefer (a) over (b)? Situation (a) sounds like strictly more total effort for a worse outcome, as you have one much more complex system that tries to navigate both purposes.

[jockm]

Because accessibility should be front of mind for all apps. We don’t want disabled people to be treated like an afterthought or only using specialty apps. Anyone can become disabled and need these features, either temporarily or permanently and shouldn’t have to change their entire tool chain to adapt

[hulitu]

> We don’t want disabled people to be treated like an afterthought or only using specialty apps.

We also don’t want non-disabled people to be treated like they are disabled (to not use other words). And no, gray on gray is not accesibility, Narrator is not accesibility, dumbing down things is not accesibility.

[InfiniteRand]

It would depend on your accessibility needs, if you only need the apis included in a, then a would be a better option