Off Topic:
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.
Lots of devs don't bother, for example, testing that lightboxy Javascript modal window with a keyboard. They get their panties in a twist when they realise the user can actually just keep tabbing around on the page below (and while a sighted AT user or regular keyboard user would realise something went wrong, a full screen reader user would not. The page would seem normal and the dialog they clicked would just seem like a link that didn't do anything).
Back to the topic:
Originally Posted by
EvanGR
When designing a website with javascript, what is the need to test the website with javascript turned off? I've read this a few times, that a website should work when javascript is not available on the browser (for some reason). Who does this, on what percentage, and why?
The percentages are getting low enough that, if you are not getting a hundred bazillion gazillion pathilizillion users per second (like Google, facewaste, amazon etc get), that 2% will never make a business case for you or your clients. What the percentage of permanently disabled-javascript users is, will not make you change how you build or how you test. Even knowing why probably won't, because the other 99.999999% of users have JS on because they have no clue anyway. Chances are, those people don't really know the difference between a browser and teh interwebs anyway. Those who've answered in this thread are possibly all your JS-off users :P (plus me).
The (main) reason to test your site (and maybe also application) with Javascript off is to make sure you're not writing garbage in the first place. To see that you aren't actually replacing built-in browser and OS functions with never-quite-as-good Javascript. You replaced a <select> with a <span> and Javascripted it into a fake-select that now matches the Design Guru's colour scheme? Great, but now you have to add in the accessibility roles by hand (usually passed on by the browser to AT automatically for you), all the multiple device interactions the OS did for you (like, can we type a single letter and jump to that option? Do arrows work? Tab? Spacebar? What about touch devices, speech-to-text, and whatever other device someone's computer supports?). Frankly, I expect anyone calling themselves a *good* developer to have tested all sorts of things when they make a decision like this. Most devs seem to be doing it lightly, without thinking: Hey I heard jQuery's got this form thing so we can make pretty forms now and make those graphics weenies happy! Yay! No second thoughts, no testing, because being a developer for some people means copy-pasta.
Most Javascript implementations of OS and browser things are poor imitations. The exception to this is sometimes a very well-built (and therefore necessarily large!) framework may have been created by folks as good as the developers of OSes like OSX or Windows. They are usually UI gurus and hardware junkies. Or they used to work for browser or OS vendors. Or they will very soon :P
Are you replacing perfectly-good working HTML+HTTP for your forms? Turning Javascript off and testing shows you that you did, indeed, do such a silly thing, instead of doing Hijax (building in the defaults that have worked for over a decade and then using Javascript to hijack and change those defaults).
Are you replacing Berners-Lee-Approved-Hyperlinks with something else for the lulz?. Think long and hard about why the benefits of replacing default browser behaviour are just so freaking awesome you can't refuse. Then think about your backup plan for when it breaks. Build defensively. Assume your clients are attackers. Assume your Javascript is filled with bugs. Assume some browser out there hates you.
Does your page suddenly load three times as fast with Javascript turned off? That's a big sign right there you're wasting too much time requesting things, loading too much, using one of those single-line-of-codes-which-call-3rd-and-4th-parties-with-millions-of-lines-of-code and probably edging into territory better left to HTML and CSS.
Is your page completely blank and 100% or 90% useless without Javascript? If so, you are either
- recreating something like GoogleDocs
or
- Javascripting way too much. Possibly also relying way too much on someone else's servers if most of your JS is for displaying ads, spacewaste Like buttons and ShareThis junk.
I'm constantly amazed at how empty many web pages are (web pages who are presented as DOCUMENTS, not applications, like say, news sites) when Javascript is off. No comments, no videos, no pictures (and blissfully no ads).
The other big reason to test your page without Javascript is to be fully aware of the experience anyone visiting will get when $hit Goes Horribly Wrong. Don't kid yourself: if you're importing code from another server (facewaste code, jquery, google, ads) you're not only a target for any hacks (on those other servers, not necessarily you at all), you're also a victim of any screwups on their end. When they update that script you import, you're allowing them "update access" to Your Stuff.
Your users may be in Crappy Bandwidth Land. Don't kid yourself here either: unless you are explicitly targetting the metrosexual big-city youth with the cash for the high-data plans and excellent wireless access all around, any group of users may get their Javascript download interrupted. Since most devs still use Javascript that blocks, the whole page load may get interrupted. ohdamnthetrainjustwentintoatunnelaaaaaah! ohnoesabirdflewbyaaaaaah! If you are hoping for mobile users, you really should just assume this. Have a backup plan. If you have actual dedicated for-mobile pages, make sure they're not asking users to download an arm and a leg and a firstborn and the moon. I heard an excellent presentation about, among other things, Javascript on mobile (mobile not meaning small, but meaning... mobile. Moving) by Rachel Andrew whose company was doing a site for a large outdoor festival where it was expected most users would have bandwidth issues. Javascript half-loading was (is) a real problem. Stephanie Reiger stated that frameworks like jQuery may still not something you want to ask a battery-dependent, mouse-turd-CPU flakephone to download.
I understand there are some security concerns, and tools like NoScript disable scripting... but you do expect dynamic sites to break if you cripple the browser, it's normal. Why would a javascript programmer worry about these corner cases?
It's not that a full-blown web application is not expected to die horribly when Javascript malfunctions. Nobody expects to see anything at all if you're trying to access a GoogleDoc without JS. Nobody expects Twitter to work without JS (even though the basic principle of it would work just fine with old-fashioned HTTP and HTML and a huge-a$$ server group).
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?
When people say "You should test your site with Javascript off", it's hopefully part of a bunch of shoulds. You should also test your Javascript broken. Break it. Break stuff on your page. Let half of it load... what do you get?
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.
Reply With Quote
(Perhaps you mean you couldn't care less. 
Bookmarks