[Mailman-Developers] Accessible DOM manipulations

[emf]

Laura Carlson wrote:
> --On Wednesday, July 5, 2006 8:54 PM +0200 emf wrote:
> 
>> 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.
> 
> I'm suggesting that javascript is fine to use for progressive 
> enhancement but not for core functionality. 

Laura, I appreciate your thoughtful and detailed replies. I feel like 
we're kind of talking across each other. I had indicated in a previous 
post that the mailman interface I am building will be fully functional 
without javascript/css; it is the first point on the technical plan at 
http://wiki.list.org/display/DEV/Summer+of+Code .

> - make it work without JavaScript
> - add event handlers or even an AJAX layer to make it work more smoothly

I am not sure what you mean by this. I will be using event handlers, but 
existing screen readers fire event handlers just fine; in fact they do 
everything I want them to do *except* change focus to the modified 
portion of the page.

> - give the user the option to use one interface or the other - as most 
> web apps require login and have a defined user journey this is a lot 
> easier, as visitors are not likely to enter in any of the pages like 
> they do in a web site.

That is what I was suggesting by providing a link to a js-light version 
for screen readers. My logic was something like this:

Because I am otherwise being quite accessible, someone using a screen 
reader *with JavaScript enabled* may not realize that some actions are 
causing other parts of the page to refresh. The javascript code I want 
to use will be perfectly functional or degrade gracefully otherwise, and 
I suspect/am working to ensure that they will still provide usability 
enhancements for those running a javascript interpreter, including said 
screen readers.

One example is keeping extraneous text hidden until it is selected; I 
imagine that someone using a screen reader/portable device would 
appreciate being able to read a "overview" page variant and then being 
able to expand as necessary.

Therefore I am attempting to find a solution to this one problem so that 
I don't have to push screen readers to a JS/css free page unless they 
choose that.

Right this second, it looks like I may be 'safe' if I make sure that 
whatever DOM manipulations I perform only cause 'downstream' (in code 
order) elements to become visible/hidden/filled.

~ethan fremen