How to Plan for the Absence of JavaScript

Though the methods used to gather website traffic statistics call into question the validity of the stats themselves, the fact is that some of your website’s visitors will have JavaScript disabled.

You could divide your traffic sources into four broad categories:

Search engines, mobile visitors, visitors using screen readers and visitors who have JavaScript turned off.

When planning your information architecture and design, you must figure out how to deal with these special groups.

I have assembled a few recent real-world scenarios to find clarity on the issue.

When you want to hide lengthy content behind an animated scroller, or rotate through products or testimonials in sequence, or present categorized page-level content cleanly, you could use accordions, carousels or any other imaginative solution.

If you keep up with JavaScript best practices or use any of the myriad of JavaScript libraries, you are probably already familiar with unobtrusive JavaScript, which is the technique of presenting JavaScript interactivity only when JavaScript is enabled.

This principle should be extended to presentation as well: build your dynamic feature(s) and set your display and visibility values only after the document is ready and only if the visitor has JavaScript enabled, rather than set the properties in your HTML code or define them server-side.

Like many screen readers, Google’s crawler tends to ignore content wrapped in an element set to display: none, while it does crawl any content set to display: visible.

So your task as a designer is to plan the space and layout around your dynamic features, and also to prepare for instances when “dynamic” is not an option.

If the content on one of your pages will always be visible in the browsers of certain users, how should it be displayed? Should hidden content remain hidden even if JavaScript is disabled? Should all content be available to screen readers and search engines? If a piece of content becomes visible only after an AJAX call, how do you adequately fill that space when JavaScript is disabled?


The Accordion

An accordion is a structure that usually consists of a pattern of pairs of heading and content. Blocks of content would expand one at a time, in response to an event triggered in the heading.

Hulu’s Accordion

I recently helped one client overcome the problem of having very long pages. This client had an online catalog of training courses and stipulated that all of the information for a particular program must be available up front: no page skipping or pop-ups for core course descriptions or program definitions.

All program information had to be available to the visitor on the same page, without having to navigate back and forth in the course catalog.

The right solution here was an accordion, collapsing course descriptions beneath headings for each area of study (math or history, for example). A poor implementation would have been to set the visibility of those collapsed course descriptions before the HTML was rendered on the screen.

If the content was hidden pre-rendering, then some visitors and search engines would miss much of the important content.

Using jQuery, I targeted the content for collapsing and set the accordion to trigger after the page had loaded and the document was ready. For this client, making the content available to all audiences was extremely important. Some of the content could run very long, and so a design that could accommodate extreme vertical expansion was needed.


The Carousel

You’ll see carousels fairly often in portfolios and product spotlights.

Typically in carousels, content will scroll in response to a time-out interval or some user interaction (see “Your Recent History” on Amazon). I like carousels for their flexibility and because they allow you to fix at least one dimension of the container.

Amazon’s carousel

Another client recently inquired about the “News and Highlights” area of their home page. Like many other content blocks of this type, this one featured the eight most recent additions to their news pages (though that number could vary).

The teasers in this block contained a summary of the article and an image. The images could be large and the content long, so a carousel that rotated between teasers was the right solution here.

Again using jQuery, I targeted the DIV wrapper for the carousel and, after the page had loaded and the document was ready, applied the carousel and set my transitions. With JavaScript enabled, the home page rendered nicely: every 15 seconds, the carousel shuffled to the next teaser. By default, all of the teasers were visible, but I hid all but the first when I created the carousel.

For this client, we again chose to display all hidden content if JavaScript was disabled. In that case, the home page would expand vertically to accommodate the extra content.

We had alternatives, though. Considering the four categories of users we identified at the beginning of this article, the priority for this content was accessibility, with search engine ranking a close second. We could have satisfied these two groups by leaving all of the teasers visible but fixing the dimensions of the container DIV and setting overflow to scroll, auto or hidden.

Any of these options would have preserved the layout’s dimensions. And screen readers and search engines would have picked up on the content, too, because the content would not be hidden with the display or visibility property.


The Content Swapper

This technique is similar to the carousel in that content in a block is rotated using some animation.

The main difference is that the tweening animation is not used; instead, one piece of content fades out while another fades in (or you could have a hard transition with no fade). The swapper is similar enough to the carousel that the alternative no-JavaScript solutions mentioned above hold true.

Yet another client came to me with the task of showing an indefinite number of testimonials on their website. We opted for a content swapper in this case because we had no need for the pagination typically found in carousels (the user wouldn’t need to scroll back one testimonial or skip to the end).

For visitors who had JavaScript disabled, we respected the design. After careful consideration, the client rightly determined that the testimonials would have such a small effect on visitors that setting the display to none would not be detrimental.

The decision afforded me a little more freedom in planning the right-hand column of the website, where the testimonials were to appear.


The Sorter

Anyone who has adjusted their Hulu queue has seen the drag-and-drop sorter. This bit of JavaScript allows users to drag and drop rows (table rows, list items, independent DIVs, etc.) into a different order.

Netflix’s sorter

Take one last client of mine as an example, who had a set of standard procedures that all employees had to follow.

Each procedure consisted of any number of tasks. An administrator could add or remove tasks and could change the order of tasks.

This was a textbook example of sorting, an implementation of drag-and-drop reordering.

Thanks to Scriptaculous and Prototype.js, creating the sortable list was easy. When the code was written and the page was live, we had a perfectly operable rendering of the design comp. Then we realized that without JavaScript, we had only the HTML equivalent of a paper weight. There was no drag-and-drop or on-the-fly reordering.

Some quick thinking and slight modification of the design gave us the same set of rows we had before but with the addition of text input boxes that could accommodate the inputting of row order (note, though, that without JavaScript, we were forced to add some significant server-side validation for these input boxes). We lost on-the-fly reordering, but at least we regained the sorting functionality.

Then we turned back to JavaScript-enabled browsers and hid the text boxes mentioned above; after all, we had drag-and-drop functionality for this group. At this point, we had a perfectly operable rendering of the design comp that was also serviceable for visitors who had JavaScript disabled. Next time, I’ll know to plan for this condition.



The evolution of the web will continue, and visitors to our websites should be able to continue enjoying dynamic flair.

Carry on planning for interactive responses with animated tweens: fade in, fade out, collapse, expand, slide things around. Given all of this animation, think of how your website will appear to visitors who cannot see the animation because of JavaScript limitations. Your clients will be happier, and you’ll be a better designer for it.

Jason Corns is a freelance web developer and full-time GUI developer for Systems Alliance, Inc., specializing in usability for all audiences.

How do YOU plan for the absence of JavaScript? Please share your tips with us…

  • JC

    Wow thanks you guys. This is something that I struggle with every time I put together a site…how to balance interactivity with the fact that it won’t work on some user’s systems. Thanks so much for the tips.

  • Rahul – Web Guru

    I like accordion quite much… and yes jQuery effects are equally impressive too.

  • SDC Software

    It’s hard to imagine a site that has no JavaScript in the background, and still looks attractive to users. JQuery change the way of designing web sites. However developers should always have on mind that JavaScript could be disabled. Thanks for the article, it’s really useful.

  • Jordan Walker

    Interest to see how degradation comes in the form of browsers and interactivity.

  • Stelian Andrei

    Regarding this issue, I always tend to develop a page having in mind that JS is disabled and balance the content the best way I can, keeping in mind the fact that I will latter on add the JavaScript interactivity. After the static page is finished I can simply add any JavaScript that would make the page more eye-candy or accessible to users that do have it enabled. I think this is the best way to ensure degradation will not mess up the way your content is displayed.

    Even in these times when JS is a very important part of any web page, there are however people that disable it. One thing to keep in mind however is the fact that those users are most often experienced ones that know how to control their browser and will enable JS if things look very awkward.

    What I’m trying to say is that people that disable JavaScript will most likely expect to see some, if not a lot, of web pages look messed up.

  • hollsk

    “display:visible” is not a CSS property. Perhaps you mean “visibility:visible”, but since visible is the default for “visibility” and has the effect of rendering text on screen, it doesn’t make a whole lot of sense in the context of this article. Or maybe you mean “display:block” or “display:inline”?

    • KristianT

      Due to the variety of layout possibilities I think he used display:visible to refer to any display option (such as block and inline) which renders the content. I think that the design and front end development process should always flow through a bottom up approach in which the page is first implemented for the most limited functionality, that is javascript disabled. Then once the page looks and feels right at this stage only then to move on and add the extra functionality

    • Jason

      @hollsk – you are absolutely right that display:visible is not a valid CSS property. As KristianT pointed out, there are a slew visible values for display (see for a list – admittedly, some of these properties are unused and have no practical application).

      Thanks, both, for your comments

  • Codesquid

    Awesome article! I think it is very important to plan for the absence of javascript! Reliance on Javascript is terrible for usability, accessibility and cross platform compatibility. Javascript should enhance a design, not act as its foundation.

  • Ash

    He means display:block

    Good article, thank you.

  • Todd J. List

    You are answering questions and solving problems that I would not have thought to ask. Very informative.

    Thank you!

  • Marco

    nice! It opened my eyes for the people with javascript disabled.

  • Shawn K.

    Better said just disable scripts for a quick view.

    For the most part, I try to keep effects only to aesthetics and if I use them in functionality, at least either have a backup plan of keep in mind what I could potentially be doing to visitors.

    I actually spent much time working on my own web framework that uses AJAX and supports automatic compensation for absence of scripting. :)

    Anyways, overall the number of users with Javascript disabled is very limited.
    For most the issue is SEO, most (if not all) search engines will not run or even attempt to crawl scripts.

  • SunkaraVOIP

    JQuery, Awesome powerful javaScript API, which can do more fun and realistic Web gadgets appliaction other than Dojo, monotool JavaScript.
    Am a Solution Architect in VOIP with JAVA Value Added Applications.
    Freshers can easy adopt the Jquery when compares to others. Execution time also so fast.
    I used this In Struts Frameworks with Ajax bases CRM Application into VOIP Value Added Applications.
    Like the TimePicker and JGrid, and My own Web gadgets

    Reply my comments…………

  • Elisa

    I was still following the german “Golden rules of bad webdesign” the whole time, so I keep JavaScript away as much as possible.

    Take my craft blog for example: since 3 years ago, progress bars were/are the in-piece and everyone wanted them. And 99,9% of all blogs which used it, used JavaScript for them. (Since has beend around, more and more get theirs from them, too)

    I am the only one I know of, who uses pure clean CSS instead.
    It does absolutely the same, faster, visible for everyone and no functionality is missing.
    I went nuts looking for a JavaScript – free solution, but it was absolutely worth it, sticking to my beliefs of “it has to be possible to get the same thing without JavaScript” and lot of webdesigner/programmers I know, didn’t believe it is possible and still, a lot of them think it isn’t necessary to make a page look fab without any scipting, because “everyone has faast internet and JavaScript enabled nowadays” but being aware, that one of my readers, who means a lot to me only is able to go online from her computer at work in the office with JavaScript off and another one is nearly blind and has special settings I am encouraged to keep webpages and my blog as accessible to disabled people as possible.

    The colour schemes I develop and design I make, and my own blog too, are always suitable for red-green blind and 3 other main sight handicaps, and so putting as few JavaScript in pages or blogs as possbible, is only a step further in making the web more accessible to everyone.

    It makes design and development in a mainly sight- orientated and dominated world a lot harder to do as much as possible server-side or non-dynamic and still look good and modern and entertaining, but in the end, the audience gets bigger, and even though a lot of webdesigners and developers and programmers have an arrogant point of view like “my design is only for the non-disabled” or “this topic is only relevant to people who can see and why bother about all others, who are not relevant?” all webdesigners and programmers who consider all this and constantly incorporate the basic thought of accessibility into their work are the biggest masters and the true professionals.

    • Jason

      I agree that all of us – designers and developers alike – should strive to deliver a site that is accessible to all walks. I would advise some caution, though, in blaming the lack of accessibility on arrogance. Budget, requirements and audience are serious factors to consider when designing and developing a website.

      For the record, though, I admire those designers that can deliver a remarkable and accessible website as much as you do.

  • James Costa

    Hey there! Awesome article, and excellent points made that sometimes we overlook (because for the most part I bet we all have javascript enabled). Would be nice to see another article on how you used jQuery to overcome the problems!

  • RCKY

    Hmm … my approach is to develop the whole site without JS. That will also help you to deal with ajax issues later on. I think JavaScript isnt for functionality, it is for usability only.

  • Bernd Artmüller

    Really interresting article, thanks!

    My personal opinion on this topic is nearly the same as the author. We can’t only develop websites for the more experienced users with all features in their browsers enabled, so we also have to consider the ones without javascript enabled or maybe using IE6, IE7.

    When I develop a website for a client with a useful and also cool javascript effect (slider, carousel), I also think about an other solution if javascript is disabled. I only show the requiered DIV’s if the user enabled javascript.

  • Jeff

    I’m pretty sure Google DOES crawl display:none elements. As the crawler does not look at CSS and only looks at HTML

  • Jason

    @Jeff – It has been my experience that Google will ignore any perceived attempt at keyword stuffing. The crawler is said to be CSS-savvy but it is also content savvy. I have never been penalized for my use of display:none, but I have also never seen any notable benefit from the content hidden by the display property, either.

    See for some further discussion on the topic.

  • Kawika

    Thanks for making a complicated subject seem easy – that of what to do for users with JavaScript disabled. Degrading gracefully is something that many designers – including myself – often forget about.

  • Tim

    This is a really good article and often forgotten by designers and developers.

    A good way to test how a site displays without javascript is to uses an add-on in Firefox called Quick Java. It lets you quickly turn javascript on and off. Unfortunately it doesn’t work on FF 3.5 yet.

  • Art

    Nice article for every web enthusiasts out there.

  • cancel bubble

    W3schools browser stats are pretty useless IMO unless you’re designing a site for web dev folk. Why? Because that’s the audience at W3schools so their stats will reflect that. It’s not the same stats you’d get from the Top 20 Alexa sites ( shows 6% JavaScript disabled but I don’t really know who these guys are or who their clients are so these stats don’t mean that much to me. It kind of looks like they’re providing an odometer-style counter that was all the rage in 1996. I don’t really get a high level of confidence from their site.

    I really wish some of the top sites would release stats like percentage of JavaScript enabled from their visitors.

  • Ryan

    The trick is for the web page to fail gracefully…

    Ps, Web developer plugin for FF has an option to disable JS for testing.

  • Jason

    @cancel Bubble – valid points about the source of the stats. As I pointed out, the stat-tracking may itself be suspect or prone to error. Regardless, most reports indicate a script-less audience of between 5% and 7%.

    Also, be very careful of Alexa – it only tracks stats reported by Users who have a toolbar that includes the Alexa reporting script installed. get someone with no toolbar and you get no Alexa data. They even acknowledge that the sample may be skewed

    The traffic data are based on the set of toolbars that use Alexa data, which may not be a representative sample of the global Internet population

    To be fair, is just as suspect – these are aggregate numbers of all stats reported from sites owned by paying customers. What we don’t know is who has paid for’s service. It could be Google or it could be some fanboy site with 6 visitors per month. Again, the point is that no matter the source, the percentages come out around 6%.

    The hard part about this is that no one can get the statistics exactly right, and your stat tracking should be done on a site-by-site basis. There is no certainty in predicting your static audience, even when predicting based on your own site stats. We have to all take the approximate numbers on faith and do with them what we will.

  • Martin

    “Search engines, mobile visitors, visitors using screen readers and visitors who have JavaScript turned off.”

    I realise that this statement was not intended to be a complete list, but one important and relevant category that you should have included is users who cannot operate a mouse. I fall into that category and it has heavily influenced my choices in development work and career path. It also means that I use the web without JS, because there is quite a lot of JS fluff that is poorly designed and either fails to work for keyboard users or at least gets in their way. Ironically, I had to enable JS just to add this comment, which should not be necessary!

    From the comments: “It’s hard to imagine a site that has no JavaScript in the background, and still looks attractive to users.”

    It’s not difficult…. There are so many attractive, distinctive, and highly usable websites that do not use JS and are none the worse for it. JS is (or should be) about adding function; it does not add attractiveness.

  • Jason

    You are absolutely right – as often as I am annoyed by the differences in actions between mouse clicks and keyboard keyup/keydown sequences (especially in form elements), I should have included that.

    The sorter is a huge culprit, when it comes to ignoring the needs of all users. One of the key elements I should point out about the Netflix sorter we have pictured here is that it also includes the actual, editable sort number in an input box that is tab-in accessible. Reordering without a mouse is not as easy, but is at least possible.

    Thanks for the comment – and the reminder that there is always more to be had.

  • Jerome Bohg

    Good read! I’m becoming more aware of the importance of planning structure and functionality in websites every day. Definitely learned a lot from reading this. Thank you.

  • Lars Weimar

    What I don’t understand is how you take advantage of awesome design attributes and scripts such as image slideshows, content sliders, animated dropdowns etc.. when not using JS? CSS3 is even less supported. There has to be a middleground. I also guess it just depends on the audience that will be using the website. If I were developing for a company like Amazon that gets such a wide variety and high level of traffic, I could see using JS as a last resort. But for the average to even higher end designs, it seems a bit silly to try and support an average of 6% to MAYBE 10% of the users that might visit the site. I think someone said it above, but it seems to depend on the client and budget. It takes work to have a site that works the same in all browsers alone (thanks IE!), nevertheless compensating for the users that have JS disabled, as well. I understand not using JS for functionality and I agree…but when the visual delivery of the content as almost equivalent to the importance of the content itself, the situation gets sticky.

  • Shannon

    Thanks for a great article. I’m really struggling to find an alternative to using Dreamweaver’s Spry Tabbed Panels. I’m new to Javascript and it came as a bit of a shock to me when I tested my site in Internet Explorer and found my menu couldn’t work without ActiveX enabled. Does anybody know a way I could get the same effect without using Javascript? Really lost now… If you want to see the menu I’m using currently (the site is under construction at this point), you can check this page: Any help or pointers would be a *huge* help!

    • Lars Weimar

      Hey Shannon,

      Check this link out:

      And this one:

      There’s no way to get tabbed panels without using some kind of Javascript. Which really goes back to my original post; at what point do we let content presentation reign over accessibility? At some point, we simply need to ignore something as small as 6% or less of the web surfers (this is highly subjective depending on the site and its target demographics) if we want to continue to evolve in web design/content presentation.

      Hope those links help!

      • Jason (author)

        I think you might be missing part of the focus of this post; I’m not advocating we abandon JavaScript – but layout planning should never depend on JavaScript.

        You are absolutely right that you can’t get a tabbed effect in all browsers without JavaScript (forget IE6 and you can use element:hover). The idea of the post is not to abandon the tabs that Shannon is trying to implement but, rather, build the tabs in such a way that everyone can play.

        For example (and note that I haven’t spent much time going over the HTML provided in that post), alter the menu and tab structure such that the tab titles are elements within the LIs (span, h6, etc) and the tab contents are div structures, also within the same tab. With such a construct, a JavaScript-less visitor would see (appropriately styled, of course):

        * Home
        * eSolutions
        SEO, SMO, R&A, etc
        * Resource
        Downloads, Blog, Guides, Training
        * Contact

        Incidentally, the nav should be built with this type of structure anyway, and only reconfigured after the document has loaded.

        Does this view match the visual goal, when JavaScript is disabled? No, probably not. Have you now provided a way for all visitors, regardless of scripting capabilities, to access your primary navigation? You bet.

        You can’t make the blanket statement that we should abandon non-ideal layouts for script-less visitors else you run the risk of alienating what may be an essential part of your audience.

        Shannon, while we’re on the topic, if one of your primary navigation items is search engine optimization, you should probably employ techniques like those I described here, to represent a little of that SEO expertise your site proclaims. Moving forward, though, I would think about writing some HTML to mimic the structure I described above, then using JavaScript to show/hide the tab content and set the layout classes for the LI tags. If you don’t feel like writing your own block of JavaScript to do all this, I would check out the jQuery UI Tabs – The jQuery and UI libraries do add a little bloat, but tab functionality is easy with this plugin.