As many of you know, I and a very tiny army of WebAIM software engineers are currently hard at work developing WAVE5–the fifth version of our ever-popular WAVE Web Accessibility Evaluation Tool. As part of this process, we’re planning to move from the “static web page” model used for the first four incarnations of WAVE to a more modern and powerful “interactive web application” model. This change will allow us to provide dozens of advanced features and capabilities that were never possible (or at least never feasible) in previous WAVE versions, as well as a level of responsiveness and interactivity we could never achieve before. Generally, we’re all very excited about it.
One of the consequences of this change in architecture is that, starting with version 5, the WAVE tool will require client-side scripting abilities (i.e., will require Javascript be enabled) in order to function. (Users without Javascript enabled will receive a friendly error message telling them that they must enable Javascript in order to use the tool).
Recently, several people who have seen or heard these plans have raised accessibility objections to our requiring Javascript. We are, of course, planning to develop the application with all current and reasonable accessibility features, including use of WAI-ARIA and related web application accessibility techniques. Additionally, we have planned extensive testing with screen readers and other assistive technology in an attempt to verify that all our accessibility components are working harmoniously and successfully.
Usually, objections to this plan do not equate to predictions that we’re going to screw that up or that it won’t be sufficient; rather, they represent an opinion that requiring Javascript for a web application is an automatic accessibility violation. This might be partly a historical feeling, as some older accessibility standards contained language that said (or could be taken to imply) that in order to be accessible, a site had to work with Javascript turned off. I don’t know what motivated the inclusion of those clauses at the time, but would note that most modern accessibility standards merely say that one’s site must be accessible (regardless of whether or not it uses or requires client-side scripting).
The aforementioned objections usually seem to follow one of three lines of reasoning.
-
“You shouldn’t require Javascript because other people will call you out as accessibility hypocrites if you do.”
Often the person making this comment cannot himself say whether requiring Javascript would actually be an accessibility concern, or may even believe that it wouldn’t, but suggests that we not do it so that we don’t cause problems with other members of the web accessibility community.
-
“You shouldn’t require Javascript because that will create accessibility problems for some of your users.”
This is slightly less common than the first, and often comes with a statistic that around 10% (or something) of web users are known to browse sites with Javascript turned off.
-
“You shouldn’t require Javascript because that will create an accessibility problem for me (or my brother, uncle, mother-in-law, co-worker, etc).”
The truth is, I have never actually heard this one. That is, despite several warnings that we should not design WAVE5 to require Javascript, we have nevertheless been unable to locate a single specific web user for whom doing so would create an accessibility problem.
This blog entry is an attempt to start, if anyone is interested, a slightly more public dialog on this topic, where anyone who feels strong about this can state and explain the relevant issues as he sees them. It’s probably pretty clear what side I take on this, so anyone who disagrees with me (especially if you’re number three above) please let me know how you feel in the comments.
How about “How can you test whether a website continues to be accessible without Javascript, if it must be enabled to use your tool?”
Bravo, WebAim.
If we cannot demonstrate that “newer” technology can be implemented in an accessible way, then we are doing a disservice, making it seem that in order to be accessible, a site must be in vanilla HTML period. This then feeds the argument by some that accessibility is the wet blanket to web innovation. There are many folks working on making Web 2.0 technology more accessible, so let’s support them by providing as many real-world examples as possible.
Most of the statistics I know of say that less than 1% of Internet users have JavaScript disabled (my own testing confirmed this). Requiring JavaScript will definitely limit which users can use your site, but chances are that the majority of users you *want* to use your site have JavaScript enabled. What I mean by that: for a public web site, your users are the general public who are using Internet Explorer, Firefox, Safari, Chrome, or Opera in its standard configuration. Those who have JavaScript disabled are typically using corporate machines or older/less capable browsers. Yes, in an ideal world everyone gets access to everything, but no one bats and eye when I complain that I can’t get HD broadcasts on my black and white CRT.
The JavaScript question is really a functionality concern versus an accessibility concern (though I more frequently here the latter). When it comes down to it, all people care about is whether or not they’re able to complete the task that they went there to complete. The technology used to complete the task doesn’t matter at all.
The most reliable figure I have come across for JavaScript disabled is a 2007 blog post from the Chief Operating Officer of the service that became Yahoo! Web Analytics http://visualrevenue.com/blog/2007/08/eu-and-us-javascript-disabled-index.html that puts the percentage as European Union 1.4% and United States 3.05%.
I have never discovered the source of this 10% figure that I have heard used now for many years. Their is a 10% figure from the 2006 data on the http://www.w3schools.com website but I would not use that site as a measurement because of its rather niche content which I think is reflected in the high proportion of Firefox and Chrome visitors.
Up to this point, I have never built a public website which does not have non-JavaScript fall-backs, but I have always questioned the validity of the ‘10%’ figure.
The reason that I still use JavaScript only as “progressive enhancement” is that those of us in the private sector can have corporate clients where the blocking or disabling of JavaScript is mandated. (Odds are that these same clients are still using IE6, too.)
Whether or not there is still an accessibility case for sites having to work without JavaScript, I feel that there is certainly still a business case.
Thank you for raising this question! Our standards in MA require state sites to work without Javascript, but it’s getting harder to defend for web-based applications. Accessible Javascript is much more usable-for everybody-than the unenhanced HTML in more and more situations.
On the other hand, I often disable Javascript in two circumstances. Most frequently, I turn it off when browsing with my 1st generation Kindle. Processing JS eats up battery like kids eat candy on Halloween. The other is when I’m using dial-up, when the page weight from JS can get ridiculous. Loading twitter.com took close to half an hour the other week (though all the pictures contribute). (Right now, the HTML is about 16K and the “inline elements” add up to 873,502 bytes!)
You may have noticed that this has more to do with the “digital divide” than with compatability with assistive technology. However, the last stats I saw showed that AT users were disportionally less likely to have broadband.
I’ll be watching the comments here with great interest!
The new javascript/html5 stuff makes accessibility harder sometimes, but sometimes it makes it better.
One thing that’s harder is that there are many competing javascript frameworks, and even those that have support for accessibility (like yui or jquery) do it differently.
With the tag proposed for future html versions, we could have web-based applications that support webcam and microphone-based interactions.
Is there an organization that monitors accessibility of videogames, or toolkits for making more accessible videogames? Because some of the issues with html5 and webgl for example, are more like the issues you would see with videogames and simulations.
<device> tag I meant
don’t know if that will show up
Even when the first set of Section 508 guidelines were published and they disagreed with the then current WCAG 1.0 specs regarding this issue, I found myself concerned about projecting an image that portrayed JavaScript and scripting as an obstacle as opposed to an opportunity. In those days client side scripting wasn’t as sophisticated and screen readers didn’t have to do a lot; yet it was clear that screen readers were falling behind even then. Rather than shying away from JavaScript or other scripting technologies, I strongly believe that we need to embrace it. While I remain concerned about the major commercial screen readers and their ability to keep up, that is a different issue. As a community, we cannot, in good conscience, ask developers to curtail their use of JavaScript. We can focus a lot more on showing usable, accessible interfaces instead. I applaud Webaim’s decision to create Wave 5 with that in mind.
Besides, progressive enhancement is an extremely useful concept that we should start looking at when talking with developers. It not only addresses many of our accessibility concerns but platform and usability issues as well.
Thanks for writing this Aaron, I’ve been meaning to write something similar, but I’m stretched at the moment.
I do feel that not-requiring JavaScript is a historical hangover, it doesn’t correlate with accessibility. (I.e. those people without JavaScript are there by choice, either their own or their employers.)
I have not seen evidence that someone with a disability is any more likely to disable JavaScript than anyone else, or what accessibility reason they would have to do so. (E.g. it’s on by default when using a screen reader.)
Whilst I do agree with those (e.g. Jeremy Keith) who say build without JavaScript first, there are a couple of key exception I would call out:
1. Editing web content.
For a regular user, wiki markup is hideously unusable, especially when it comes to embedding images or adding tables. I wrote about needing a WYSIWYG editor four years ago:
http://alastairc.ac/2006/08/accessible-wysiwyg-editors/
2. An interface where you add filters to something, like creating an iTunes smart-playlist.
This is something in our (accessible to use) Content Management System, and we started off trying to create a non-JavaScript version. However, the amount of work it would have taken compared to the JavaScript based version was 2-4 times greater, and the interface would have been slow and cumbersome for *everyone*.
It’s those sort of cost-benefits ratios where maybe 5% of people (unrelated to accessibility) cannot use it, compared to optimising the interface for usability and accessibility.
For many regular developers (who don’t have the same interest in accessibility that we do), asking them to create a non-JavaScript version *and* make sure the JavaScript version is accessible will be too much.
I would rather they made the version that most people receive as accessible as possible, rather than them not putting any effort into it at all.
Computerworld posted an interesting and relevant article yesterday:
Gov 2.0, Web 2.0 clash over accessibility
Both accessibility and dial-up issues are discussed.
Disabling JavaScript in your browser is no disability, despite the related terms. Thus turning JavaScript off is a question of progressive enhancement, but not an accessibility issue.
It’s an interesting article. There is a very strong perception in the web design community that accessibility and JavaScript are intrinsically antagonist to one another, when this doesn’t need to be the case at all.
Consider the availability of browser add-ons that give you selective control over whether or not to use javascript on a particular site on a particular day (such as NoScript in Firefox).
This is simply not an all-or-nothing proposition any more.
I really appreciate reading the comments from everyone here; some I have had the pleasure to meet in person, and others I follow avidly in the social media space. So, first let me say thank you.
As someone who has recently accepted the challenge of setting standards for a large company to develop a comprehensive accessibility strategy, I have a lot to sift through to determine best practice and best user experience. I think it’s imperative, as Andy said, to establish that accessibility and JavaScript do not have to be enemies. Building for accessibility need not limit creativity or functionality on a site and can actually enhance it for everyone, if implemented correctly. This perceived choice between web 2.0 and accessibility is very real, I can attest, because it’s a battle I face every day. The comments here are encouraging. It allows me to focus on educating myself and others in my organization, finding the “how,” instead of struggling to make the case for 20th century site development.
I appreciate the intelligent discussion and hope I can add to it.
To state the obvious: Javacript is a scripting language, a tool to enhance web page design and functionality, and as such is neither inherently accessible nor inaccessible; its particular implementation is the determining factor. In practical terms, considering the sheer number of web pages being designed by non-professionals, or professionals without training in accessibility issues, and proliferation of spaghetti code never written with accessibility in mind, the end result is the erroneous impression that Javascript and accessibility are mutually exclusive. We need websites we can point to employing well-written, accessible Javascript usable by all, an example we can point to and say “This is how it can be done.”
Any recent statistics on the percentage of users with Javascript disabled are skewed by the increasing awareness of the inherent security risk of having Javascript globally enabled on webpages. Since slient-side scripting has become a primary vector for malware attacks, selective enabling of Javascrpt has, in my opinion, become a necessity for safe and secure web browsing behavior. Allowing scripting from WebAIM.org is a no-brainer.
This is an issue that I have been struggling with for a while as whether or not required that users have JavaScript enable in order to use the site or provide functionality that can only be available for those with JavaScript enable.
Then, when I look deep into this problem it seems to me that this is not a matter of accessibility but a matter of inclusiveness; of providing a site with information and services that ALL can have access to them, including those with disabilities and JavaScript disabled.
When we build something that has some core functionality that requires the user to have JavaScript enable, we are telling to those who have chosen to disable JavaScript because of security concerns or any other reasons, that they have an OPTION to enable the JavaScript and use our site to the fullest. However for those who have JavaScript disabled not by choice, but because they CANNOT enable JavaScript, whatever the reason for this be, we are telling them that they CANNOT use our site. We are not providing them with any option. In other words we are excluding them from using something we built. For me this affects the core principle of inclusiveness which was something that I always strived for when trying to educate and show people how we could build something that was accessible to ALL.
But then one might ask how can we address this issue? The concept of progressive enhancement is something that, in my opinion, addresses the problem, not only because it separates the concerns, but because it can be done in a way that does not exclude anyone from having access to information and functionality. But how could that be implemented? I came across a book called “Designing with progressive enhancement – building the web that works for everyone” by Todd Parker et all. Where they work with the principle of providing a “basic experience” and an “enhanced experience” to the users. And I quote from the book
Only after they have built the page that provides the basic experience they work on the JavaScript and CSS to enhanced the functionality and usability making sure the accessibility features are added to the page including WAI-ARIA attributes. They use a script to test for browser capabilities, which then includes unobtrusively the JS and CSS files for the enhanced experience.
It might seem a lot of work for some, but if you think about it, by building the web pages that way we can make sure that ALL have access to it no matter what kind of device they use from mobile phones, old browsers to the most updated modern browsers.
Perhaps WAVE5 should have its core functionality built without requiring JavaScript and only the advanced features would required JavaScript if they could not be provided without the use of a scripting language. That way at least all could have access to the core and basic functionality that WAVE provides.
I think allot of the reason JavaScript has historically been considered inaccessible is many screen readers used to have problems announcing changes on the page when a script modified an element. Not only this, but I think some people may feel that even when a screen reader does handle such changes correctly it may be distracting.
Also, WAI-ARIA is still just a draft. If a script can’t be made accessible without using ARIA, is it really fair to call it accessible when it uses an unfinalized draft which is still changing and isn’t fully implemented?
Oh, ditto, I’m really glad you started this discussion.
It seems like, all along, we have designed for the core audience i.e., “sighted with good motor skills”. Unless a law stipulates that design must include accessibility review, websites will be plagued with accessibility issues. User groups that are more empowered should adjust and make room for others. What is wrong with a design that highlights 1) When a page loads, it is always js disabled. 2) And only clicking the link “enhanced view” on the top etc. shall give a user all the functionality of a js enabled page. If this were technologically feasible, we can uphold the tenet of comparable access.
Thanks Aaron for the article and for helping to promote the notion that JavaScript is not automatically inaccessible. As with most technologies, it is not the technology but how you use it. Really looking forward to the new WAVE especially if it includes some the WAI-ARIA techniques.
A lot of people have said here “javascript is not the enemy of accessibility” but no-one has really explained why they believe that to be the case. For blind people using line-by-line screen-readers, I am reliably informed that having javascript inline-editing their DOM is always and obviously a pain in the ass.
How do those of you who say that javascript can be accessible deal with that complaint?
New video: Dennis Lembree (WebAxe) on Making JavaScript Accessible at YUI Theater.
Dennis Lembree also points out that you can’t assume that JavaScript is always available (corporate policy, certain mobile devices, …). That does not mean that you shouldn’t use JavaScript but it’s best used as an enhancement. “Plan for Ajax at the start; implement Ajax at the end” (quote from Jeremy Keith).
Aaron, I was just reading the WebAIM JavaScript guide (http://webaim.org/techniques/javascript/) in which it reads: “your web pages should be fully functional with JavaScript disabled. This is required under Priority 1 of the Web Content Accessibility Guidelines.”
Presumably this is referring to version 1.0 – shouldn’t this article be updated?
ARIA requires 2 things to be useful; a) the person needs to be running a browser that supports passing that information; 2) the AT needs to support it. I think that public sector organisations struggle with these requirements because they do not want to exclude people who may not have the latest technology. Before you go telling me “ya but get firefox and nvda, it’s free and solves this issue”; not to knock NVDA but it doesn’t do a great job on the desktop with third party desktop apps. It’s great on the web (sort of). However even then realise that NVDA/Firefox really isn’t an option for many people. When government departments run managed desktops where they don’t allow users to install software; where they have lists of allowed software and move at a snail’s pace; we are going to run into situations where this really isn’t possible. When people need to run a specific AT solution in order to stay employed because it works best with the systems internally; we are going to run into situations where people don’t have an ARIA supported experience. When the mainstream AT developers have products that aren’t as stable on a javascript rich environment; it sadly means that we really can’t depend on the assumption that javascript doesn’t create a barrier for someone’s participation or usage of a site. i.e. many gov departments are running IE 7 and Windows XP. Some just finished upgrading from IE 6 to 7.
Progressive enhancement is the only viable option at present.
Hi,
I enquired about the capability of the JAWS screen reader with regards to handling JavaScript and had this response from Freedom Scientific Support:
“At the present time, JAWS does not support Java Script. The only JAVA that JAWS supports is that developed by Sun Micro Systems. Sometimes JavaScript reads with JAWS, and sometimes not. However JavaScript is not officially supported by JAWS”
Surely a screen reader that does not function correctly is an accessibility issue?
WebAIM’s own survey of screenreader users shows that somewhere between 10% and 25% have Javascript off: http://webaim.org/projects/screenreadersurvey2/#javascript
That percentage is clearly higher than in the general population; so, yes, requiring Javascript is an accessibility issue.
That in itself is reason enough for any site claiming real-world accessibility to deliver a reasonably complete and functional site to users without Javascript.
The principle of “progressive enhancement” is still very much the way to go: deliver a site with core functionality and content in the form of semantically marked-up HTML, then enhance with (but do not require) CSS, and enhance with (but do not require) Javascript.
Obviously there are some complex web apps where it’s just not feasible to deliver a reasonable non-Javascript version… but where it is feasible, a non-JS version should definitely be there – for all sorts of users, not just screenreader-using people.
Greetings & Happy Holidays/2011 New Year, Web Colleagues!
Interesting dialogue… I happen to agree with the expressed views above that accessibility is often as much about how well one uses the underlying (new or old) technology to implement accessible UI design and that one should use an established baseline of good development assets (e.g., JavaScript, PhP, XML, etc) to create the most accessible, user experience of one’s product as possible… This is not to say that, in some cases (e.g., where a known user population is known not to have access to such key underlying technology or bandwidth), that might not be a business case, albeit a perhaps shrinking one, to employ a noscript option to accommodate such limitations…
BTW, the reported Freedom Scientific (FS) portion of the entry for 8/27/2010 mistakenly conflates JavaScript, a scripting language, with Java, a programming language. Furthermore, in my personal experiences, the last few versions of JAWS, at least v9.x through v11.x, have recognized some JavaScript (whether “official” or not).
great blog! Thank you for raising this question! Our standards in MA require state sites to work without Javascript, but it’s getting harder to defend for web-based applications. Accessible Javascript is much more usable-for everybody-than the unenhanced HTML in more and more situations.
+1 to the first comment from Matthew.
Requiring JS for a plug-in doesnt hurt accessibility at all or cause any issue with any particular website as the plug-in isnt writing code for the site. But its a testing tool, how can we test with WAVE that our sites are accessible with JS off? We can’t…
It just leaves a big gaping hole in the products testing capability/features. This is now not a whole testing solution, it’s just a JS ON accessiblity testing tool.
You will probably need to find another tool to perform JS off accessiblity testing.
The three senarios offered in the article regarding peoples objections are ridiculous and uninformed, if people really have those concerns I can imagine why you would ignore them. But I hope you can see past those and to the real limitations that you’re building into the product.
MichaelH-
The server version of WAVE cannot process the JavaScript on the page it evaluates. It would be a serious security concern for us to run your page’s JavaScript on our server – or to pass that JavaScript from our server to the end user. All server-based evaluation tools function this way.
So even though the WAVE interface might require JavaScript, WAVE is always a JS OFF testing tool. To perform WAVE evaluation of scripted content, one would need to use the WAVE toolbar.
Jared –
In that case its just my poor understand of the article and comments I read. I can now agree thats theres no deficiency in the approach taken for the tools abilities.
Thanks a lot for the reply, and clearing up my obvious confusion – especially considering the article was written years ago.