Mailman 3 August 2006 - Mailman-Developers

Forms Acessibility (was Re: Hi! I'll be your intern for the summer :)) summer :)
by Laura Carlson 11 Sep '06

11 Sep '06

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

4 3

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [8005] trunk/mailman/messages/de
by Barry Warsaw 31 Aug '06

31 Aug '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 31, 2006, at 5:17 PM, pheinlein(a)users.sourceforge.net wrote: > Revision: 8005 > http://svn.sourceforge.net/mailman/?rev=8005&view=rev > Author: pheinlein > Date: 2006-08-31 14:17:24 -0700 (Thu, 31 Aug 2006) Peer, don't forget to commit any necessary changes to the Release_2_1- maint branch, if you want to get them into 2.1.9. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRPde13EjvBPtnXfVAQIwDgQApBgULRT9gi/bSuXWSFkBWSwECxkQcmta guEHOs1spkPlm26MHK+ub0ezInN5OzI0hYnWo1Y+gu0rSK6kRHLXrcGMPjhUoVbK YR9ClYNoqJuJINj3SCJAxM45H9sQuSZ/20ToDL4fvxHw7G7Hw2dKmJMUY59fhD1e v4tXzSY3yto= =eQBN -----END PGP SIGNATURE-----

1 0

trunk checkins ok?
by emf 30 Aug '06

30 Aug '06

Gentlebeings, There are things I'd like to change that seem like they'd be best changed on the trunk; the two examples at the moment are list_names() doesn't talk to the config object properly and I found a python implementation of line-wrapping by a number-theory guy that claims to be at least as filled with fu as the emacs version, which I'd like to substitute for wrap(). Is it ok if I make changes on the trunk? ~ethan

1 0

subscription barrier
by Thomas Andrews 27 Aug '06

27 Aug '06

Hi, On the asterisk-dev list, we constantly get questions that should have been sent to asterisk-users. (I'm sure the same has happened here.) I have a suggestion which people might like: If one can be required to answer a question correctly during the subscription proces, unnecessary memberships could be blocked. For example, let's say the admin made the question" "What is the value of x in typedef enum { u,v,x,y,z=9 } e; ?" The average non-C programmer would probably get the message and not bother to subscribe. It would also take a bit of trouble to find out the correct answer if they did try. Of course it would be up to the list admin to enable this feature, and choose the question (and it's answer.) A small useful side-effect is that it might help raise the bar against spammers doing scripted list subscriptions. Regards, Thomas

1 0

Security standards?
by emf 21 Aug '06

21 Aug '06

So as I understand it, mm 2.2 is dropping email reminders of passwords. This has made me think that we'd like more support for 'passwordless' manipulation of the UI. I've come up with a few approaches for this, and I'd like to get feedback as to what would be acceptable. Please keep in mind I'll allow administrators to require more authentication than I outline below. * Use case A: an email is a member of a mailing list but has never logged into the interface. I was thinking it would be ok in this context to allow a user-agent to approach the interface and provide only the email address to be "provisionally authenticated"; they would be allowed to manipulate the member's settings. Once they were done doing so, an email would be sent to the address that required clicking on a confirmation link to make the changes active. * Use case B: a user-agent presents an email that has used the interface previously. If the user-agent presents a visitation cookie that was active during the previous manipulation, the user is provisionally authenticated again, and gets a similar confirmation email. If they did *not* have a matching visitation cookie, or present another this-is-really-me token, they would not be allowed to manipulate the interface until they click a email-verification link. * Use case C: Some other code (an upstream process, OpenId server, etc) provides a username for a user. In this case we accept the user as authenticated, and either use our map of username-> email addresses for purposes of determining membership or accept an email_addresses list from the WSGI environment or from the remote server/other process. If only the username is provided, the user is given the opportunity to indicate which email addressess should be associated with that username; once they have done so, verification emails are sent to said addresses, and post reply/link activation mailman considers those emails to be associated with that username. Does this stuff sound reasonable? ~ethan fremen

1 0

SoC Summary
by emf 21 Aug '06

21 Aug '06

Gentlebeings, A thousand pardons for not delivering a functional UI by the deadline of my SoC project. I have written a summary of my experiences at: http://wiki.list.org/display/DEV/2006/08/20/Summer+of+Code+summary and I assure you that I will continue to work on this project for the foreseeable future, or at least until it makes it into a main-line release. Thank you all for all the help you've been so far; I expect to continue to rely on it as I move closer to something we can actually use. ~ethan fremen

1 0

Timing, events, runners, oh my
by emf 21 Aug '06

21 Aug '06

Gentlebeings, The UI would like to use email for a variety of functions, and it would like some event-based code. I was wondering how much of mailman's existing infrastructure I should use. a.) I would like to allow "email login", where a passwordless user receives an email confirmation link. Whom should I send this as? Should I inject it into mailman's queue? b.) If the UI could be notified when changes occur on the command line or via email, I could do some more intelligent caching. What's the best place to make that happen? c.) I'd like to have events and observers and whatnot; this is down the road a bit, for 'improved' digest support among other things. Would it be inappropriate to have a UIEventsRunner ? ~ethan fremen

2 1

development setup?
by emf 21 Aug '06

21 Aug '06

Gentlebeings, As we enter the end of my SoC internship, I still have a long road to hoe to get to a complete UI for Mailman. That being said, I'm definitely going to continue working with this at least until it makes it into a mainline release, and hopefully longer. Here's my quandary: I need to have several mailman installs 'up and running' - on a "I can talk to the pickles" level, anyway. How do I get such a beast out of svn? INSTALL points me to an 'admin' directory that isn't in svn. I had thought of just adding svn_dir to my pythonpath, but I need a configuration file, and in general I would like my code to be verbatim what is needed to run it against a production server. Thanks, ~ethan

2 1

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [7989] branches/soc2006-webui
by emf 21 Aug '06

21 Aug '06

Sorry for all the property changes. SF.net doesn't seem to let me set repository tags. Any chance someone (barry?) can add .pyc to svn:ignore on the server side? Thanks, ~ethan

2 1

Re: [Mailman-Developers] [Mailman-checkins] SF.net SVN: mailman: [7985] trunk/mailman/messages
by Barry Warsaw 16 Aug '06

16 Aug '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 16, 2006, at 4:04 AM, tkikuchi(a)users.sourceforge.net wrote: > Arabic message for mailman-2.2 ... it wasn't there because I used > cp -r from > mailman-2.1 directory and .svn was also copied. :-( Yep, svn merge is probably the best thing to use to do this kind of cross-branch updates. (BTW, very cool to see Apple's Mail display all those Arabic characters!) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBROMS2XEjvBPtnXfVAQIHrQQAh6nYJGjMiFsSI1P2bCmVtDweblPvgs7V RvliCTqbzrfpDKIsxEM4/R5+BXIfaFiQDUxRbCITd1h4ujRAbmWv2QJclL4xIyo8 bhqT04UWhvVodJu5opmrmFVVMxzD+O72BJEu9MM/1fuW8UKFJpBl7m0SK1URR2JD JpGTSwUl0ss= =CS59 -----END PGP SIGNATURE-----

1 0