Hi,
From a purely legal (in the UK) point of view, do I need my site to work with JS turned off?
I have inherited a site that uses complex JS to make the content appear as well as use core functionality so the site is useless without JS but that to me would mean it isn’t meeting the minimum standards on the DDA but I can’t find anywhere that specifically states that you must provide a working non-JS version (other than comments about allowing every user access to your site).
Thank, Des
Yes and no. It depends.
I don’t know much specifically about DDA, but I’m pretty sure it’s very similar to ADA (American’s with Disabilities Act).
You need a site that works with disability helping software (namely screen readers). Most screen readers don’t handle JS well. If they do, what usually happens is they’ll start rereading the whole page whenever something changes (which can get very awkward). While you usually don’t have to provide 100% equal experience, there needs to be something for them to be compliant.
At a higher level, it’s always a good idea to have it working without Javascript, even before you worry about disabled users. Google, for example, doesn’t like Javascript pages very much either, so you’re doing yourself a disservice.
Not that it matters very much to this discussion, but the DDA was superceded in 2010 by the all-encompassing Equalities Act. Neither act made any specific mention of expected standards, unlike the old Section 508 in America. So interpretation is still required in order to ascertain what might constitute discrimination or compliance, so no change there.
My interpretation of “accessible” is strict. If I cannot access content (especially core content) or navigate without support for CSS, JS, or images, then it is not accessible. My preferred day-to-day browser does not support JS and I avoid using the mouse unless necessary.
Many developers will, when deciding what to do about this or justifying a choice, guesstimate whether JS is OK (which depends largely on the behaviour of the JS), conclude that it is, and forget about the two related principles of graceful degradation and progressive enhancement. It’s often more complex than deciding whether to use something or not.
I wish that I had a pound for every website out there that has some unnecessary JS because a designer felt an obligation to use it, as if there is an unwritten rule that states that all modern websites must use JS for something; or some JS that could easily have remained highly accessible but isn’t because no-one bothered.
If it is core functionality like navigation or a feedback form or login input (that requires JS or will do nothing/won’t work) and it doesn’t have a fall-back or alternative then it would probably fail. Because it wouldn’t allow the user to perform an important function that could easily be provided without the use of JS since you’d be creating a barrier to the user under the ‘reasonable adjustments’ category.
but I can’t find anywhere that specifically states that you must provide a working non-JS version
But somewhere you got the idea that JS is prohibitive. This most likely comes from the first version of the WCAG (Web Content Accessibility Guides), where they did say something along the lines of, if you use scripts, they must either be only for pretty extras, or you must somewhere else have a non-scripted equivalent.
WCAG version 2 however sorta undid that, because WCAG2 focusses more on “does it work?” without mentioning specific technologies so much (sometimes it does, like Flash…).
WCAG2 states that users need to be able to do whatever it is they came to do on your site. It needs to function, whether the user agent (browsers are user agents; screen readers and things like Dragon Naturally Speaking are considered user agents that run on top of browsers) loads CSS or not, images or not, Javascript or not. That functionality may not rely on things like colour or position on the page. That the input device not be restricted to mouse or on-screen cursor (I’m not sure how touch falls in there, but there are separate W3C mobile guidelines that deal with touch).
In general, if your site MUST be DDA compliant (taking into account what Mat30 said), I would say:
Do not rely on Javascript to get content onto the page. If you are calling information from a script on the server using AJAX, have built-in a regular submit button and let users who DO have Javascript get the AJAX while everyone else does the usual HTTP POST or GET request. This technique is known as HIJAX. It’s probably difficult to tack-on, but is reasonably easy to build-in.
Screen reader users tend to have Javascript on by default, for the same reason everyone else does too: it’s just already on in the browser, and unless the screen reader user him/herself is a geek, they likely don’t really know what JS even is any better than your mom.
Screen readers can do okay with Javascript. Make sure any onmouseover events are coupled with onfocus events. Make sure any element who is supposed to react to user events is naturally focusable (meaning, don’t throw an onClick method on a div, who isn’t naturally focusable… use either an anchor, or a form control. Don’t use an <i>checkbox</i> disguised as a checkbox with a role of “checkbox” on it and an onClick method. Instead, use a real checkbox and use other tricks to style it goofy as needed).
Most screen readers don’t handle JS well. If they do, what usually happens is they’ll start rereading the whole page whenever something changes (which can get very awkward).
They do pretty well today, but the issue you bring up is still sometimes a problem.
I’ve seen an example of a site that only had Javascript running some kind of calendar widget in a sidebar… that somehow made the Orca (linux) screen reader keep acting as if the page had refreshed. The user disabled Javascript and suddenly the problem was gone (but then other things didn’t work, of course).
If you are putting a method on an anchor, be careful what that anchor’s href attribute points to. When it’s just “#”, that tells most browsers “this page” and clicking on it without Javascript intervention means a refresh.
Take a good look at the new ARIA roles and attributes that are getting more and more support in browsers and screen readers.
Start with ARIA landmarks, they are the easiest to get started with in my opinion.
Then check out how ARIA is used in things like widgets: Here’s an awesome example of a typical “slider” used in forms by Filiament Group. Paciello Group (first link) has an ARIA tutorial with things like sliders and whatnot.
Marco Zehe’s English blog also has some how-to’s that helped me see how to use ARIA in code. The HTML code itself isn’t very good, but just focus on how the ARIA stuff is used. (Look for “Easy ARIA Tip #something” [url=http://www.marcozehe.de/category/aria/]here).
Live regions will probably be the hardest part to deal with, partially because the authors are still figuring stuff out themselves, but this helps screen reader users deal with things moving and changing on the page dynamically (without full page refreshes).
ARIA is pretty much ONLY for screen readers, but they’re also usually the hardest group to accomodate, and ARIA helps.
Lastly I guess if you’ve got stuff appearing on the page without page refreshes, another group to be aware of would be those using screen magnifyers. These may or may not be used in conjunction with a screen reader. Basically the user sees a part of your page… about the size of a credit card. So if the user is looking at a part of your page where they must click things or select things, if something changes on the other side of the page, these people would not necessarily notice or know. Making sure changes happen close to where the user event occurs will help many people… and when that’s not possible, have at the pace where the event occurs (since that’s where user attention is at the moment) an alert to the user that another area is now changed (“Your shopping cart has been updated!”) somehow.
TL;DR:
You’re asking about legal compliance. Get someone familiar with your country’s laws to look over the site first. If this site was built JS-first and that is the core functionality, then if it does NOT meet your country’s laws or guidelines, it very likely will need to be rebuilt since that’s almost always easier than fixing. Accessibility is easier built-in than bolted-on. So get someone who can make sure if you do this sort of large investment that you do it right. Do not rely on automated testing tools (they can help, sure, but no more).
And this might sound terrible, and of course goes against my moral principles etc, but since rewriting a site is expensive, you may want to look at the cost of any lawsuits or fines vs the cost of redoing the site before making your decision. Obviously it would rock if the site just freakin worked for everyone, but…
I started to reply yesterday, but had to leave. I found that the DDA says it has to follow the WCAG, but I couldn’t find if it is version 1 or 2. Section 508 in the US basically follows WCAG 1. WCAG 1.1.1 (WCAG v1 Priority 1.1) says
Provide a text equivalent for every non-text element (e.g., via “alt”, “longdesc”, or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
Javascript falls under this. In Section 508 it gets transcribed to
and
I agree wholeheartly about this.
Moving focus programmically on updates like this will automatically miove the magnifier to that area, so if saying something changed is mission-critical, doing this is a good idea. Of course in moderation.
Moving focus programmically on updates like this will automatically miove the magnifier to that area,
Though, I’m also leery of yanking the user around the page unless it’s the best/only reasonable way to do things, since large complicated pages are easy to get lost in. When I last tried MAGic, if I hadn’t had JAWS I would have had to give up. I had no idea where I was. Assuming regular users are better at it than I tho.
But I meant, if I click on a button somewhere, if a message appeared by that button giving me feedback, I’ll know to check the area (may be offscreen) that changed.
At that time the old DDA (2005) basically followed WCAG 1.0 because it was the latest recommendation and JS is not a W3C technology. http://coi.gov.uk/guidance.php?page=131
Thanks for all the responses.
For clarity, I’m not looking for reasoning on whether I should have a fallback non-JS version, I fully understand that part and fully agree. What I’m try to find is definitive proof on whether the site will be illegal without it.
If I’d built the site this wouldn’t be an issue as it would have been done properly in the first place but its an inherited site (ie someone else built it and now my team has to look after it), I’m trying to confirm when I take control of it can someone sue my company for not being able to use the site.
Theoretically yes if it would be illegal it prevented the user from performing a task within the scope of reasonable adjustments.
Though in either case you as the website owner would have to refuse to adapt the website or not make accessible improvements if challenged by a person with disabilities, etc. Before further steps were taken…
The amount of cases in the UK you can count on one hand that have come to light in the press. Probably the Olympics 2012 strobe effect promo advert (2007, causing epilepsy seizures) was the most famous. Or perhaps those airlines I forget which that had adverts for money off that were image only got a slapping.
As I understand it, the bottom line is that people must have equal access to services, regardless of disability.
Rather than have a fall-back non-JS version of the site, you only need ensure it is still usable with JS disabled.
My local transport company revamped their web site and had three different JavaScript sliders, all running at once and with no way to pause them. (They have since added pause options.) One of these was showing important “service disruption” information. As I can’t use a site with moving images, I had no option but to keep JavaScript disabled (which is my usual policy). However, I still have full access to all information and the page is still highly usable, although the layout is a little less tidy than with JavaScript enabled. I’m perfectly happy and the company only has one version of the site to worry about.
For clarity, I’m not looking for reasoning on whether I should have a fallback non-JS version, I fully understand that part and fully agree. What I’m try to find is definitive proof on whether the site will be illegal without it.
Today, it’s not a question of “is JS illegal here” but absolutely “is your site accessible the way it is now?”. You need to find someone not only fully aware of the law but who can also view and test your site to see if it still, despite being JS-heavy, fits the criteria of “accessible” as the law defines. And where it doesn’t, so that you know what the (possible) problems are and only then can you decide if you can fix it, or if the site needs a total rebuild, or what.
There are those in this thread who know some things about DDA, but the ultimate answer will be specific to someone testing your site.
So what about Google map? – are developers who implement Google Maps incompetent because it is completely inaccessible.
What I’m try to find is definitive proof on whether the site will be illegal without it.
I’ve hinted at my answer to that, and although some developers might think it a strict interpretation of real-world requirements, I stick by it from personal experience. I wish that we (UK developers) had something clearer to follow than the vagaries of the Equalities Act, but we just have to err on the side of caution, interpret the WCAG 2, and keep all users in mind.
So, yes. This and any website should have as much non-JS functionality as possible (allowing for certain services that can only be done with scripting, but that’s the point at which my definition of a website ends and the web app begins) by employing progressive enhancement from the start. Scripting need not break fundamental web accessibility if it is done right. But if does, surely that is breaking equality law.
Those two words belong together too often.
They do offer a fallback, which is just a static map with hyperlinks to pan and zoom. Some mobile phones automatically get sent to this version of the site.
Which is PRECISELY how scripting should be handled – it should be used to ENHANCE functionality, not supplant it. While certainly there are some things that only scripting can do, that’s no reason to crap all over a normal website when trying to deliver ordinary plain-Jane content… which is what 90%+ of the javascript in circulation, PARTICULARLY the code based on those idiotic ‘frameworks’ like jQuery or MooTools, seem to be all about.
There are three basic categories for scripts on a site these days – goofy animated crap that makes the page harder to use, “gee ain’t it neat” effects that make the content painful to get at, and useful enhancement of existing functionality… and there are few if any good examples of the last of those out there.
…PARTICULARLY the code based on those idiotic ‘frameworks’ like jQuery or MooTools…
Many developers suffer palpitations and shortness of breath if they have not used jQuery in some utterly pointless way in the last 24 hours. It’s a very common medical condition. 
The application of this law to websites is still largely untested, however according to section 20(6):
I think that’s as close as you’re going to get to an answer. 
[ot]
Have you seen the dotdesk rant? It’s brilliant, and so is the fake SO screenshot too: http://www.doxdesk.com/updates/2009.html#u20091116-jquery[/ot]