I was called into a discussion on Twitter, and it really can’t be addressed in 140 characters, so here is my long’ish answer. It’s about JavaScript…
The Conversation
First, let me give highlights of the twitter conversation, so people who haven’t seen it can see what I’m addressing. It started by Michael Koziarski (@nzkoz) saying:
Attention web nerds, no one has Javascript disabled. No, not even them.
Don Christie (@normnz) suggested that before making those claims, @nzkoz should check US accessibility regulations.
you’ll note that I, like you, reside in another country ;). Also screw screen readers if they can’t handle 15 year old tech
@normnz rightly pointed out that their software has to work in the US, even though the company is not based in the US.
Not Even Them
I wonder what @nzkoz meant by "not even them". It is easy to assume that by "them", he means "people with disabilities". Surely he isn’t one of "those" people who still think in terms of "us and them". You know… "I have nothing against ‘them’, but I wouldn’t want ‘them’ living next door". Or… "I have nothing against ‘them’, but I can’t be bothered making my website inclusive". I chose to believe this is a case of poor wording choice on his part.
Screw Screen Readers
Now that can’t be left to interpretation. It’s quite a clear statement. The thing is, if you don’t cater to screenreader applications, it’s not the screenreader application you’re screwing, it’s the USER.
Saying "screw screen readers" is a bit like saying "screw IE6". We all rant and rave against Internet Explorer, and many of us have abandonned support for IE6 altogether. Fair enough. But it’s not Microsoft we’re punishing by not supporting IE6 – it’s those poor saps that are still using it. And there are still a LOT of people using IE6 (5 months old stats). Maybe they aren’t your primary market, but how can you be sure?
Remember this: Making websites more accessible and more inclusive is not about the software, it’s about the USER. You want your user to be able to access your content.
Myth: Screen Readers Do Not Support JavaScript
In any case, most screen reading applications support JavaScript. That is, screen readers work on top of browsers, and the support for JavaScript comes from the browser, not the screen reader. Roger Johansson explains it well:
[There is a] fairly widespread belief that screen readers do not support JavaScript. The reasoning is that as long as you use unobtrusive JavaScript you don’t have to think about the accessibility of the markup and behaviour created by your scripts.
If screen readers really did not support JavaScript, or screen reader users in general had JavaScript disabled, this could be a reasonable approach. However, screen readers run on top of web browsers that support JavaScript and, as I mention in Unobtrusive JavaScript is not necessarily accessible JavaScript, most screen reader users do have JavaScript enabled.
And since accessibility is not just about screen readers, you also have to consider keyboard accessibility in your scripting.
Unobtrusive JavaScript is great, but it does not guarantee accessibility.
In fact, JavaScript can cause problems to people using screen readers because it is “supported” – a typical example is using AJAX to refresh content on a page. Sighted users see what’s happening, but unless the AJAX is done properly, a blind user will have no way of knowing there is fresh content on the page.
No One Has JavaScript Disabled?
It may be 15 year old technology, but there *are* people who have javascript turned off, disabled, or plain old not working. I can think of two groups of users that can’t handle javascript:
- People who use phones that are not JavaScript enabled to access the web – Not everyone can afford to replace their phone every year to get the latest and greatest. There are still a lot of phones out there that don’t play nice with JavaScript. Considering the push to make sites more mobile friendly, one would think that developers wouldn’t be so quick to want to rely on technology.
- People behind corporate firewalls – There are some companies that simply turn off JavaScript at the firewall, for security reasons. There may not be many companies that have that practice, but they may be a significant part of your market.
Another Country?
In this day and age, software and website developers cannot develop just for their own little corner of the world. We live in a global market. Your servers might be based in New Zealand, half your developers might be working out of India, some in Europe, some in the US. Your clients will be based all over the world. You must abide by local regulations. Yes, it means that even if you don’t live in the US, it’s a good idea to meet US accessibility regulations.
But then, there are accessibility requirements in many countries in the world, not just the US. Canada and the United Kingdom are two significant English speaking countries. Oh, yeah, Australia as well (remember the Sydney Olympics website debacle?). Let’s not forget that even little old New Zealand has this thing called the Human Rights Act 1993 – so, ok, the Human Rights Act doesn’t specifically say "make your websites accessible", but it does mention the idea that we shouldn’t discriminate against people. Knowingly implementing technologies that create barriers to a group of people is discrimination. And if your application is destined for use by the NZ government, then you have to contend with the e-government standards.
But It’s Not (just) About The Law
In the end though, the legal argument is not one I like to use. It’s there, and we have to consider it, but we should do the right thing because it’s the right thing to do – not because we’re forced to do it. And if that’s not good reason enough, then we should consider the financial aspect of it.
Progressive Enhancement vs Graceful Degradation
The concept of progressive enhancement is not new. Make your site work without all the bells and whistles, then add the eye candy. If someone comes to the site without a particular technology, they can still get your content. This is not limited to JavaScript. Why is it not sinking in developers’ brains? It is not rocket science. And it’s not just about people with disabilities either. Old browsers, mobile devices, people stuck on dial-up, you name it, everyone benefits from this.
Wrapping It Up
The question of JavaScript is not a simple one. JavaScript is not inherently evil from a web accessibility point of view. "Accessibility" isn’t just for people who are blind, but also those with other disabilities. It’s also good for a large segments of the population that is "technology impaired" but doesn’t have a disability.
Implementing JavaScript should be done carefully, thinking of the impact it may have not just on screen reader users, but people who use only the keyboard to interact with a site, people on some mobile devices, people stuck with older browsers, etc. Don’t just think that if the site works without JavaScript it is accessible. Don’t just think that unobtrusive JavaScript makes the site accessible.
There are legal reasons to build accessible / inclusive websites throughout the world, as well as financial reasons.
How about you? Are you as disappointed as I am to still encounter those attitudes? Those developers that point blank say "screw you"? How can we help them change their thinking?
Firstly I certainly agree that twitter is an awful medium to use for a nuanced discussion thanks for taking the time to write this up.
As to the ludicrous assertion that mimi’s making, I’ll just let that slide along with “when did you stop beating your wife” and “what are you, a nazi?” and other ridiculous smears people use when they can’t be bothered being rational.
To me there are 3 cases where people claim javascript is off, in each case it’s not as simple as “NO JAVASCRIPT”. My ‘them’ was directed at each constituency, not one in particular.
The first and loudest constituency are nerds, like me, who use noscript to avoid annoying ads and XSS problems. I can, and do, enable scripts when the content is worthwhile. If a site isn’t working I’m more than capable of pressing a few keys to give it a go again. There’s no issue here. If you don’t trust a site enough to enable javascript then you’re certainly not going to put your credit card into their system and buy things.
The next lot are people with shitty phones or corporate users who have it turned off for them and can’t change it.
I personally don’t care about crappy phones, that’s a problem that will disappear over the next few years as android devours the feature phone market and iPhone et. al. continue capturing the high end. But even now, people who have a free phone aren’t likely looking to *do* anything with it. For years people raved about how WAP, or xhtml-script-mini-whatever would take over the world. No one used it, the iPhone and android come out and almost instantly the old phones are a rounding error for mobile web traffic. There’s not some large cohort of people desperate to use your website but who have no access to the internet bar their series 40 nokia phone.
As for corporates who disable javascript, I’ve not seen that but have no doubt that somewhere there’s some company implementing such a ridiculous policy. No doubt their passwords must be changed every 7 days too. Assuming your site isn’t firewalled off already, I’m guessing their IT guys will block it eventually for violating their acceptable use policy. In any case the users more than likely have internet access at home which is where they do their browsing. This group will have two solutions open to them:
* complain to IT until the ‘internet isn’t broken’ (or quit and get a job where you’re respected)
* use the internet at home
Letting them have some half-assed version of your website that only gets a fraction of the usability and functional testing isn’t serving their interests in either case.
Obviously if you’re building sites where the target market is people with shitty phones or corporate serfs with capricious IT overlords you can’t be as flippant here, but I can.
The biggest and loudest response comes from people who have the mistaken view that screen readers are some kind of magical browser which doesn’t execute javascript. Frankly it pisses me off to see developers whose whole theory of accessibility is:
“If my site works with noscript then I automatically am an advocate for the downtrodden and outcasts”
This is entirely inaccurate and lets them continue their holier than thou attitude when in actual fact they’re doing nothing to help their alleged constituency. By letting people begin and end their work with ‘no javascript’ you’re letting people avoid the harder stuff that needs to be done. Does the site use colours that everyone can distinguish? Are the buttons large enough for people who find mice hard to use? are the labels legible and readable by screen readers?
There’s nothing inherent about javascript and ajax which makes it impossible for screenreaders to work, though it’s admittedly a tough problem.
So on to ‘screw screenreaders’. My frustration here isn’t with the users, but with their suppliers who continue to fail them.
It’s been at least 5 years since javascript frameworks took off, people all over the world are using jquery, prototype, dojo et.al to improve the perceived performance of their web applications. During this period where have the screen reader programmers been? Where are the working groups trying to get some best practises established? Where are the posts to the mailing list suggesting alternative implementations of .show() or .hide() or .highlight()?
By now we could have standard javascript events or APIs to give awesome hints like:
* This content is gone, here’s the new content
* This div has just appeared and been highlighted, notify the user in an appropriate way
* There are 3 tabs here with information associated with a title
The potentials are *huge*.
Instead we have nothing but excuses, apologists and continued suffering for their customers. It’s unacceptable, and the fact people aren’t more riled up about it saddens me. There’s no putting the genie back in the bottle, people love the fancy whiz-bang ajax that people can whip up these days. You’ll never boil the ocean and convince every guy who downloads a fancy drupal widget to make sure it works in all screen readers. The only hope for those who need them is for the screen readers themselves to get better.
Nothing else will work.
I hope that clears up my flippant 140 char trollbait.
Great topic!
The whole javascript/progressive enhancement accessibility accessibility issue is one of the core fundamentals of the “Web Experience Toolkit” (http://weba.im/wxtk) a project hosted by the Government of Canada and open to the web development world.
We invite/need people from everywhere to collaborate with us.
No single developer, software vendor, Assistive/Adaptive Technology user can change the accessibility of the web on their own. If we have a collaborative space to try new things, get feedback and come up with real solutions we can make things just that much better.
Check it out at http://weba.im/wxtk
@Koz – Thank you for taking the time to explain your position. I’m glad to see that it was indeed a miscommunication.
Regarding the ludicrous assertion, wasn’t so ludicrous based on the little information that was available through your tweets. It’s also natural for people who continually get a door slammed in their face to get angry when they see a door move – whether or not it’s about to be slammed in their face. I’ve been there.
I completely agree that all too often developers think that making a site work with noscript is making an accessible site – there is indeed a lot more to accessibility than JavaScripting issues. A lot more. I’ve blogged about this and spoken about it at different conferences. This blog was addressing the specific tweets made about JavaScript though, even though I and other people misconstrued your meaning.
You’re right – screen reader software developers, particularly the big established ones, have been thoroughly unresponsive. They do what they bloody well want and that’s about the end of it.
Your ideas about different JavaScript events or APIs are excellent. The potential is indeed huge.
I don’t know how to make screen reader developers more responsive. I think the folks at NVDA are pretty good. The folks at Freedom Scientific, not so much. I’m not even sure a populace uprising would really have such an effect, but then, I’m not sure how to get such a revolution going. Yes, people should be more riled up. Yes, people should fight. Is it making apologies to say that perhaps people don’t have that much fight in them? I think a lot of people are just tired of trying to make things change and have nothing happen. It’s that door slammed in the face again – comes a point where you just can’t do it anymore. There are some people who advocate, and try to make things happen. To more or less success.
Koz asks, “where have the screen reader programmers been?” and why we don’t see them engaging on mailing lists, discussing best practices. Well, playing the devil’s advocate here – why should they? The most popular screen readers are written for Windows. The screen reader developers don’t have to concern themselves with best practice or Standards – all they have to do is ensure that their product works with the most commonly-used Microsoft software.
A common misconception is that screen readers replace browsers. They don’t – they work on top of browsers. It’s no trivial task to produce software that works cross-browser and across platforms such as Microsoft, Adobe, and Lotus Symphony. Screen reader developers are always following along, having to adapt their product to the whims of the developers whose software they build access to.
Screen reader users are often slow to upgrade as well. The two most popular readers, JAWS and Window-Eyes, cost between US$895 – $1150. A screen reader for mobile devices costs around US$5,000. This is money that has to be spent on top of the usual desktop OS and apps so its not an insignificant amount. This creates a chicken and egg situation since people cannot upgrade their version of Windows OS & apps if they cannot afford to also upgrade their version of screen reading software. Added to this, the fact that screen reader development (at least for JAWS & Window-Eyes) is so closely tied to Windows development it’s easy to see why there is not better support for Standards-based frameworks.
Instead of railing against screen reader development, perhaps we should all be asking why Windows Automation API is so backward (easy answer – its been pretty much stalled since it was first released with Windows 95). This is the API that is used by screen reader developers to interface with Microsoft OS & apps, and with Mozilla’s Firefox. So, if anyone wants to jump up & down they should be jumping on Microsoft. After all, if the source is tainted the downstream river will be too.
@Elpie
Why should screen reader developers fob off the blame onto Microsoft? Any of them could now choose to build on Gecko(Firefox) or Webkit. If they actually got involved in the projects and committed development resources, they could hook right into the renderers themselves and be at nobody’s “whim” – they’d be driving the development of the browser. The sort of Javascript accessibility events that @nzkoz mentioned would be a reality.
> A common misconception is that screen readers replace browsers
Ask 10 web developers if they’ve ever used or installed or seen a screen reader and I think you’ll get 9-10 “no” responses. And not because they don’t care, just that the software isn’t available, published, and promoted to them. Why aren’t the screen reader developers (who, rememember, are charging over 3x as much as MS Office for a *browser addon*) sponsoring Web conferences, getting evangelists to local meetups, running trainings, or having blogs and forums where best-practices are discussed?
My cynical side says that most screen reader software is actually paid for by public health/welfare systems (be it benefits, ACC, Insurance, whatever) so they charge like wounded bulls and couldn’t give a toss.
Realistically, if the community wants better readers they need to get one of the open source projects the resources (ie. hiring top-notch developers, designers & OSS contributors) to both improve their own software as well as develop the browser engines they integrate with. And start working *with* the general web development community.
@Rob There already is a brilliant open source project for screen reading software:
http://www.nvda-project.org/
@Rob
Screen readers aren’t browser addons. There are browser addons that can be used to read browser screens, and some browsers also have voice functionality, but screen readers such as JAWS and Window-Eyes provide the interface for working with Windows and apps such as Microsoft Office, Adobe, Lotus, itunes, etc etc. As well as some browsers (notably IE & Firefox).
>Why should screen reader developers fob off the blame onto Microsoft?
I don’t know that they do. However, they have to base their work on the Windows Automation API, which has its own best practices (http://msdn.microsoft.com/en-us/library/ff625908%28v=vs.85%29.aspx) The open source NVDA reader does too.
I’ve got a measure of sympathy for the developers because I would hate to have to build something that works with apps & browsers that don’t, themselves, follow Standards.
It’s impossible to know the level of involvement screen reader developers have with formulating Web Standards via W3C, but hard to imagine they are not actively working within the W3C working groups. International accessibility standards are set by that group.
@Nicolas – perhaps you could contact the two major screen reader development companies and ask them to comment?
Good idea that, I’ll contact them. Hope they do comment.
On a side note, speaking on behalf of the U.S.A., there has never been a law that says Web pages and applications must work without JavaScript. The law very clearly says in Section 508 §1194.22(l):
So, maybe not so clear, but to paraphrase, any JavaScript used must be useable to screen readers. This means for ten almost ten years in the U.S.A. you can go crazy and use all the JavaScript you want; just do it right so everyone, irregardless of device, can use it.
Hmm, not sure whether markup is allowed here, but I’ll take a stab at it. Koz said:
As I understand it, this is what WAI-ARIA is about: <http://www.w3.org/WAI/intro/aria.php>. No idea about the level of involvement of screenreader programmers…
@Nicolas
I know – probably due in no small part to the cost of the commercial ones. Note that Elpie mentioned only
JAWS and Window-Eyes initially – so I suspect NVDA has a bit of work to do (in marketing if nothing else).
@Elpie
As nearly all computer time is now spent in web browsers, and with the increased adoption of cloud-based apps (eg. Google Docs, Gmail, Office Live, Xero, Facebook…) it’d be a smart move to ignore the desktop or at least develop for the browser separately to provide a better experience. So while I understand there has traditionally been more to a computer than just the browser, that’s diminishing by the day — see Google’s ChromeOS.
> International accessibility standards are set by that group [W3C].
W3C is a pretty dysfunctional organisation, as seen with the XHTML mess, the paralysis on CSS development, lack of developer involement, and numerous other problems. WHATWG were the group of browser-developers who got off their butts and built HTML5 *despite* the W3C. That’s who screen reader devs need to be engaged with for improving the workings of browsers and developing standards.
@Aankhen
We did a huge amount of work in the Dojo toolkit to support accessibility markup (WAI/ARIA) for Javascript-based widgets – including markup hints & high-contrast CSS, but it continues to be hard to develop & maintain precisely because very few developers had access to screen reader software. It needs to be as simple as clicking a button in the Firefox/Chrome dev tools, and having the accessibility equivalents of YSlow to provide a checklist of specific things that web developers can change.