Mailman-Developers July 2006

mailman-developers@python.org

19 participants
35 discussions

Forms Acessibility (was Re: Hi! I'll be your intern for the summer :)) summer :)

by Laura Carlson

--On Thursday, June 22, 2006 4:15 AM +0200 emf wrote: > Thanks very much for your feedback, Laura! I am something of a > standards fanatic; all the pages I've re-written so far have made > heavy use of label (although I use the implicit label where > possible), fieldset, legend, thead & tbody and the title attribute > to provide as much support for assistive technologies and > alternative renderings as I can. Wonderful news to hear that you support accessibility and web standards, Ethan. Yes, fieldset, legend, thead, tbody and the title attributes are very important for structural markup. > Once I have a clear idea what form elements will be where, I am also > going to add tabindex and accesskey attributes to the form elements. I would like to mention a few things regarding implicit labels, accesskeys, and tabindex. LABELS The W3C identifies two different types of labels: implicit and explicit [1]. Basically, the difference is that implicit labels are an older, (deprecated in WCAG 2.0) technique that wrap around their target field elements; explicit labels use the for attribute to indicate which form element they describe (that value of the for attribute is the id of the element it describes. I would caution against using implicit labels. Explicit association is preferable. WCAG 1.0 12.4 advises web developers to "Associate labels explicitly with their controls."[2] It also says in section 508: "Experience has shown that implicit labeling should be avoided for two reasons. First, implicit labeling is not reliably supported by many screen readers and, in particular, does not work well if explicit labels are simultaneously used anywhere on the same web page. Often, the output can be wildly inaccurate and confusing. Second, if any text separates a label from its associated form element, an implicit label becomes impractical and confusing because the label itself is no longer easily identified with the form element.[3]" For an illustration of this visit Roger Hudson's Web Essential 05 Association Examples [4]. If you use explicit labels, you're specifically providing information about each form element. Each form control should have its own LABEL. Add the FOR attribute to tie the LABEL to the form control's ID attribute. ACCESSKEYS Something to be aware of is that the current opinion of many accessibility experts is that accesskeys mostly work against accessibility. Because of the many conflicts, defining accesskeys seems to be a waste of time unless you are designing for a controlled environment such as an intranet. Joe Clark suggests that there are at least 36 characters that can be used for accesskey attributes [5]. However, John Foliot's and Derek Featherstone's [6] [7] unofficial survey/research concluded that there really are no useful access keys not already reserved by some application or other. When you take internationalization issues into account, it becomes pretty much of a hopeless cause. Part of this is that browsers by default don't indicate the accesskey assignments or tabbing order. No one argues with the idea behind accesskey, and it's usefulness. But given the current state of affairs, and the potential for confusion and/or conflict with various adaptive technologies, they have issues. So... Based on the existing issues I usually advise developers to not use accesskeys. However, best practice is that IF accesskeys are used: - Always supply a legend that defines the accesskeys. - Make sure this legend is on or available from every page on the site...perhaps in an accessibility statement. - Supply title attributes on any accesskeys used. - Keep the number of accesskeys to a minimum. - Test to make sure that accesskeys help usability more than they hinder accessibility. TABINDEX If you have a logical page design tabindex isn't usually necessary. By default, with no tabindex attributes present, the browser will tab through elements in the order in which they appear in the source code. Using just one tabindex for the first field like you did for the exercise isn't bad, but just having a sensible natural order to start with, meets WCAG requirements for HTML documents. If the tabindex attribute is not assigned to all fields, JAWS first moves through the items with a tabindex assigned, then moves through the other form fields and links in the order they appear on the page. You can usually lighten your HTML and usually forego tabindex. But if there is something very weird with link or form presentation so they don't function in a sensible order it can be helpful to have a tabindex. In any event I suggest it may be better to avoid having a weird ordering in HTML. If tabbing needed to come in anything but their natural order, I think I would probably regard my document structure as flawed and would rework it. When a form is well structure, and still reflects that structure when styles are turn off, the tab flow is often the same with or without coding tabindex. If that is the case, don't bother coding it when tab order is simple and clear. The W3C checkpoint [8] that actually refers to tabindex essentially says specify tab order via the tabindex attribute or ensure a logical page design. Often people seem to forget about the logical tab order that almost always exists and is reasonable. In fact, I'd say you have to work pretty hard to actually need to go outside the logical order that naturally exists within standards-based sites. Further, when people do implement tabindex, sometimes it breaks expected interaction because the order is either non-intuitive or it is completely out of line with where you think you are headed next. In my experience tabindex just makes forms more annoying to use. In most cases I'd rather web developers just let the browser get on with working out the tab order and stop trying to guess where the user wants to tab to. Ethan, thanks for all of your hard work. All the best, Laura [1] http://www.w3.org/TR/2005/WD-WCAG20-HTML-TECHS-20050630/#label [2] http://www.w3.org/TR/WCAG10-TECHS/#tech-associate-labels [3] http://www.access-board.gov/sec508/guide/1194.22.htm#(n) [4] http://we05.com/resources/roger-hudson/association_examples.html [5] http://joeclark.org/book/sashay/serialization/Chapter08.html#p-4125 [6] http://www.wats.ca/show.php?contentid=43 [7] http://www.wats.ca/show.php?contentid=32 [8] http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#tech-tab-order ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN 55812-3009 http://www.d.umn.edu/goto/webdesign/

14 years, 10 months

by James Ralston

Consider the following situation: 1. Some users at our site are subscribed to external Mailman-managed mailing lists that perform automatic bounce processing. 2. Because the list owners are either unwilling are unable to protect the lists from spam, the lists receive a fair amount of spam. 3. Our MX servers are configured to reject outright incoming messages that are obviously spam. Most of you can see the impending train wreck already, but for completeness' sake, here's the problem: 1. Mailman distributes obvious spam to the list. 2. We detect the spam and reject it during the SMTP dialog with a 550 reply code (5.7.0 extended status code). 3. Mailman receives a DSN message because we bounced the message. 4. Mailman assumes that the bounce is due to the recipient's address being invalid, and disables the subscription. 5. Much wailing and gnashing of teeth ensues. >From looking at Bouncers/DSN.py, although Mailman takes the time to pick apart each message/delivery-status subpart and extract the "action" field, it blissfully ignores the "status" field, which must be present and must contain the extended status code which generated the DSN. The subject sub-code of the extended status code classifies the status as follows: X.0.XXX Other or Undefined Status X.1.XXX Addressing Status X.2.XXX Mailbox Status X.3.XXX Mail System Status X.4.XXX Network and Routing Status X.5.XXX Mail Delivery Protocol Status X.6.XXX Message Content or Media Status X.7.XXX Security or Policy Status Of these, some subject sub-codes (e.g.: X.2.XXX) pertain directly to the validity of the destination address. But some do *not* pertain to the destination address: for example, X.6.XXX clearly means that the *content* of the message (not the source or destination address) caused the DSN. Regardless, Mailman ignores all of the status field information: if the action is "failed", Mailman counts it as a bounce, and that's that. IMHO, this is an error. I propose modifying Bouncers/DSN.py as follows: 1. Mailman tries to extract the status field from message/delivery-status subpart. 2. If Mailman cannot extract the status field, it operates solely on the action field. 2. If Mailman can extract the status field, and the subject sub-code is X.6.XXX or X.7.XXX, Mailman assumes that the DSN was generated by the fluke content of a specific message, and ignores the DSN. I admit that this algorithm isn't perfect. But I think it's better than what Mailman does currently, which is to ignore the status field entirely. Thoughts? Arguments? James

14 years, 11 months

Re: [Mailman-Developers] The Philosophy of Web Use.

by Laura Carlson

Ethan wrote: > Can you do me a favor and let me know how these examples work > for you? > > http://tool-man.org/examples/sorting.html Works great for able bodied mouse users. But how are people with mobility impairments like low dexterity (unable to use a pointing device like a mouse and instead must use keyboard or switch) able to use it? It doesn't seem to work via keyboard. WCAG Guideline 9. Design for device-independence: "Use features that enable activation of page elements via a variety of input devices. Device-independent access means that the user may interact with the user agent or document with a preferred input (or output) device -- mouse, keyboard, voice, head wand, or other. If, for example, a form control can only be activated with a mouse or other pointing device, someone who is using the page without sight, with voice input, or with a keyboard or who is using some other non-pointing input device will not be able to use the form." [1] Best Regards, Laura [1] http://www.w3.org/TR/WCAG10/#gl-device-independence ___________________________________________ 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/

14 years, 12 months

Re: [Mailman-Developers] Turning off dynamic JavaScript

by Laura Carlson

--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. Javascript should be used to enhance the usability, _if_ it doesn't negatively affect accessibility. A Javascript dependent app is just not accessible. But like it says in 6.3 of WCAG 1.0, if it is not possible to make pages accessible when scripts, applets, or other programmatic objects are turned off or not supported, the fallback is to provide equivalent information on an alternative accessible page. SitePoint's JavaScript Anthology chapter on JavaScript and accessibility that features a lot of test results with different screen readers, but I don't see that as much more use than a DHTML script that was tested in 1999 on Netscape and IE - by making your DHTML accessibility dependent on the user agent - regardless of screen reader or browser - you make it easily outdated. The problem is not only users of assistive technology, it is about availability as well. What if I work in a high security environment where my employer turns off JavaScript or filters it out via a proxy by default? What if I am somewhere without internet access on the ground and want to use my mobile or satellite phone to reach an app? In both Section 508 and WCAG 1.0 a separate text only version is not considered an accessible solution. Basically the requirements state that the author has determined that the primary site CANNOT be made accessible, and the text only site provides some kind of second class access to the content. Creating a text-only version of a web site should be done when there is no other way to make the content accessible, or when it offers significant advantages over the main version. And then the text-only version needs to provide the functionality equivalent to that of the main version. Some thing to consider with separate versions: Text-only versions are rarely totally equivalent in content to the "real" version. They often do not fully convey content and its context. They effectively segregate the audience they are targeted at. When there is a text-only version available, developers sometimes do not make the "real" version accessible. >From a maintenance view, creating a text-only page for every Web page is twice the work. Invariably, the text version is going to be out of sync with regular content. This then creates an accuracy problem. The accessible version is often hidden behind its inaccessible counterpart. People needing to use the accessible version of the website still need to be able to deal with the inaccessible one. They have to search through an inaccessible page to find the link to the text-only page. This problem could be reduced by ensuring that the "skip to accessible version" link is the first piece of information on a page. Ethan, have you considered making the main site not rely on JavaScript for functionality and having a link to a JavaScript enhanced version, so the accessible version is not hidden behind its inaccessible counterpart?...Or you might want to consider this approach: - make it work without JavaScript - add event handlers or even an AJAX layer to make it work more smoothly - 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. Best regards, 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/

14 years, 12 months

Bounces, Pickles, Coding Styles Oh My

by emf

Calloo Callay! So I'm spelunking about. I don't like the way the current UI doesn't tell the admin about bounciness of users, so I was looking to see what is known. After some non-trivial meditation on BounceRunner.py I think I know the difference between verp_probe and verp_bounce, despite not quite knowing what VERP means, the comment string for the two functions being identical, and the bodies of them being identical as well save a tiny little memory stanza. Would someone be willing to change verp_probe's docstring to more clearly illustrate its function? Also, I'm finding a fair number of files that aren't pep8/styleguide.txt happy. anyone care if I at least correct tab/space mixing, and/or make it otherwise style-guide correct? As much as I appreciate the principles of code-hiding, it's been a bit of a pain to use the interpreter to figure out what is stored in a pickle. Since I can't read the pickle file with my eyes, perhaps a little less obscuration might be OK? Like, list.members['i(a)mindlace.net'] doesn't work. In fact, I can't find any function that gives me a member in its entirety. It would help me if I could just see the underlying data; any suggestions on how? ~ethan

14 years, 12 months

Re: [Mailman-Developers] [Python-Dev] Py2.5 release schedule

by Barry Warsaw

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Re: Python 2.5 compatibility On Jul 28, 2006, at 8:57 AM, Barry Warsaw wrote: > +1. It would give me more type to port and test a few of my > applications to the new version. > > I'm still working on Mailman but the most painful thing so far has > been the conversion of exceptions to new-style classes, and even > that wasn't /too/ painful. I believe I've finished porting Mailman to Python 2.5. None of the issues were insurmountable, but here they are FTR: 1) Exceptions are new-style classes but Mailman was doing one specific test against the type of an object to see if it needed to be instantiated. This test was written as: if isinstance(obj, ClassType) which fails in Python 2.5. I actually rewrote it like so: if isinstance(obj, ClassType) or isinstance(obj, type(type)) in MM2.1 because it has to be backward compatible to Python 2.1. 2) There was one place where I was commonly raising a string and that generates deprecation warnings, so I changed that to a class. There are a few other legacy string exceptions defined in the code, but they are rarely used and should all get rewritten as well. 3) Cookie.py's repr changed so that trailing semicolons are no longer output on the end of text lines. I understand this change was made so that Python cookies were more RFC compliant, but it broke some homegrown cookie text splitting we were doing. I changed this code to split on lines first. All in all, not too bad although the Cookie.py change took a while to track down! - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRM0MDnEjvBPtnXfVAQJ9ZAP/VdtM79SXgx7s/X0aEIu4HDZva7TkYyi6 dRzlgAtEV5BN1yYn+vzw8PBCtdy+9N3yYtv/zqdQP54mZDjsaGaNw6MiS0jsETRy 248hj3otL/00WTrKWh8/OvDlLW8KUNQI4MWBOMKJ/TqYW5Es4fJGEMtbO/xqGXXD /wgWmmLOOAE= =Mu8m -----END PGP SIGNATURE-----

14 years, 12 months

Password reminders "going away" in 2.2

by emf

So does this mean I don't have to implement that bit of preferences UI? ~ethan

15 years

Decorators in MailList.py ....

by emf

Hallo! I am noticing there are decorators in MailList.py... does that mean I can use them? ~ethan

15 years

Anyone have a pickle / mbox to spare?

by emf

Gentlebeings, It would sincerely help me if I could test my UI against actual mailman pickles to make sure I can deal with vagaries of configuration, etc. I would use them on a local machine; for collaboration purposes the data would be as available to the public as your current installation, though it wouldn't accept or send mail. I'd be happy to provide a script to randomize all users passwords before you sent it over, but would prefer that the email addresses stay valid. I don't need generated archive files; just list pickles and mbox files, if you've been generating them. If you have at least one 'private' list's that you'd be willing to share, that would be ideal, though I have some lying about. I can accept attachments of arbitrary size, or arrange another method of transit. Thanks for your help, ~ethan fremen http://wiki.list.org/display/DEV/Summer+of+Code

15 years

effects of not rewriting the Sender header

by James Ralston

As a follow-up to the Sender header discussion back on 2006-04/05... On 2006-06-17, we disabled Sender header rewriting at our site, using the attached patch. Since then, we've received no complaints whatsoever from our users about bounces not being caught, and the complaints about recipients using Outlook seeing "bounce" addresses have ceased. Based on our experiences, I'd strongly recommend that this patch be applied to the official Mailman distribution. Regards, James

15 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers July 2006