Mailman 3 July 2006 - Mailman-Developers

Turning off dynamic JavaScript
by David Andrews 05 Jul '06

05 Jul '06

> >There is MSAA, Microsoft Active Accessibility, and a replacement with Vista, I believe, but don't remember what it is called. Don't know if they can be used by style sheets, but inquiry to enable(a)Microsoft.com might be in order. > >Dave > >At 12:45 PM 7/4/2006, you wrote: >>Gentlebeings, >> >>I have read a depressing and recent article suggesting that DOM >>manipulations are invisible to most screen readers [1]. There are some >>workarounds suggested in [2], but for the most part it looks like >>dangerous territory. >> >>What's worse, there seems to be no way to detect screen readers >>reliably. 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. >> >>(I think it would be good for screen readers, too, if there was just >>some way for me to control/hint the "focus" of the screen reader, but at >>the moment there doesn't seem to be. Screen readers don't even seem to >>support an aural/speech stylesheet, much less provide some JavaScript >>object that lets me know I'm in one.) >> >>I found a page (that is eluding me at the moment) detailing a method for >>showing content to screen readers yet hiding it from 'regular' clients. >>I was thinking of adding a "Screen Reader Support On" link to the top of >>all pages that would only show to screen readers; does this seem like a >>good approach? >> >>Note that this would be in *addition* to the ability to get a JS-free >>version of the interface by using a different URL prefix for any user >>agent that doesn't want the JS action. >> >>~ethan

1 0

LoopError vs. Approve.py
by David Lee 05 Jul '06

05 Jul '06

(Mailman 2.1.8) Probably trivial; probably my misunderstanding. But... ... at the end of "Approve.py" is some code to detect multiple passes through a list ("x-beenthere" etc.). But "Approve.py" is about handling passwords, whereas loop-detection has no relation to such authentication issues. Shouldn't this loop detection functionality be in some other place, not "Approve.py"? For instance, perhaps in its own, almost trivial, handler? (I noticed it because I'm writing an experimental sender-authentication scheme as a custom handler modelled on "Approve.py".) BTW: Overall, as I dig into the Mailman code, I'm increasingly impressed with its usually clean modularisation and its flexibility. So this loop-detection (mis-)placement seems out of character. Many thanks for a good product. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : Durham University : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :

2 1

Turning off dynamic JavaScript
by emf 05 Jul '06

05 Jul '06

Gentlebeings, I have read a depressing and recent article suggesting that DOM manipulations are invisible to most screen readers [1]. There are some workarounds suggested in [2], but for the most part it looks like dangerous territory. What's worse, there seems to be no way to detect screen readers reliably. 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. (I think it would be good for screen readers, too, if there was just some way for me to control/hint the "focus" of the screen reader, but at the moment there doesn't seem to be. Screen readers don't even seem to support an aural/speech stylesheet, much less provide some JavaScript object that lets me know I'm in one.) I found a page (that is eluding me at the moment) detailing a method for showing content to screen readers yet hiding it from 'regular' clients. I was thinking of adding a "Screen Reader Support On" link to the top of all pages that would only show to screen readers; does this seem like a good approach? Note that this would be in *addition* to the ability to get a JS-free version of the interface by using a different URL prefix for any user agent that doesn't want the JS action. ~ethan

3 6

SoC: status update
by emf 04 Jul '06

04 Jul '06

http://wiki.list.org/display/DEV/Summer+of+Code Gentlebeings, I have updated the summer of code page above to indicate my current progress and record the synthesis of the opinions I have received so far. Thank you for the excellent feedback you've provided so far; don't be shy about continuing, either here or on the wiki. ~ethan fremen

4 5

Hi! I'll be your intern for the summer :)
by emf 03 Jul '06

03 Jul '06

Hey, all; I'm ethan fremen, and I've been selected for a WebUI Summer of Code project. I'll keep a running log of my progress at http://wiki.list.org/display/DEV/Summer+of+Code My svn branch is https://svn.sourceforge.net/svnroot/mailman/branches/soc2006-webui ; feel free to check it out as the inclination strikes you. I'm especially interested in getting any feedback, either on the wiki or here, about any and all WebUI - or UI in general - ideas in people's heads. While the SoC project is fairly constrained, I want to at least make the future easier. ~ethan fremen

9 35