While it may sound like a good idea, it literally violates the U.S. Air Carrier Access Act and SAS (the airline) was recently fined for doing exactly what you describe[1].
This solution may also create a situation where the accessible website becomes a "second class citizen" in terms of content because managers are not willing to allocate resources to improving the dedicated accessibility-friendly version. I argue it's much better to make a11y a part of the specification process just like we did with the responsive web when we abandoned WAP.
Getting the data is easier nowadays than in the past. E.g. https://www.census.gov/newsroom/releases/archives/miscellane... and http://www.pewresearch.org/fact-tank/2017/04/07/disabled-ame...
Can you be sure that the separate accessible version would be kept up to date with the mainstream version, and have all the same functionality? "Separate but equal" didn't work when applied to racial segregation, and accessibility advocates tend to discourage it as well.
You can try to sway your boss by explaining the second "accessibility-friendly" version is needed for a different set of target audience.
http://cryptomarketplot.com/accessible-index.html is made both for geeks who use terminal browsers like links, and people who depend on screen readers and could not use the graphs.
Seriously, try the page with elinks inside xterm to even get the colored trend arrows!
Isn't this essentially what AMP is? It's not limited to Google subdomains AFAICT, e.g. apparently Cloudflare can also host cached AMP content.
I often wonder if it would be easier to push out a second, accessibility-friendly version of the site on a subdomain. Something like acc.example.com that screen readers and other accessibility tools would check for when they access example.com.
We used to do this back in the WAP days: wap.example.com, and even in the early iPhone days with i.example.com, mobile.example.com, or m.example.com.
I believe it would save time on some projects.