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.
> 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.