Comment by Pewpewarrows | Hacker News Reader

Comment by Pewpewarrows | Hacker News Reader

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.

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?

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.

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.

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

> avoid Flash and other annoying videos

I can't think of a single reason why that would be a bad thing.

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!

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/howbrowsers...? that seems laggy when scrolling with js.

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.

> 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.

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?

> 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?

Because the millions of dollars spent adding rubberized material to some-but-not-all street corners sounds-based UIs for some-but-not-all intersection lamps could easily buy those who need it a vehicle to climb stairs?

Yeah, I'm sure you could engineer a wheelchair that fits into existing spaces reasonably AND climbs ALL stairs. </snark>

Also: perhaps you are forgetting a few very important benefits of those street corner ramps that have nothing to do with wheelchairs:

* People pushing strollers and carts now have an easier and safer way of getting out of the street.

* Old folks who can walk but not climb stairs very well can get across the street easier.

* Everyone has a non-0 probability of tripping as they cross the varied height curbs in cities - ramps reduces that significantly, saving society a lot of lawsuit and medical costs, this is a continuing benefit.

Not a benefit, but a solid argument:

* Since almost all of the money spent on putting these in is part of normal road/curb/sidewalk maintenance anyway, its probably not as expensive as you suggest, and since the tooling exists, why not do it right this time, rather than the old way?

* Since the government is building sidewalks, do you really want your government to actively exclude people from participating in basic "for everyone" stuff because of reasons like wheelchair bounding? I can understand if it is a result of choices they make (e.g. keep sex offenders out of parks), but telling someone "sorry life sucked for you, no more participation" is not a function of a democracy.

I have noticed that accessibility features often help usability even if not strictly needed, just like in your argument.

For example for restrooms, instead of a dime-sized button for soap, there can be an accessible button big as a palm that is easy to hit and light to push.

I was going to write most in my original post, but I figured most reasonable humans know that climbing stairs does not mean climbing all stairs in the world ever.

It seems like it's been a while since you read the HN guidelines. It might be good to read them again.

I'm not sure that it was at all obvious. You suggested that all ramp building and such accessibility activity should be replaced by a stair climbing chair. I, via a bit of snark, pointed out that such a suggestion is impractical.

You and I will have to disagree on whether or not my 1 line of snark (respectfully labeled as such) in an otherwise civil and respectful reply about the practicalities of ramps constitutes incivility. I personally would say that in a conversation face to face, and very few people find me offensive (and many of those who choose to be insulted by my views not my conversational style).

That's a good idea about screenreaders, but a horrible example. Screen readers a easy to fix (with minor semantic improvements to markup, or providing an API) , since there is DOM. Ramps are trivial and more broadly applicable ("universally accessible" is the official term, since they help everyone, wheelchair or not) than permanent-need wheelchairs. Ramps are the JSON API of the physical world leader.

As someone who has worked extensively with JavaScript web apps specifically geared towards accessibility, I can say that without a doubt the two major screen readers work with JavaScript. There are some quarks that you have to deal with but they do work, the issue is that not many developers take the time to test with them and make the necessary tweaks to get them working correctly. The biggest one being ensuring that the tab orders on elements match the flow of the application dynamics.

Do you know of any good testing guides, checklists, or suites for ensuring your site, js or not, works with screenreaders? I'd like to do a more thorough job of supporting people with disabilities (blind, colorblind, etc.), and am compiling a list of resources.

wave is a good tool, though they do complain about scripts, which can pretty much be ignored now days. Run in on HN and it will give you an idea of what it does http://wave.webaim.org/ http://www.webnauts.net/check.html also has some tools but their browser emulation is dated. That being said the automated tools are good for double checking your work but nothing will replace the need for downloading a reader like JAWS and going through your site. If you look at my other post in this story it gives some development type links. As for colorblind, I don't know, I am color blind so I get our free on that one, my sites are already accessible to the colorblind. The big offense on that one is always make sure you back up color coding with some other type of system such as a number or icon system.

The web was built in a manner to separate content, presentation, and later logic. It is those who insist on adding requirements that break it. Which then have to be fixed (see css).

Actually, modern screen readers and similar work off the DOM and tend to have full JS support (some are based on webkit).

here's a link to support that http://www.brucelawson.co.uk/2011/javascript-and-screenreade...

What does disabling JavaScript have to do with accessibility?

Screen readers generally don't support content appended to the page after load. Twitter doesn't work on a screen reader.

All of the major screen readers support content added to the DOM dynamically. They just watch particular events to know when and where to look, you have to ensure you are updating the DOM in a manner that they understand.

Perhaps my knowledge is dated then.

Thanks for the correction. Do you know of anywhere I can learn more?

This is a dated article but it does give a good overview of how the screen readers work, some items have been improved in the screen readers since 08 but for the most part it is a good starting point http://northtemple.com/2008/10/07/javascript-and-screen-read... also this is a good stack overflow conversation on getting the readers to read dynamic content http://stackoverflow.com/questions/3670570/getting-screen-re... and finally a little more bland but still containing a lot of good info the wai-aria specification http://www.w3.org/TR/wai-aria/ . Also look at Dojo in my opinion they have the most advanced accessibility library out of all of the toolkits.

If that is the case, those screen readers are broken.

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.

Reply on news.ycombinator.com