Live data from Hacker News

How many users have JavaScript disabled?

developer.yahoo.com

41–50 of 74 posts

Re: How many users have JavaScript disabled?

#41

If your website relies on JavaScript to work, then you're excluding people who can't use JavaScript. Disabled people with screen readers. If you don't cater for those people, put some money aside for lawyers.

I'm not sure why this was downvoted. While his remark about lawyering up may be overkill (unless you work for a federal agency and have to abide by Section 508 rules), his point about excluding those who rely on screen readers is dead on.

I've found that one of the major complaints that blind users have is that it's a total bitch to work with dynamically updating pages. If more developers paid attention to web accessibility, a lot of the major problems to disabled folks would be greatly alleviated.

http://en.wikipedia.org/wiki/Web_Accessibility_Initiative http://en.wikipedia.org/wiki/Web_Content_Accessibility_Guide... http://en.wikipedia.org/wiki/Section_508_Amendment_to_the_Re...

I say this as a visually impaired developer with several blind friends and family. To me, web accessibility is serious business.

Re: How many users have JavaScript disabled?

#42
post #14

Earlier quoted context omitted.

If your web page is a simple marketing site, blog, or e-store, then I completely agree. But if your web page is a complex application, having to support no-JS either shuts you out from from a huge set of interface tools, or forces you to maintain two interfaces in tandem. To me, 2% doesn't justify that, particularly when you can just politely inform the user that their browser has a significant feature disabled, and…

I agree with you and the posters below that you can't develop two versions. But I'd like to point out that "it doesn't work because JS is disabled" versus "it's not pretty because JS is disabled" are two different things, and they are not mutually exclusive. There are a slew of sites that work without JS even though they depend on it for "fancy" stuff. Plus you don't have to support two different sites in tandem, it'…

You're overlooking a lot of powerful applications that need SOMEthing to work client-side. Markup.io, recently featured here, is not the sort of application that can post-through to another page to fix. One could argue that it might also work with Flash, or ActiveX, but I'm only even mentioning them to head off somebody else from doing so, as that's hardly a solution.

I suppose it could be implemented as an Applet, but what's important is that Markup.io is exactly the sort of thing that Javascript exists for, really. And yes, disabling JS will break it, completely, and yes, I think that's perfectly forgivable.

On the whole, I agree that my blog should degrade, and data-entry type applications should work as well, but saying that everything should is completely overlooking an entire category of application for which it's perfectly acceptable, in my opinion.

Re: How many users have JavaScript disabled?

#43
post #40

Earlier quoted context omitted.

> Consider GMail. How awesome would it be if you didn't have to wait for its "Loading..." progress bar? Well, taking a look at "Basic HTML view"... considerably less awesome.

My point was that Google solves this problem the wrong way. Instead of making two interfaces, they should make one interface. If JavaScript hasn't loaded yet (or if it's disabled), the majority of the interface can still be available immediately. JavaScript should always add to the experience. It doesn't make sense to show GMail's Chat widget until JS is loaded-- but it really doesn't make sense to show nothing at al…

But what about features that _need_ JS to work? Should they be in the interface until the JS loads and they work? Then when I try to use them in the first few seconds, they're broken. If they're added afterwards, they just pop into existence...

I don't mind waiting the second or two.

Re: How many users have JavaScript disabled?

#44
If you haven't got the experience, then yes, it's going to seem like two times the work. But I am a low vision user who disables JavaScript often because developers don't understand that jut because I stopped moving my mouse doesn't mean I want to see a popup definition of the word I hovered on which obscures my viewport. (I'm zoomed in now as I type this).

I'm saddend (and a little angry) at the number of developers here who absolutely insist it's so much extra work to build a site that doesn't require JavaScript. If you follow best practices, it's not a big deal. Web apps create, retrieve, update, and delete records. No matter how fancy your new startup's idea is, you have to realize that it's all the same task over and over again, and you can do that with simple web forms that don't require AJAX. A little unobtrusive JS to capture clicks, hide boring interfaces, and transform your dull non-JS interface can go a LONG way. Plus you can test that the underlying functionality of your site works very early.

I'm required by law (Section 508) to build accessible web sites at my day job. It's much easier to make Section 508 compliant websites without JS. Then we put the icing on the cake to satisfy the other 98% of our users.

Re: How many users have JavaScript disabled?

#45
post #42

Earlier quoted context omitted.

I agree with you and the posters below that you can't develop two versions. But I'd like to point out that "it doesn't work because JS is disabled" versus "it's not pretty because JS is disabled" are two different things, and they are not mutually exclusive. There are a slew of sites that work without JS even though they depend on it for "fancy" stuff. Plus you don't have to support two different sites in tandem, it'…

You're overlooking a lot of powerful applications that need SOMEthing to work client-side. Markup.io, recently featured here, is not the sort of application that can post-through to another page to fix. One could argue that it might also work with Flash, or ActiveX, but I'm only even mentioning them to head off somebody else from doing so, as that's hardly a solution. I suppose it could be implemented as an Applet, b…

Ok, good point. My problem is sites where it is reasonable to expect them to work without JS, but end up not working at all. I would never expect a specialized site like Markup.io or asteroids-on-a-page (forgot the name) to work without JS. News sites, portals, blogs, shopping sites, etc, are all fair game for no JS (like you said).

By the way, not sure if you're the author of Markup.io, but it's pretty cool.

Re: How many users have JavaScript disabled?

#46
post #44

If you haven't got the experience, then yes, it's going to seem like two times the work. But I am a low vision user who disables JavaScript often because developers don't understand that jut because I stopped moving my mouse doesn't mean I want to see a popup definition of the word I hovered on which obscures my viewport. (I'm zoomed in now as I type this). I'm saddend (and a little angry) at the number of developers…

(This is an academic point for me right now - I'm building an app in Facebook, and Facebook requires Javascript.)

It seems like your zoom software interacts badly with behaviour that's common on some websites. Disabling Javascript seems like a reasonable workaround, but not without cost. I'm curious - why are web developers the target of your aggravation, rather than the people who wrote your zoom software?

It seems to me that a lot of expensive accessibility software copes well with computing circa 1998. But then it hit a wall. Most of the advocacy and lobbying around this issue seems to focus on forcing most developers to adapt to the limitations of this accessibility software, rather than pressuring accessibility software vendors to provide software which (a) delivers innovation and utilizes advanced technology, as you'd expect in 2010 and (b) deals with common patterns in modern software development.

Re: How many users have JavaScript disabled?

#47
post #42

Earlier quoted context omitted.

I agree with you and the posters below that you can't develop two versions. But I'd like to point out that "it doesn't work because JS is disabled" versus "it's not pretty because JS is disabled" are two different things, and they are not mutually exclusive. There are a slew of sites that work without JS even though they depend on it for "fancy" stuff. Plus you don't have to support two different sites in tandem, it'…

You're overlooking a lot of powerful applications that need SOMEthing to work client-side. Markup.io, recently featured here, is not the sort of application that can post-through to another page to fix. One could argue that it might also work with Flash, or ActiveX, but I'm only even mentioning them to head off somebody else from doing so, as that's hardly a solution. I suppose it could be implemented as an Applet, b…

Markup.io isn't actually a part of the world-wide web of linked semantic documents. Its content is inaccessible (even for viewing) unless you blindly trust its code. It rightfully deserves to be a browser plugin, it's just cleverly smuggling itself into everyone else's content because there are no good portable extension mechanisms for browsers.

Re: How many users have JavaScript disabled?

#48
post #40

Earlier quoted context omitted.

My point was that Google solves this problem the wrong way. Instead of making two interfaces, they should make one interface. If JavaScript hasn't loaded yet (or if it's disabled), the majority of the interface can still be available immediately. JavaScript should always add to the experience. It doesn't make sense to show GMail's Chat widget until JS is loaded-- but it really doesn't make sense to show nothing at al…

But what about features that _need_ JS to work? Should they be in the interface until the JS loads and they work? Then when I try to use them in the first few seconds, they're broken. If they're added afterwards, they just pop into existence... I don't mind waiting the second or two.

No. Those features should not be in the HTML markup if they are bonuses that require JavaScript. At least, they must be hidden until its script loads. But you shouldn't have to hide everything.

I'm pretty happy browsers don't show a big "Loading..." message until everything is loaded instead of painting the page as soon as possible. Shouldn't we be avoiding that too?

The bulk of that interface can be progressively enhanced.

For example, the message list and side navigation can be normal links. When JS comes along, they get actions (show this view, show this message) that override the default actions of those links (navigate to the page /message_view?id=foo).

If you try to use them in those first few seconds, they act as normal links-- they aren't broken, they just weren't enhanced yet. You can start using the page faster.

Re: How many users have JavaScript disabled?

#49
post #46
post #44

If you haven't got the experience, then yes, it's going to seem like two times the work. But I am a low vision user who disables JavaScript often because developers don't understand that jut because I stopped moving my mouse doesn't mean I want to see a popup definition of the word I hovered on which obscures my viewport. (I'm zoomed in now as I type this). I'm saddend (and a little angry) at the number of developers…

(This is an academic point for me right now - I'm building an app in Facebook, and Facebook requires Javascript.) It seems like your zoom software interacts badly with behaviour that's common on some websites. Disabling Javascript seems like a reasonable workaround, but not without cost. I'm curious - why are web developers the target of your aggravation, rather than the people who wrote your zoom software? It seems…

I am aggravated by the developers because developers are the ones who confuse interactions (clicks) with invitations to interact (hovers). When I move my mouse, my viewport moves. That's by design, as the mouse pointer can be placed near words so I can see it. Keeping the mouse pointer visible is important when you can't see it well.

Now imagine I'm surfing as a blind user, and I follow a link from HN, and my screen reader starts reading the page, only to be interrupted by a "take this survey" modal DIV. After a couple of times I'm turning off the JS, cos that's really annoying.

The people who make my zoom software make OSX (it's built into the operating system and it works amazingly well for me except for applications which fire events when I hover.

Following the principles of UJS and web standards makes it infinitely easier, in my experience, to develop web sites that work with screen readers and still use that advanced technology that everyone's gaga over. But if you can't write JS easily that works across multiple browsers, how do you ever expect assistive technology to be able to interpret it correctly? :)

Re: How many users have JavaScript disabled?

#50
post #2

The follow-up question is "Why users disable JS?". How many do it unintentional because they think JS is Java(applets ...), or the browser does not support it. I'm also wondering how many people change the advanced JS settings in the browser (do browser other than Firefox even support them?). I'm one of those 2% for different reasons(open for discussion): - it blocks 90% of ads, because most banners are JS driven - I…

I'd reckon that most of them are FOSS weenies and/or security paranoid. At least, that's the common thread among my peers who disable JS as a matter of principle. They are proud of it, and they are happy to find a reason (like requiring JS) to snub your web app. Then there are the NoScript people, who are willing to whitelist your site to allow JS if they think there is value in it. These people skew the numbers but…

Paranoid is assuming attackers are out to get you. I just assume attackers are abusing automation and out to get everyone, because we have already seen that happen several times, and there's no reason to believe javascript sandboxes are suddenly flawless despite their disappointing history.

I also have scripting off because I tend to be curious about the diligence and talent of the authors at a site.

Post reply on HN