Mailman 3 July 2006 - Mailman-Developers

Re: [Mailman-Developers] What I did on my summer vacation
by Barry Warsaw 07 Jul '06

07 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 5, 2006, at 5:27 PM, Arne Schwabe wrote: > Barry Warsaw schrieb: >> If you want to get a taste of the things I'm going to check in soon, >> please see: >> >> http://wiki.list.org/x/vg > > That page does not seem to public accessable. It asks me for a > username > / password. I think I've fixed this now. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK3TJHEjvBPtnXfVAQLeHgP8DAXhPxyWikf4U2+79vvNqb0+HfN8q1D+ 4gALanZHsiYfc+yGBB8srDi93U3iHQG17vnRfn0jpDEF8iEybrYiLsXLTOEBrH7D LEnIlL5p8PTfJr7RRu5WhHcsraHe8BFe2QaBgObVyX/PXX88vWXaTVSe66JtUbEq ctjd+Rf7jKc= =e2pj -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] Accessible DOM manipulations
by Laura Carlson 06 Jul '06

06 Jul '06

Ethan wrote: >>> 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. An overview at the top of a page is good usability. This is referred to as inverted pyramid [1]. The inverted pyramid is a type of writing style where conclusions are presented first not last. It begins with a conclusion then moves to the key information followed by background information. Usability studies show that web users want instant gratification. That is why the inverted pyramid style is important. Brad Knowles wrote: >> I would much prefer to do this without JavaScript. Because you can't >> guarantee that you know the way that page would be rendered if you >> send all sorts of "hidden" text that isn't shown until such time as >> someone does something to make it appear, and you can't control what >> kinds of mailicious cross-scripting attacks people may throw at you, >> it's best to simply not send anything that the user cannot currently >> see. Bryan Carbonnell wrote: > I have to agree with Brad on this. > > An option may be to give the site admin the ability to turn the JS > on/off site wide with a mm_cfg.py variable. Default set to off? For the non JS option maybe provide a table of contents or overview at the top of the page with plain old anchors to jump down to detailed information. Personally, I usually also dislike expandable/collapsible content is that relies on user action. But I haven't used Ethan's version yet. Hope it is keyboard friendly. BTW, some degree of accessibility checking for the app can be done simply by using keyboard techniques like tabbing (using no mouse). Blind users often browse web sites by tabbing from heading to heading or link to link. Keyboard techniques, such as tabbing through a page (tabbing through a page usually goes in the same order as a voice browser would read), is a good quick test. By tabbing you can check for any elements that cannot be accessed with the keyboard or that are in an illogical tabbing order. The first exercise I have my Web Accessibility class do is disable their browser. The the idea is to give them an idea as to what it's like to have access to the web restricted. It's goal is to help them to understand what it feels like, and hopefully get them thinking about how these problems can be overcome. These are their instructions: <begin exercise> No, don't unplug the phone cord or Ethernet connection! Instead we are going to selectively disable certain features in your web browser. 1. Go into your preferences in your browser and turn off any and all of the following, if you can. (You may have to poke around a bit in "preferences" or internet settings, and not all browsers will allow you to disable everything. But the general intent is to turn off as much as you can.) - Images - Sound - Java - JavaScript - Style Sheets 2. Take your mouse/track ball/pointing device, unplug it, and throw it out the window. Okay, don't really do that, you might not be able to find it again. But don't use the mouse for the purpose of this exercise. 3. Look up the keyboard shortcuts for your browser in the help files or manual pages. Oops, I should have told you to do that before removing the mouse. Well, just remember that people with disabilities aren't magically born knowing how to run computers either, and if the help system is not accessible, they are in as much trouble as you are now! 4. With your "disabled" browsing system, look at five different web sites and attempt to use them. These should meet the following criteria: - They are sites you've used before. - They are sites where you can actually do something, and that something is of interest to you personally. - They are different types of sites (not all news, not all e-commerce, not all personal pages, etc). Look at a variety of sites. - Try to use these sites as you normally would, and record where you encountered any difficulties. What Was Your Experience Like? 1. What sites did you visit? 2. Were you able to perform your normal tasks? 3. What kind of obstacles, if any, did you encounter in accessing those sites? </end exercise> Best Regards, Laura [1] http://www.d.umn.edu/goto/usability#pyramid ___________________________________________ 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/

2 1

test addresses
by Ian Eiloart 06 Jul '06

06 Jul '06

Hi, I was just discussing Mailman features with our user-support person. One idea we had (not directly related to the web interface) is a test address for every list. The purpose is to test a list setup without spamming everyone. So, if we had a list foo(a)example.com, it would be nice to be able to send an email to foo-test(a)example.com and get back an email saying what would have happened if I'd emailed the list. The result might be a standard bounce, but alternatively, it might say "your email was accepted, and would have been delivered to 16 addresses, including 4 other Mailman lists on this server. 3 other recipients have no-mail set". Where a list member is another Mailman list on the same server, that list should be sent an email to its test address, and so on, recursively. Of course, if the new interface manages to be sufficiently simple and robust, the need for test addresses might be reduced. -- Ian Eiloart IT Services, University of Sussex

1 0

Re: [Mailman-Developers] Turning off dynamic JavaScript
by Laura Carlson 06 Jul '06

06 Jul '06

At 01:54 PM 7/5/2006, John W. Baxter wrote: >> 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 At 01:54 PM 7/5/2006, David Andrews 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 On one of the SXSW 2006 Interactive Panels [1], "Making Web 2.0 Accessible", Javascript and accessibility guru, Derek Featherstone, mentioned that screenreaders running with JavaScript enabled is in fact the norm. Shawn Henry also mention the importance of testing with users. Laura SXSW 2006 Podcasts: [1] http://2006.sxsw.com/coverage/podcasts/ ___________________________________________ 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/

1 0

Re: [Mailman-Developers] Turning off dynamic JavaScript
by Laura Carlson 06 Jul '06

06 Jul '06

--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/

4 4

Re: [Mailman-Developers] Turning off dynamic JavaScript
by Laura Carlson 06 Jul '06

06 Jul '06

--On Thursday, July 06, 2006 1:30 AM +0200 emf wrote: > I had indicated in a > previous post that the mailman interface I am building > will be fully > functional without javascript/css; Excellent, Ethan. Sorry for the confusion. Thanks for all of your hard work. All the Best, Laura ___________________________________________ 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 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/

1 0

Re: [Mailman-Developers] Mailman-Developers Digest, Vol 207, Issue 6
by Laura Carlson 06 Jul '06

06 Jul '06

--On Thursday, July 06, 2006 1:30 AM +0200 emf wrote: > I had indicated in a > previous post that the mailman interface I am building > will be fully > functional without javascript/css; Excellent, Ethan. Sorry for the confusion. Thanks for all of your hard work. All the Best, Laura ___________________________________________ 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/

1 0

Strange words that don't exists in Wikipedia and MonoBook.tpl the output continue to be identical ?
by Ulisse Savi 06 Jul '06

06 Jul '06

I have installed a mirror of Wikipedia in my site here : http://encyclopedia.meta99.com/ But i have some problems. I never used MediaWiki in past and i'm a newbie. Can you help me ? 1) Some pages has strange words that don't exists in Wikipedia- For example the "Cats" page and the "Dogs page" : http://encyclopedia.meta99.com/wiki/Dogs http://encyclopedia.meta99.com/wiki/Cats has strange words in the page : {{#if:| [[{{{diversity_link}}}|Diversity]]}} {{#if:| Binomial name {{{binomial}}}}} {{#if:Felis silvestris catus| Trinomial name Felis silvestris catus(Linnaeus, 1758)}} {{#if:| Type Genus {{{type_genus}}}}} {{#if:| Type Species {{{type_species}}}}} {{#if:| [[image:{{{range_map}}}|200px|]]}} {{#if:| {{{binomial2}}}}} {{#if:| {{{trinomial2}}}}} {{#if:| [[image:{{{range_map2}}}|200px|]]}} {{#if:| {{{binomial3}}}}} {{#if:| {{{trinomial3}}}}} {{#if:| [[image:{{{range_map3}}}|200px|]]}} {{#if:| {{{binomial4}}}}} {{#if:| {{{trinomial4}}}}} {{#if:| [[image:{{{range_map4}}}|200px|]]}} {{#if:| {{{subdivision_ranks}}}}} {{#if:| Why these terrible words ? Exist a setting to disable the words in the output ? 2) I do not understand where is the system to change the output template/skin. I have changed some file in the directory /skins/ . For example the MonoBook.tpl but the output continue to be the same. If i change the directly the MonoBook.tpl file in the directory /skins/ why the output is identical ? A problem of cache ? I need ro change the html output to make it similar to my other pages different from MediaWiki. But i have failed to change the template. Why if i change directly MonoBook.tpl the output continue to be identical ?

1 1

Re: [Mailman-Developers] Turning off dynamic JavaScript
by David Andrews 06 Jul '06

06 Jul '06

> >I believe that the W3C standards require that Javascript and other components fail gracefully, so the point could be made, for things link Lynx and Links that a graceful degrade would also take care of us screen reader users. Anything specific you write for us, while appreciated, is also something that may have to be kept up separately, and thus may not be. > >Dave > >At 01:06 PM 7/4/2006, you wrote: >>Brad Knowles wrote: >> >>> Speaking only for myself, this is not the kind of approach I'd like to see >>> used. I'd prefer to see the web application auto-detect that JavaScript >>> is not available, and therefore to automatically present the appropriate >>> non-JavaScript interface. >> >>I will do this for browsers not employing JavaScript. Screen readers >>employ JavaScript and provide no indication what they do/do not provide >>feedback to the user for. >> >>> Likewise, it should auto-detect that there is a >>> screen reader being used, and present the appropriate screen reader >>> compatible interface. >> >>This is an admirable goal. One "screen reader" in semi-common use is IE >>6 via Jaws; another one is Safari with OS X reading turned on. >> >>They present to me no handle, user-agent or otherwise, indicating >>they're being spoken rather than seen. >> >>> Of course, the manual options should always be there, but if we're forcing >>> the user to manually select a different page in order to get away from the >>> JavaScript stuff, then I think we're doing something wrong. >> >>I agree that it is an Ugly Hack; In this case I think the screen readers >>are misbehaved, but there's not a lot I can do about that. >> >>~ethan fremen >> >>_______________________________________________ >>Mailman-Developers mailing list >>Mailman-Developers(a)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.c… >> >>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

1 0

Fwd: Re: Turning off dynamic JavaScript
by David Andrews 06 Jul '06

06 Jul '06

> >I believe there is a "screen reader present" flag in Windows, don't know any more than that. > >Dave > >At 12:59 PM 7/4/2006, you wrote: >>Ethan wrote: >> >>> 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. >> >>Speaking only for myself, this is not the kind of approach I'd like to see >>used. I'd prefer to see the web application auto-detect that JavaScript >>is not available, and therefore to automatically present the appropriate >>non-JavaScript interface. Likewise, it should auto-detect that there is a >>screen reader being used, and present the appropriate screen reader >>compatible interface. >> >>Of course, the manual options should always be there, but if we're forcing >>the user to manually select a different page in order to get away from the >>JavaScript stuff, then I think we're doing something wrong. >> >>-- >>Brad Knowles, <brad(a)stop.mail-abuse.org> >> >>"Those who would give up essential Liberty, to purchase a little >>temporary Safety, deserve neither Liberty nor Safety." >> >> -- Benjamin Franklin (1706-1790), reply of the Pennsylvania >> Assembly to the Governor, November 11, 1755 >> >> LOPSA member since December 2005. See <http://www.lopsa.org/>. >>_______________________________________________ >>Mailman-Developers mailing list >>Mailman-Developers(a)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.c… >> >>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

1 0