1) A site that isn't ready for a screen reader probably isn't ready for a voice browser or other non-visual user agent. Say, an AI/digital assistant. Or perhaps even a search engine indexing bot (though for the last 10-15 years the incentives behind this often mean people will invest heavily, even non-cooperatively, in this specifically).
2) Projects for which the engineering takes into account the possibility of serving content to non-JS or weird screens UAs from the get-go are often better technically. Not a statistically investigated theory, but my theory is that it's because if you're really doing the REST/resource-oriented thinking necessary to make a non-trivial app display responses as minimal markup, you're also doing the thinking necessary to make a good API to be consumed by a dynamic or even SPA front-end. And vice versa: if you've got a good API for a dynamic-heavy or SPA front-end, it's not difficult to represent the given resource with the media type HTML instead of JSON. Which means if it is difficult to represent a resource as HTML instead of JSON, something's probably not right with how your app is put together.
I wouldn't go so far as to say every app needs to be plain-HTML + accessibility focused, but I think there's benefits that go beyond the margins of users with direct accessibility issues.
Ux Engineering manager here for a fortune 100 company.
We don't care about any of the use cases in your comment. If our JavaScript doesn't work in your browser, you are a security risk and we don't want our site to work on your browser.
Please call our 1-800 number to talk to a representative.
> If our JavaScript doesn't work in your browser, you are a security risk and we don't want our site to work on your browser.
Sorry, what? Why am I security risk for not wanting to run the arbitrary code that your website sends me? (I browse with JavaScript turned on, FWIW, so this is a hypothetical question for me.)
> Ux Engineering manager here for a fortune 100 company.
That doesn't mean much these days when it comes to ux :-) Edit: so until we know what company you work for we don’t know if you are part of the problem or fighting against the problems.
If anything modern ux is an exercise in embracing mystery meat navigation.
I recently got an iPad and while I like it a lot it is an exercise in frustration and DDG-ing to find out if something is missing (like select all in mail) or if someone has just come up with another "intuitive" way to hide it: slide in? slide in from the right? pull down on a list that is already on top? Touch the top bar? Long touch? Turn device sideways?
I'm almost not joking when I say usability was better in the 90ies:
Ever present menus, hover to get tooltips, context menus and documentation.
> We don't care about any of the use cases in your comment
Hey, everybody has to make tradeoffs, and it's certainly conceivable that the margins of disability don't matter to you, or that your phone support is your non-visual UA, or even that you don't care about search.
That's only half the contents of my comment, though, the rest is about engineering benefits. Perhaps you don't care about those either?
> If our JavaScript doesn't work in your browser, you are a security risk
What? JavaScript fantastically useful, but it's a vulnerability surface, not a security feature.
Maybe you meant to say HTTPS/TLS? Because if you meant to use JS as a proxy for TLS support, oh, man, I have some bad news for you. Both about security and about the relative utility of engineering around proxy tests vs engineering around tests for specific feature support.
> Ux Engineering manager here for a fortune 100 company.
I'd love to know the name of the company. Don't worry, I won't try to get you in trouble or anything, it's just clear that there's opportunities to rise well above one's competence there.
OTOH, if someone's going to do a drive-by comment in a discussion where they lean heavily on the authority of a management position at a high-profile company, and then proceed to speak as if they don't understand how the area they interact with intersects with security and haven't thoughtfully engaged with the comment they're responding to, then I'm not really sure it's out of line to suggest that whatever authority they've been given has been questionably allocated.
and this is exactly my problem with Fortune100 companies. Shoving your code down our throats till we hoke, without the possibility to use it the way we want.
1) A site that isn't ready for a screen reader probably isn't ready for a voice browser or other non-visual user agent. Say, an AI/digital assistant. Or perhaps even a search engine indexing bot (though for the last 10-15 years the incentives behind this often mean people will invest heavily, even non-cooperatively, in this specifically).
2) Projects for which the engineering takes into account the possibility of serving content to non-JS or weird screens UAs from the get-go are often better technically. Not a statistically investigated theory, but my theory is that it's because if you're really doing the REST/resource-oriented thinking necessary to make a non-trivial app display responses as minimal markup, you're also doing the thinking necessary to make a good API to be consumed by a dynamic or even SPA front-end. And vice versa: if you've got a good API for a dynamic-heavy or SPA front-end, it's not difficult to represent the given resource with the media type HTML instead of JSON. Which means if it is difficult to represent a resource as HTML instead of JSON, something's probably not right with how your app is put together.
I wouldn't go so far as to say every app needs to be plain-HTML + accessibility focused, but I think there's benefits that go beyond the margins of users with direct accessibility issues.