6 ms·

Here is how I handle this for projects that I work on, and I haven't received a single complaint thus far: 1. Decide if the core of the site is undoable withou

Here is how I handle this for projects that I work on, and I haven't received a single complaint thus far: 1. Decide if the core of the site is undoable without JavaScript. Something like Google Docs or games relying heavily on Canvas/WebGL are prime examples. It is very rare for this to be the case, but if it is then disregard the rest of the steps. 2. Build the entire site without even considering JavaScript as an option. The advantage of this is I can finish all functionality without opening my browser window once. I build out the core with unit tests, and assert the base user workflow using integration tests that can simulate things like form submissions to route end-points. My test suite is now a constant confirmation that my site works with JavaScript disabled. 3. Open up the site in a browser, and begin the design & UX portion of development. Because the site is essentially feature-complete and tested already, I can have a lot of fun experimenting in this stage, tweaking things to my heart's content. 4. I slap this on the page after I'm satisfied with the enhanced UX that design and client-side scripting provides: <div class="jsnotice"> We notice that you currently have Javascript disabled. While this site is fully accessible without it, you're still missing out on some pretty neat features. We work tirelessly to ensure that our scripts are small, unobtrusive, and do not harm your user experience. Please add us to your whitelist, or <a href="//enable-javascript.com/">enable Javascript in your browser</a>! </div> Using Modernizr, that class only shows if JavaScript is disabled. The message itself is unobtrusive, and I always provide a way for the user to dismiss it permanently. If I want, I go into a little bit of detail on what "features" they're not experiencing fully.

goodside 15y ago
What percentage of your users actually have JavaScript disabled? How small would the user base have to be before you decided they weren't worth this much effort?
- XLcommerce 15y ago
  That's an important question to answer. Creating a site that works sans js then layering on js is great, but it does entail duplication of effort, a larger testing burden etc. It's important to work out if the ROI for going the extra mile makes good business sense. Especially given the (excellent) point the original post makes: if a user has turned off js then if your app is worth their time they'll find the js switch again without difficulties.
  - tjoff 15y ago
    Not saying that it isn't an important question but if the site doesn't work without js the user will most certainly not enable it just to decide whether the app/site is worth their time. The instant the site fails the decision has been made. If your site breaks without js you must at least realize that you will, at the very least, annoy the users who has actively disabled it.
    - Drbble 15y ago
      People who look for trouble are apt to find it. Next, you would have to build a cookieless site, avoid Flash and other annoying videos, fly blind without tracking etc. /NoScript user /I am the 1 percent
      - kijin 15y ago
        > avoid Flash and other annoying videos I can't think of a single reason why that would be a bad thing.
      - chris_wot 15y ago
        You say that like its a bad thing! Actually sounds pretty good to me :-) seriously, when building a trite, shouldn't that be th first thing you do, then layer that stuff on top? Sounds like it would actually be easier to test!
  - keeperofdakeys 15y ago
    Are we talking about applications, or webpages? Of course an application written in javascript won't work without, that is a given. That's not the problem though, its static webpages (or what could be). If I get to a website with visible content (mainly text, or images), but isn't fully functional without javascript, I probably won't enable it. If I see one where I can't see content, I'll probably enable javascript there as well, but it depends if I want to read it. Good examples of some problems I've seen are Twitter taking several seconds to load content, even when the javascript is cached (somehow facebook does it fast enough). You even have a webpage like this "http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ http://www.html5rocks.com/en/tutorials/internals/howbrowsers...? that seems laggy when scrolling with js.
- babarock 15y ago
  Imho you cannot approach the issue just from a pure numbers point of view. For instance, one big portion of the people browsing without Js are disabled people working with screen readers and such. True Story: I worked for a while on a website where users would upload and share tutorials on various topics. As the company behind it grew, it had the genius idea of selling print copies of their best tutorials. At some point, we were looking for a Python tutorial to publish. We select our favorite one, get in touch with the author and were genuinely delighted to find out that he was blind, accessing our app via screen reader. He went on to publish a book (last I heard selling at over 10 000 units in less than a year topping Amazon's sales in its category). It was our app (the general focus on accessibility, independance from Js was a big part of it) that allowed this cool blind kid to publish a best sellers book. The odds of something like this happening, clearly, aren't very high, but when they do it's instant gratification for the developer who worked on making it accessible. If you're too hung up on numbers and ROI, think of all the benefits the company got from the positive exposure it gathered from the press around the incident. In any case, unless the core of your app is in JS, it's always a good idea to provide alternatives.
  - nailer 15y ago
    > For instance, one big portion of the people browsing without Js are disabled people working with screen readers and such. Shouldn't we fix the screen readers, rather than fixing every website? Any solution to any problems that begins with 'first change the world' is not a valid solution as the project will never get past that stage. The world would be a much better place if the effort and money spent on making ramps was spent on wheelchair provisioning and development.
    - sophacles 15y ago
      Actually, we should be doing both. The screen reader usage paradigm, even with good screen readers, requires a site to have considered that case. For instance, translating icons popups, and other graphic information is a very hard problem to do without hints from the site developer. Some types of layout are very nice from a visual view, but terrible from a textual/reading point of view. It is problem that needs to be approached from all angles. To work it into an analogy: What is the point of having good, easily available wheelchairs, if there are no ramps (or equivalently wheelchair accessibility means) for people to use?
- Pewpewarrows 15y ago
  In practice it's <2% on average per site. But at this point I don't view it as any extra effort. It's just a different way of approaching my development workflow. And it might just be a placebo, but it makes me feel like the site functions are more testable and compartmentalized.

goodside 15y ago

What percentage of your users actually have JavaScript disabled? How small would the user base have to be before you decided they weren't worth this much effort?

XLcommerce 15y ago
That's an important question to answer. Creating a site that works sans js then layering on js is great, but it does entail duplication of effort, a larger testing burden etc. It's important to work out if the ROI for going the extra mile makes good business sense. Especially given the (excellent) point the original post makes: if a user has turned off js then if your app is worth their time they'll find the js switch again without difficulties.
- tjoff 15y ago
  Not saying that it isn't an important question but if the site doesn't work without js the user will most certainly not enable it just to decide whether the app/site is worth their time. The instant the site fails the decision has been made. If your site breaks without js you must at least realize that you will, at the very least, annoy the users who has actively disabled it.
  - Drbble 15y ago
    People who look for trouble are apt to find it. Next, you would have to build a cookieless site, avoid Flash and other annoying videos, fly blind without tracking etc. /NoScript user /I am the 1 percent
    - kijin 15y ago
      > avoid Flash and other annoying videos I can't think of a single reason why that would be a bad thing.
    - chris_wot 15y ago
      You say that like its a bad thing! Actually sounds pretty good to me :-) seriously, when building a trite, shouldn't that be th first thing you do, then layer that stuff on top? Sounds like it would actually be easier to test!
- keeperofdakeys 15y ago
  Are we talking about applications, or webpages? Of course an application written in javascript won't work without, that is a given. That's not the problem though, its static webpages (or what could be). If I get to a website with visible content (mainly text, or images), but isn't fully functional without javascript, I probably won't enable it. If I see one where I can't see content, I'll probably enable javascript there as well, but it depends if I want to read it. Good examples of some problems I've seen are Twitter taking several seconds to load content, even when the javascript is cached (somehow facebook does it fast enough). You even have a webpage like this "http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ http://www.html5rocks.com/en/tutorials/internals/howbrowsers...? that seems laggy when scrolling with js.
babarock 15y ago
Imho you cannot approach the issue just from a pure numbers point of view. For instance, one big portion of the people browsing without Js are disabled people working with screen readers and such. True Story: I worked for a while on a website where users would upload and share tutorials on various topics. As the company behind it grew, it had the genius idea of selling print copies of their best tutorials. At some point, we were looking for a Python tutorial to publish. We select our favorite one, get in touch with the author and were genuinely delighted to find out that he was blind, accessing our app via screen reader. He went on to publish a book (last I heard selling at over 10 000 units in less than a year topping Amazon's sales in its category). It was our app (the general focus on accessibility, independance from Js was a big part of it) that allowed this cool blind kid to publish a best sellers book. The odds of something like this happening, clearly, aren't very high, but when they do it's instant gratification for the developer who worked on making it accessible. If you're too hung up on numbers and ROI, think of all the benefits the company got from the positive exposure it gathered from the press around the incident. In any case, unless the core of your app is in JS, it's always a good idea to provide alternatives.
- nailer 15y ago
  > For instance, one big portion of the people browsing without Js are disabled people working with screen readers and such. Shouldn't we fix the screen readers, rather than fixing every website? Any solution to any problems that begins with 'first change the world' is not a valid solution as the project will never get past that stage. The world would be a much better place if the effort and money spent on making ramps was spent on wheelchair provisioning and development.
  - sophacles 15y ago
    Actually, we should be doing both. The screen reader usage paradigm, even with good screen readers, requires a site to have considered that case. For instance, translating icons popups, and other graphic information is a very hard problem to do without hints from the site developer. Some types of layout are very nice from a visual view, but terrible from a textual/reading point of view. It is problem that needs to be approached from all angles. To work it into an analogy: What is the point of having good, easily available wheelchairs, if there are no ramps (or equivalently wheelchair accessibility means) for people to use?
Pewpewarrows 15y ago
In practice it's <2% on average per site. But at this point I don't view it as any extra effort. It's just a different way of approaching my development workflow. And it might just be a placebo, but it makes me feel like the site functions are more testable and compartmentalized.