--On Tuesday, July 4, 2006 9:44 PM +0200 emf wrote: > I am determined to provide some JavaScript in the 'standard' > interface, as it will make for enhanced ease-of-use for those sighted > people using a modern browser.
Hi Ethan, It says in 6.3 of WCAG 1.0 to "Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page." [1] Developers can use javascript as long as it degrades gracefully/is for progressive enhancement or if they provide an accessible alternative. If developers want use JavaScript, then they also need to be very sure that what they write is accessible to devices like screen readers, magnification software, keyboard only control, voice-only control, feet-based mice. If developers are willing to support these situations in a responsible manner (thorough testing with real assistive technology users is key), then they can write JavaScript. Current browser-based screenreaders do support javascript, but its practical scripting capabilities are nothing like the same as the browser used on its own (in terms of the interface elements it can use, and whether it can see/read updates to the DOM), yet you can't reliably detect the difference programmatically. Heavyweight DOM scripting, often results in inaccessible content, because events used are mouse-specific and changes to the page are not always announced to users. The result might be perfectly accessible content on a page, but a screen reader user may not know that the new content exists or even if the user knows that it exists he probably doesn't know where to find it on the page. Another difficulty often occurs when developers make things that look like controls on a page, but the information needed by assistive technologies like explicit labels are not present, and the accessibility and user experience for disabled users suffers. It is fine to use javascript, unobtrusively, but, one should be aware of accessibility issues, and, if you don't NEED javascript for something that you can do it server side, often the server-side solution would make more sense. It is far easier to deal with accessible JavaScript by ensuring that the core service being provided is not reliant on scripting. That way, if for some reason the JavaScript is inaccessible, it can be disabled in a browser, and thus the core functionality remains accessible. This is a safety net for developers, as well as visitors. You can guarantee things server side. You can't client side. Maybe 100% of your users use javascript. Maybe 80% use it. Maybe some have figured out how to circumvent the javascript and submit invalid data to the server. Maybe they are not using the latest alternative devices that support Javascript. Maybe they are blind and hate the way many sites use javascript to manipulate the browser client-side making it hard for them to navigate from page to page and so have shut it off. Even people with perfectly modern computers who have 20/20 eyesight, full cognitive and motor skills will turn off Java Support in their browser. The point is that all things being equal, it makes more sense to get the server-side logic working first, because it's more reliable. After that, use Javascript to enhance the usability features for the majority of users, without negatively affecting the accessibility. You should always fall back on a plain HTML or server-side solution for the benefit JavaScript provides. In my opinion accessibility and Javascript boil down to one question: if you take away/disable javascript, will this prevent the user from accessing or retrieving the information? Best regards, Laura [1] http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-scripts Related References: http://www.d.umn.edu/goto/javascript#access http://www.d.umn.edu/goto/javascript#ajaxaccess ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
