JavaScript and screenreaders
For three years Jared Smith and his lovable chums at WebAIM have conducted a survey of screenreader users, analysed the result and posted them. This year’s results are out. Let’s take a moment to give them a round of applause.
There is much to digest, but one figure really caught my attention: only 1.6% of respondents had JavaScript disabled. Turning that round, 98.4% of screenreader users had JavaScript enabled.
Hopefully this will finally bury the WCAG1-era myth that JavaScript is automatically bad for accessibility or that pages that depend on scripting are inaccessible to assistive technologies.
This myth came about from the early days of screenreaders, which took a snapshot of the rendered page into a buffer and, when a user was navigating a page, he was really navigating that snapshot. If a page was changed with script the user wouldn’t know because another snapshot wasn’t triggered. (Even in this model, some JavaScript was fine. If, for example, your page contained lots of document.writes that executed immediately, and wrote HTML to the page, that would be available.)
As the Web made more use of “Ajax”, screenreaders became more sophisticated and now can handle most scripted interactions. This doesn’t mean that JavaScript is always fine to use; just as you can write inaccessible HTML and CSS, it’s possible to script away accessibility. An understanding of WAI ARIA is vital to professional JavaScripters.
(It’s also important to understand that not all accessibility needs are assistive technology needs. Christian Heilmann and Antonia Hyde showed that some scripting can be empowering for people with cognitive problems with their Easy YouTube and Easy Flickr.)
So we know that script doesn’t scare off assistive technologies, and we know from Yahoo! developer Nicholas C. Zakas’ report How many users have JavaScript disabled? that only 1% of visitors to Yahoo! have turned off JavaScript. Does this mean that we can safely forget about those who can’t use JavaScript.
Well, no. But JavaScript-required is not an accessibility problem, it’s a usability problem. As Zakas says
While the percentage of visitors with JavaScript disabled seems like a low number, keep in mind that small percentages of big numbers are also big numbers.
We spend a lot of time making our sites work with old browsers, using JavaScript shivs and polyfills but we don’t talk much about users without JavaScript. The Opera mini browser, for example, is the most-widespread mobile browser out there but, because it renders on a server, interactivity is limited (See Opera Mini: web content authoring guidelines for more information.)
How far can an application that requires Web Sockets, local storage, cross-domain messaging, canvas be expected to degrade gracefully?
(Last Updated on )
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
10 Responses to “ JavaScript and screenreaders ”
Wow! Congrats and thanks on the study. Really good work.
I’d just leave a word of caution, though. Even if screenreaders can interpret JS you still have to consider SEO. Google’s proposal for indexing ajax content must be our way out in that area, but it basically supports progressive enhancement.
As for you question… How can fancy-schmancy HTML webapps degrade gracefully?
Option 1) Show a less-capable app (websockets=refresh button, local storage=cookie(limit size), x-domain=proxy, etc.) but you probably won’t be able to mimic everything, nor want to. That leads us to number 2.
Option 2) Show a warning letting them know why they can’t access the app. It fails, but it also explains. That’s gracefully degrading in my book. 😉
[…] JavaScript and screenreaders […]
Interesting information! However, something that’s seldom taken into account is when JavaScript is enabled, but gets partly/fully disabled later on by evil proxies and antivirus/firewall programs.
For instance, when something like this happens: http://robertnyman.com/2006/04/25/an-important-lesson-learned-about-ajax-and-accessibility/
Good to see that this has been researched. It confirms a suspicion most JS developers probably had for a while. But the conclusion is that even though the reason has changed, it’s still important to have a functional non-JS version of a website :).
Disabled JS by screen reader users is not a myth from old era.
As recent as October ’09 survey reported 10% users w. disabled JS and 14% who weren’t sure (so the number could have been anywhere from 10 to 24).
http://webaim.org/projects/screenreadersurvey2/#javascript
Good to see such drastic change in just 2 years.
[…] Una delle cose più importanti è la grande diffusione di JavaScript su cui ha scritto un bell’intervento anche Bruce Lawson: ormai è diventato uno standard, ma questo non significa smettere di […]
[…] to your features. The number of people that this will affect in reality is however miniscule. According to Bruce Lawson even most screenreader users will be able to […]
Nice piece of information. All that we need to understand today is that screen readers do understand javascript, right? Could anyone here point me to resource/reference about accessibility in html 5? Looking at the basics, elements like <menu> are outcome of WAI-ARIA's <div role="menu">
Anything that ellaborates more such examples
We’ve just made a version of FixMyStreet for another country, which launches later this week (exciting!); it uses OpenLayers to display an OpenStreetMap map. JavaScript or no JavaScript, some people will be unable to use the map, and so, ever since the first version of the site back in 2007, there has been an option to skip that step. OpenLayers gives you nothing if you don’t have JavaScript, but as my original (non-OpenLayers) code was progressively enhanced, it was simple to show the same map to non-JavaScript users, with links and image form inputs which work in the same way (panning, zooming, clicking, all fine). I don’t care whether this is accessibility, usability, or whatever you want to call it; 1.6% of screenreaders without JavaScript is still 1.6%, as you say, and this is just trying my best to make a website work for the 98.4%, the 1.6%, and everyone else too.