[toast0]

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 and auditing and testing to confirm.

Separate, but equal isn't equal.

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

[wolrah]

> Separate, but equal isn't equal.

The world of mobile web sites demonstrates that this swings both ways. Some web sites have mobile-specific interfaces that greatly enhance the experience when using the site on a small screen touch device compared to a large screen keyboard/mouse device. Wikipedia for example, the desktop interface is terrible on a phone and the mobile interface is terrible on a desktop. Obviously other sites are well known to have swung in the opposite direction and whichever variant is not their primary target is significantly worse.

I think that in a similar way the ability to serve specific content optimized for screen readers would allow those who care to deliver a much better experience, but likewise those who don't might make something worse.

---

Of course the simple web site purist in me wants to say that every web site should just stick to basic formatting and text-primary designs that work well in any browsers, but that idea is not just unrealistic thanks to marketing people but it would simply not work for so many modern sites and web applications.

I say the solution is the same as it's always been for when bad web sites do stupid things based on user agent or whatever else. Lie to them. As long as the screen reader can turn off the identifier tag it seems like the worst case outcome is a minor annoyance to have to blacklist that web site from receiving the tag.

--- edit: also a side thought, the things that make a screen reader work well also make it easier to separate content from ads, so there is an inherent commercial incentive for ad-supported content providers to only do the minimum legally required.

[mikkergp]

I’m genuinely asking here out of lack of experience — Is it separate but equal, or is it customizing the user experience? I’m not blind but it always seemed weird to me to try and retrofit visual abstractions to someone who may not be as comfortable with those abstractions then to build an experience directly to that user. Mobile sites often have different experiences than desktop sites, and we would say that’s an experience customized for a small screen, not separate but equal. Wouldn’t designing a separate experience from the ground up built for someone with visual impairment be better than fitting them into a system that’s probably wasn’t set out for them in the first place? You’re hampering the experience because you’ll always be biasing for the sighted, unless your ux lead is visually impaired.

[jscholes]

> I’m genuinely asking here out of lack of experience — Is it separate but equal, or is it customizing the user experience?

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/

[jimmaswell]

Do you also take exception to braile translations replacing "red button" with "third button down"?

[jscholes]

> Do you also take exception to braile translations replacing "red button" with "third button down"?

This is a different case for two significant reasons:

1. Utilising purely sensory references in web materials is a violation of WCAG success criterion 1.3.3, Sensory Characteristics (level A)[1]. Naturally, if you're physically brailling something, it's probably not web content but the point still stands: if your web page tells people to press the red button on the left it's not accessible to some.

2. By including alternative instructions in some form/format (or just making them inclusive from the start), you're not asking anybody to out themselves as having a permanent or circumstantial disability. You're just preparing for the case that they do. This is assuming the alternative option is available to everyone (e.g. on a web page or as a physical braille sign), rather than as something that is locked away and must be explicitly requested.

[1] https://www.w3.org/WAI/WCAG21/Understanding/sensory-characte...

[bryanrasmussen]

well, the fact is the use of a screen reader (or at least most) can be detected relatively easily by having an element in the screen reader flow that is hidden from sighted users, and if you wanted for extra surety having an element that will be interacted with by anyone accessing the page - but that is hidden from screen readers but available to sighted users.

detecting interaction with visually hidden element, but no interaction with visually shown element, can be registered as screen reader. Obviously this can also happen with bots, but probably you would prefer to register the bot as screen reader rather than to try to filter them out and inadvertently filter out a screen reader (which can often happen with bot filtering strategies anyway)

[jscholes]

> well, the fact is the use of a screen reader (or at least most) can be detected relatively easily by having an element in the screen reader flow that is hidden from sighted users

This isn't true, at least not enough to be useful. The majority of screen readers present web pages in a kind of virtual buffer, which users can browse with the arrow keys and other shortcuts (e.g. H to jump by heading). In this mode, the majority of screen readers don't fire focus events to let you know, "hey, your screen-reader-only element has been hit". You would be limited to:

1. users operating a screen reader which does fire focus events;

2. trying to highjack scroll events for this purpose; and

3. less technically-inclined users (read: beginners) who move through the page with Tab/Shift+Tab before they've learned the other keystrokes their screen reader offers.

[bryanrasmussen]

I guess #3 explains my confusion, as whenever I use a screenreader it's for testing and I just tab through.

I suppose each screen reader then has its own hotkey shortcuts? Do you know of any resource that puts shortcuts of most popular screen readers together?

[mwcampbell]

If you happen to be using Windows, Narrator has a well-written tutorial (no, I didn't write it) that goes into the most common shortcuts, and you can get a complete list with Narrator+F1 (the "Narrator" key is either Caps Lock or Insert). I believe VoiceOver on Mac also has a tutorial.