[Mailman-Developers] Turning off dynamic JavaScript

[emf]

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