Re: [Mailman-Developers] Turning off dynamic JavaScript
--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/
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
On 7/5/06 11:26 AM, "emf" <i@mindlace.net> wrote:
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
Does the industry (I almost wrote "do we") know how big a problem this is in practice? That is, what fraction of users of screen readers and other assistive stuff routinely run with JavaScript active?
Since the assertion here is "screenreaders have trouble with JavaScript" I would expect most screenreader users to have JavaScript turned off.
--John
That assertion is not true, to my knowledge -- and I am a screen reader user. Because it does work with a lot of things, and does offer improved functionality, it is rare to turn Javascript off.
David Andrews
At 01:54 PM 7/5/2006, John W. Baxter wrote:
On 7/5/06 11:26 AM, "emf" <i@mindlace.net> wrote:
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
Does the industry (I almost wrote "do we") know how big a problem this is in practice? That is, what fraction of users of screen readers and other assistive stuff routinely run with JavaScript active?
Since the assertion here is "screenreaders have trouble with JavaScript" I would expect most screenreader users to have JavaScript turned off.
--John
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/dandrews%40visi.co...
Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
__________ NOD32 1.1617 (20060623) Information __________
This message was checked by NOD32 antivirus system. http://www.eset.com
Thank you for the correction, David.
--John
On 7/5/06 5:07 PM, "David Andrews" <dandrews@visi.com> wrote:
That assertion is not true, to my knowledge -- and I am a screen reader user. Because it does work with a lot of things, and does offer improved functionality, it is rare to turn Javascript off.
David Andrews
At 01:54 PM 7/5/2006, John W. Baxter wrote:
On 7/5/06 11:26 AM, "emf" <i@mindlace.net> wrote:
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
Does the industry (I almost wrote "do we") know how big a problem this is in practice? That is, what fraction of users of screen readers and other assistive stuff routinely run with JavaScript active?
Since the assertion here is "screenreaders have trouble with JavaScript" I would expect most screenreader users to have JavaScript turned off.
--John
participants (4)
-
David Andrews -
emf -
John W. Baxter -
Laura Carlson