http://tc.eserver.org/dir/Design/Web-Design/Accessibility/JavaScript A listing of the most recently indexed works about Design and Web Design and Accessibility and JavaScript in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Design/Web-Design/Accessibility/JavaScript http://tc.eserver.org/32519.html http://tc.eserver.org/32519.html Modern user agents with JavaScript enabled will hide content contained within NOSCRIPT, and reveal it when JavaScript is disabled. User agents that do not support JavaScript will display the content within it. User agents with partial/antiquated JavaScript capabilities however interpret the element correctly and do not show the content, but when JavaScript is disabled also do not show the content - it never gets seen. This has an impact on the accessibility of the content. If your writing is targeted at modern, standards-based, compliant, and fully capable JavaScript user agents, employing the NOSCRIPT element is no problem. If the user agents among your audience are unpredictable, however, replacing the NOSCRIPT element with another mechanism becomes significant. This article looks at one such solution. http://tc.eserver.org/32450.html http://tc.eserver.org/32450.html One of the most important things to keep in mind when writing JavaScript for the Web is to make it unobtrusive, since You cannot rely on JavaScript being available.Sadly, there are many developers who do not seem to spend any energy at all on considering how to do that. Instead they choose to blindly forge ahead and assume that everybody who comes visiting will have full support for JavaScript and use a mouse. http://tc.eserver.org/32468.html http://tc.eserver.org/32468.html When a client requests that I duplicate functionality that should be (and is) handled by web browsers, I always try to avoid doing it by explaining why I believe it is better to leave such functionality to the browser. Most of the time I succed, but occasionally I don’t. http://tc.eserver.org/32008.html http://tc.eserver.org/32008.html There are some things in the world of accessibility that appear, on the face of it, to be really wonderful ideas… until you scratch slightly below the service. What may seem feasible when putting together some guidelines on accessibility might not ultimately translate well to a real-world application. Hands up who can remember the last time they felt compelled to use a longdesc attribute? And what about the accesskey attribute? Oh, you have used them you say. OK, let’s back up a little and find out what went wrong here. http://tc.eserver.org/27725.html http://tc.eserver.org/27725.html One of the great advantages of using first letter of the link text as access key is that it can be generated by code. Conventional wisdom states that it should be done server-side. Bad that it is much easier with JavaScript. http://tc.eserver.org/22327.html http://tc.eserver.org/22327.html Developers put a lot of effort into ensuring their sites can be viewed in outdated browsers, but all too often ignore newer browsers, or worse still, a whole range of visitors. Accessibility means access to information for all. Information to all, regardless of the device used to view the document, or abilities of the visitor. You're extremely proud of your latest masterpiece. The choice of colours is striking, the layout fits perfectly on your screen, but how does it look on a Personal Digital Assistant (PDA)? How does it look to a colour-blind visitor? Does it read correctly using assistive technologies, such as screen reading software? Can a visitor navigate the site without the use of a mouse? Is the site usable when JavaScript and images are switched off in the browser?