|
|
|
|
|
|
by mikkergp
1995 days ago
|
|
|
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. |
|
|
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/