Visitors
| 28% | | United States |
| 9.5% | | United Kingdom |
| 5.5% | | Cyprus |
| 3% | | Greece |
| 3% | | Italy |
| 3% | | Japan |
| 2.9% | | Germany |
| 2.6% | | Brazil |
| 2.3% | | Denmark |
| 2.3% | | Turkey |
| Today: | 10 |
| Yesterday: | 7 |
| This Week: | 55 |
| Last Week: | 74 |
| This Month: | 209 |
| Last Month: | 369 |
| Total: | 475617 |
Follow Us on Facebook
Legend
| Javascript as an accessibility concern |
|
|
|
|
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.
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. |



