I would say that it violates the principle of single responsibility. Let’s say that Stack Exchange did implement its own screen reading tech on the site. That’s great, but now it needs to be maintained and tested which is additional overhead. It also means that users would have to forgo the tech that they likely have installed, such as NVDA, so that they can let the Stack Exchange tool do its job. They would also have to reconfigure the Stack Exchange tool to match their settings for their own screen reader and if the Stack Exchange tool doesn’t match the capabilities, the will have to toggle between the tools and hope they don’t conflict.
The easier thing to do is just let the user use their own screen reader that they are likely running to be able to actually interact with the browser program and OS since the Stack Exchange tool wouldn’t be able to read the user agent’s actual menuing since it’s outside the reach of JavaScript.
Additionally, a key thing that sites need to do, and Stack Exchange does for the most part, is use semantic markup. That means using <h1>
tags, <label>
tags, aria attributes, and other things that OS level accessibility tools use as hooks to be able to explain to the user what is going on.
In a similar fashion, the OS can offer high contrast features that can be applied at the entire graphics display level. It’s good to offer your own high contrast style sheet, but if you enable it at the same time the operating system enables high contrast, they will either cancel out, or fight.
In short, Stack Exchange does have accessibility features, but it doesn’t try to force a particular, potentially bad, implementation on you.