[jscholes]

> I can't imagine websites doing anything but dropping screen reader users into a separate experience; rather than doing the work to design for accessibility in all their experiences

I agree with this. I will say that developers who are 100% unwilling to entertain changes to their "main" UI to accommodate accessibility are in the clear minority. But even the most well-meaning devs and designers will ask questions like, "could we just do this for screen reader users ...?". It's a slippery slope from there, with technical debt, legacy implementation and ghetto user flows all the way down.

[cosmotic]

I wouldn't be surprised if some sighted users turn on the screen reader to get the 'worse' (read: superior) user experience. In some cases, the screen reader supported experience would be faster, easier to use, and more reliable.

[toast0]

It might well be superior when released, but will it continue to support everything, or will it sit around with no updates and miss out on new features, or simply stop working and have no one notice?

[cosmotic]

In large, the reason the screen reader versions would exist is the threat of lawsuits due to the ADA. I work professionally in this realm and accessibility is a huge part of our development and QA process. A release doesn't go out unless thoroughly tested for accessibility. I presume that would just map on to the screenreader site forks.

[mwcampbell]

Still, mainstream developers make decisions based on data. So if we want them to serve our community, shouldn't we help them by giving them data on how we use their sites and apps?

[jscholes]

> Still, mainstream developers make decisions based on data. So if we want them to serve our community, shouldn't we help them by giving them data on how we use their sites and apps?

Quite possibly. But there is an argument for that being voluntary rather than mandatory, even if that decision is provided via a switch in OS-or-screen-reader-level settings. But then there are questions such as:

- Should such a setting be switched on by default?

- What sort of users are likely to enable/disable it?

- If there is any correlation between level of technical skill and privacy awareness, will results be skewed towards the users with lower levels of technical knowledge?

- If a product team uses the data to solicit feedback from users who are detected to be running an assistive technology, but quote "power users" unquote have turned off that detection, again, will that feedback be representative?

Anecdotally, I will say that after working with some iOS development teams where this behaviour is natively available, cases which rely on an explicit detection of VoiceOver still seem rare. Whereas, use of features like accessibility label overrides without an explicit check are used a lot. On the other hand, it's becoming much more common to perform explicit checks for more visually-oriented accessibility features, like reduced motion or high contrast, some of which can even be carried out on the web now.

[miki123211]

We also need to take into account the biases in this data. If a given website isn't screen-reader accessible, the screen reader usage statistics are going to be very low. This shouldn't be surprising to anyone, after all, why would blind people go to a website they can't comfortably use? Some developers would probably still use that data to explain why accessibility isn't important, though.

Regardless of that, as a blind person, I'm all for a flag that lets you detect screen reader usage. I believe a good compromise here is disabling this flag in private/incognito mode.

[anoncake]

What if screenreaders randomly switched between revealing and hiding themselves? Developers would get statistic but couldn't deliver a different UI to screenreader users.