Accessibility does not prevent you from using JavaScript or Flash
A common misconception is that in order to make a website accessible you have to abstain from using JavaScript or Flash. Almost every time I hold a workshop on Web standards and accessibility there is at least one participant who believes that accessibility limits what they can do on the Web by telling them to stay away from anything that isn’t pure HTML.
Misinterpretation of guidelines?
This misconception likely has its roots in people misinterpreting or adhering very strictly to a couple of guidelines in WCAG 1.0:
From Guideline 6. Ensure that pages featuring new technologies transform gracefully.:
Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.
From Guideline 11. Use W3C technologies and guidelines.:
Use W3C technologies (according to specification) and follow accessibility guidelines. Where it is not possible to use a W3C technology, or doing so results in material that does not transform gracefully, provide an alternative version of the content that is accessible.
My interpretation of those two guidelines is not that the use of JavaScript and Flash is disallowed, but that you have to ensure that you use them unobtrusively.
Unobtrusive JavaScript
Even WCAG 1.0 allows the use of JavaScript as long as it is not a requirement for accessing and navigating your site and its content. Use it when it is actually beneficial to the end user and not just because you can. Some rules of thumb:
- Think about what happens when support is missing
- Make sure any user interaction is input device independent (i.e. does not require a mouse)
- Implement JavaScript using progressive enhancement
The Ajax problem
There is a catch though. Using JavaScript to manipulate the contents of a document without reloading the page (with Ajax, for instance) can be confusing to some people, particularly screen reader users. Screen readers have become better at handling Ajax than they used to be, but it is still possible that the user is not informed of a change in the page content due to an Ajax request.
To make JavaScript and Ajax-heavy websites accessible to everybody, you may need to turn to WAI-ARIA:
WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.
The good news is that support for WAI-ARIA is already partly there, and is increasing. All major browsers support or will support it, as do several screen readers.
More articles on WAI-ARIA:
- Introduction to WAI ARIA
- WAI-ARIA Overview
- WAI-ARIA Primer
- Enhancing TabView Accessibility with WAI-ARIA Roles and States
- WAI ARIA Live Regions
Flash and accessibility
As for Flash, well, there are two main things to think about. One is to embed Flash content so that people without Flash (like iPhone/iPod Touch/iPad users) get an alternative, normally in the form of HTML. Again, by using progressive enhancement. The other is that you need to make the actual Flash content as accessible as possible, which means developing your Flash content with accessibility in mind. Information about how to do that can be found on Adobe’s Flash CS4 Professional Accessibility site.
One unfortunate thing with Flash accessibility is that, if I read Adobe’s documentation correctly, Flash content can currently only be made accessible to screen readers running on Windows, so screen reader users are out of luck if they use another operating system, like Mac OS X or Linux. Be aware of that and offer an alternative.
According to the information in Flash Player and Flex Support for IAccessible2 and WAI-ARIA, It looks like that problem is being worked on. However, until Flash is accessible across platforms I am hesitant to call it what WCAG 2.0 refers to as accessibility supported technology.
JavaScript and Flash are not always available
In summary: remember that you simply cannot assume that everybody has support for JavaScript and Flash, that you have to think about what happens when support for either is missing (i.e. use progressive enhancement), and that you need to consider how assistive technologies handle them. Also realise that you do not have to give users without JavaScript or Flash exactly the same experience, but you do need to give them something.
You do not, however, have to avoid JavaScript or Flash as long as you keep accessibility in mind.
- Previous post: If you use the accesskey attribute, specify unique values
- Next post: Be careful with non-ascii characters in URLs