Ask HN: Why don't websites have 'text only' backup versions?

Another thing is even if the effort of enabling is small, people responsible for the website are not even aware of the problem.

As an experiment I would drop a note to a few websites broken with JS disabled about a problem, providing a reasoning why it should be fixed and check how many respond.

EDIT: A bit of online searching mainly shows people *complaining8 about print sheets, so perhaps I'm completely out of the loop and simply haven't printed anything in a long time.

It's not much - just stripping out menu bars and other stuff that makes no sense in print, plus a few typographical changes, such as a change in font from sans serif (screen) to serif (paper).

Similar to the other comment, there isn't a clear business case for it very often, but whenever there's a website with a "print version"-link to their articles I don't see why they wouldn't do this instead. Well, aside from the fact that nobody would expect this functionality to be there, which isn't minor I guess.

[0] http://alistapart.com/article/goingtoprint

It's mostly because the website owner/responsible believes that the cost of producing a "text only" version would be bigger than the benefits achieved. If the decision is right or not, I wouldn't know - and, frankly, neither most of people who make the decision (albeit being "confident"). I seriously doubt that any thorough analysis is done on the subject, people just believe that almost everyone uses JS and images. And they might be right, or not.

Sometimes it might also be a matter of ignorance. It might happen that the responsible is not aware of this question (and neither is "made aware" by the technical people).

I know that sounds a little heartless and "not caring about the web", but it's the reality.

I've just tried it with JS, actually it's a very little of the whole content.

(Any takers?)

Model 1: ecommerce. The website exists to sell your product. Having an alternate version is a simple cost/benefit decision: will people buy your thing from a low-overhead site? This may be combined with a mobile-friendly rendition.

Model 2: advertising. The website exists to catch attention long enough to show ads. You need seven tracking systems and eleven ad networks; all of them need JS and graphics and won't make money for you otherwise.

Model 3: public service. The focus is on providing information, not on making a sale or showing ads. The benefit of a low-overhead version is clear, but you need to keep the costs low, so you can't spend much extra time or money on it.

Model 4: SAAS. The website is the service, so user satisfaction is the top concern. Understand how your users want to use your service, and provide that for them.

I think frameworks have inverted things: the easiest approach these days is to load the default config of some framework/CMS, which will make heavy use of Javascript/images/CSS/etc. in order to entice developers to use it (otherwise, why use a framework at all ;) ). In this world, turning off a feature takes more effort than leaving it on, and we end up with ideas like special "text only" alternatives.

I think there's definitely a burden on the developers of frameworks to make them degrade as gracefully as possible. Of course, this isn't always possible (especially those designed to be completely in client-side JS), but in those instances where it is possible, it can have a large impact. For example, if the developer of some popular Wordpress theme spent a little extra effort on graceful fallbacks, it would improve the situation for all sites using that theme.

Disclaimer: I used to develop a CMS with crazy-strict adherence to, among other things, accessibility standards ;)

which is obvious from your question ;)

> To me, any website implementing good accessibility (http://www.w3.org/WAI/) is likely to be perfectly viewable and browsable per what you said. But most webmasters don't know about WAI.

I'd add "or don't care".

every website has a target audience and it simply doesn't make sense to spend time and effort for this support. It's just not worth it.

It's not text-only versions we need, but sensible use of progressive enhancement. I'm totally fine with 'web apps' requiring Javascript and CSS (but please, at least give me a message to that effect, and don't leave me with an infinite spinner!) but simple web pages are increasingly broken without scripting.

It's frustrating, because it's not like progressive enhancement is hard, either.

Current trends aside, from a pragmatic perspective, I would anticipate something like this increasing development costs (labor & money) between 10-50%, and would likely have a very low ROI.