It's separation, because it introduces the chances of an inequitable experience being created as the "customised" version for screen reader users drifts out of sync. This may not even be down to anything malicious; plenty of companies create mobile-friendly versions of websites and apps, only to find that as years go by, they no longer have the budget to facilitate their upkeep. Far from assigning them to the trash heap of history, these often continue to be provided, offering a substandard experience, and this is despite companies having so much data available about high mobile usage. The chances of it happening to an accessibility-specific version are higher because the likely user take-up is lower, and as this post and thread indicate, speciality skills are often required to make a good job of it. Not like responsive web design, where experts are ten a penny.

There are other reasons this approach is flawed, of course:

1. Screen reader users aren't the only disabled people out there. Heck, even within that group, there are those who use the software as an absolute necessity, and others who use it in addition with other assistive tech like speech recognition or a magnifier. Nobody in their right mind is going to create a separate experience for every subset of disabled users. Even if they did, how would they be surfaced?

2. Some people are only temporarily disabled, e.g. because of an injury. They don't have the lifelong feel for how to look for accessibility settings or separate modes, so they aren't likely to benefit from a shiny accessible version. Making your main product inclusive prepares for this.

3. The aim should be to allow customisations to be included which aren't intrusive to those who don't need them, e.g. via techniques like WAI-ARIA[1] which allow additional context to be added for screen reader users while remaining invisible to everyone else.

[1] https://www.w3.org/TR/wai-aria-1.2/