Also consider blind folks with screen readers who can't avail themselves of all the JS functionality—so it's important to make sure they have access to some kind of content.
They can avail themselves of almost all JS functionality.
The biggest issues facing AT (accessibility technology) and JS are these:
AT is usually not nicely free or cheap like browsers are, so upgrading AT isn't like upgrading a browser-- it often costs mooooola. So unlike with browsers, it may be more likely that users with AT are using old AT. However it would also be true that old AT requires old browsers, so if you know you're serving a particularly high number of general AT users, then likely that's where your higher-than-normal percentage of IE6 is really coming from. I think developers just have to draw a line somewhere and decide what they will support, but less flippantly than they do with non-AT users still sitting on IE6.
The new interaction thingies every dev and his dog want to do often require the building of widgets. A widget in poes-speak is something you build out of silly HTML (like divs and spans) in order to create something which does not actually exist in HTML. Basically, HTML is a markup language designed for documents, and therefore is missing a lot when it comes to building applications. AT is trying to keep up with these widgets but it's hard when most of the things built are completely custom.
ARIA is one answer to the not-so-custom parts of widgets. A lot of widgets are recreating the same basic application thingies: modal dialog windows, form selection sliders, progress bars and boxes that update via message protocols or push notifications. So you can label a lot of these creations with ARIA to give some meaning to the browsers' accessibility layers which helps a lot. But there are places where the spec hasn't settled, the browsers don't or mis-understand some states, or the AT has not kept up.
Back to the topic:
- recreating something like GoogleDocs
Users of plugins like NoScript can selectively block scripts by domain, subdomain, etc. Sites who are, for example, built with dependence on Google AdWords (where if the AdWords don't run, none of the site scripts run either) may be broken because someone is blocking one external thing (NoScript specifically works around this, but I wouldn't expect all blockers to do this).
Always ask yourself: are you building a basecamp? Are you making a real APPLICATION? Is what you're building on the scale of, say, a mail client? Live collaborative document editor? Audio or video editor? Drawing on the screen to turn your tablet PC into a real drawing tablet? Is it expected to be able to reach deep into the device its viewed on and use its stuff like the camera or the filesystem? Answer that question honestly, and then think about how you'll do your backup plan. If you b0rk a script, where you will send users until you fix it? What will they still be able to do?
Make your grandma use your page/app/thing and see how long it takes her to break it.
Testing with JS off is just something a good, consciencious developer does. They also test with images off, CSS off, with an imitation of butt-slow internets, with crappy colours for colourblindness, on multiple input and output devices... it's just part of that Stuff Good/Excellent Developers Do. Not necessarily because 4 people on SitePoint forums block it. That's a silly reason. The reason to do it is because testing your site instead of assumptions is good.