问题
As a web developer, a number of the projects I work on fall under government umbrellas and hence are subject to 508 Accessibility laws, and sometimes W3C accessibility guidelines. To what extent can JavaScript be used while still meeting these requirements?
Along these lines, to what extent is JavaScript, specifically AJAX and using packages like jQuery to do things such as display modal dialogues, popups, etc. supported by modern accessibility software such as JAWS, Orca, etc? In the past, the rule went something like "If it won't work in Lynx, it won't work for a screen reader." Is this still true, or has there been more progress in these areas?
EDIT: The consensus seems to be that javascript is fine as long as there are non-javascript fallbacks, however it still seems uncertain about the support for AJAX in screen reader software. If anyone has specific experience with this, that would be most helpful.
回答1:
If accessibility is your primary concern, always start a website using standards-compliant (pick a Document Type Definition and stick to it) HTML. If it's a web application (form submissions, etc), make sure the forms will work using just HTTP GET and POST. Once you have a complete website/application you can add bits of CSS and JavaScript as long as the site still functions, with either or both off.
The most important concept here is Progressive Enhancement. You're adding additional bells and whistles using CSS/JavaScript, but your web site/application will function perfectly well without either.
A great tool for testing 508, WAI, CSS off, JavaScript off try using the Web Developer plugin for Firefox.
回答2:
I think the answer is really in how you architect things. JQuery has the capability to be unobtrusive and therefore accessible. The trick is to have redundancy around your AJAX calls so browsers without JavaScript can still utilize your service. In other words, wherever you have JavaScript responses, dialogs, etc you need to have a degraded equivalent.
If you have accessibility in mind and you're properly testing for both use cases (JavaScript vs. Non-JavaScript) you should be able to write applications that cater to both audiences.
Example ($(document).ready call omitted for clarity and brevity:
<script>
$("#hello").click(function(){
alert("Hi");
});
</script>
<a href="/say_hello.htm" id="hello">Say Hello</a>
A trivial example but basically this will only evaluate the click JavaScript event if JavaScript is supported. Otherwise, it will perform like a normal link and go to say_hello.htm - your job as the developer is to make sure that both outcomes are handled for appropriately.
Hope that helps!
回答3:
Progressive enhancement is certainly one route but unobtrusiveness is not the be all and end all of JavaScript accessibility as screen readers tend to use browsers as a basis for their work. Since those browsers support JavaScript, scripts on your page will still run. This is a particular problem with AJAX as clicking on one part of the page could change another part of the page that the screen reader isn't aware of.
As AJAX matures, however, methods of making it accessible are emerging. Look into the WAI-ARIA for modern methods of making AJAX accessible, and Google's AxsJAX for a good way of implementing it.
回答4:
See
- http://juicystudio.com/article/making-ajax-work-with-screen-readers.php
- http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php
- http://www.paciellogroup.com/blog/?p=15
- http://www-03.ibm.com/able/resources/ajaxaccessibility.html
You might also take a look at FlashAid, although it is far from a perfect solution. (But, if you used progressive enhancement and only used AJAX when Flash was present and the user wasn't using the accessibility API, you might have a reasonable solution... for Windows.)
In the long run WAI-ARIA is the solution. It is somewhat supported in JAWS 10 (beta) and Firevox, but it certainly isn't sufficient for all of today's users.
回答5:
JQuery has the capability to be unobtrusive and therefore accessible. The trick is to have redundancy around your AJAX calls so browsers without JavaScript can still utilize your service. In other words, wherever you have JavaScript responses, dialogs, etc you need to have a degraded equivalent.
One way to do this to reuse your code, is to have your "simple" page calling a "function" (or whatever you use for server side logic) that can be called by itself, returning JSON or XML.
For example: /static/myform.asp (in the server side, 'includes' the same logic as /ajax/myform.asp) that way you'd be using asp as django's templates.
Of course, with a full featured bell and whistles framework, you could make this a lot easier (think of having an html and an xml 'template' for the same view in django), but the same idea applyes.
Having done this, iterating over all anchors on document ready using jQuery and adding onclick events using the anchor's own link, remplacing /static/ajax/ could make your life easier.
Can anyone think of reasons for this to be too much of a burden? Would like to know if there is any serious flaw on this 'design idea'.
回答6:
I think the accepted answer, while fine for its time, is now out of date. (Literally a decade old at time of writing this answer. WCAG 2.1 was finalized a few weeks ago...)
The W3C WAI-Authoring Design Patterns Practices document includes various examples of common widgets which require javaScript in order to communicate the right semantics, states and roles to assistive technologies.
AJAX can be made accessible, as long as you are careful to give screenreaders relevant semantic clues about what the in-page-update will be before the user activates it. You may also need to notify the screenreader about what actually changed afterwards, e.g. an aria-live region might announce "20 new items have been loaded" or whatever. This is achieved with javaScript.
If your accessibility knowledge stops at 'progressive enhancement', and you see the accepted answer above as rationale for that position, then you may well be in need of an update. Things are moving fast these days.
来源：https://stackoverflow.com/questions/266777/javascript-and-accessibility