Laura Carlson wrote: > Heavyweight DOM scripting, often results in inaccessible content,
The main point I'm driving at is *any* dom manipulation - heavy, light, fat-free, or decaf - appears to be invisible to the screen reading user unless I do it "downstream" of the focused text. I'm talking super-simple stuff like element.style.display='none' or "highlighting" text on another part of the page. I don't think it's reasonable to argue that I need to reduce usability for sighted users in order to cater to the (sadly) poor implementation of current screen readers. > 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. For the most part I'm talking about things that aren't doable on the server. Visual feedback is extremely important for assisting sighted readers. Highlighting changes transiently, simplifying pages by hiding elements until they're needed, providing immediate error/warning/information messages, and allowing partial form submission are all things that make for a user experience that is much easier for the sighted user to grasp. I have read from several places that the ability to "play" - i.e. make changes iteratively and receive immediate feedback - encourages interaction and experimentation. Is this "needed"? No. Is it part of a good user interface for the bulk of users? Yes. Many of these tactics - including highlighting (i.e. 're-read this section'), hiding elements (don't read this until such-and-such happens), immediate messages (read this now) and partial form submission would all be helpful to people using screen readers. If I had *any bloody way* to tell a screen reader what to read next, none of what I'm doing would need to be disabled for the screen reader with JavaScript. > 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. Are you suggesting I provide *no* link for the screen-reader-with-javascript client and let them at some point figure out that they're not seeing what's going on and thus turn off javascript? That seems like a worse solution. > 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? The problem I face is not when JavaScript is not active, the problem is when JavaScript *is* active *and* behaves correctly - i.e. performs the dom modification I've told it to - but the browser/screen reader doesn't bother to tell the user. ~ethan fremen _______________________________________________ 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
