[Mailman-Developers] UI for Mailman 3.0 update

[Geoff Shang]

On Fri, 4 Jun 2010, Anna Granudd wrote:

> there are some mock-ups on the wiki (see
> http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you
> could help with ideas for a nice design and layout!

As a blind person, I'm not able to comment on these as these are images.

I can understand the desire for an overhall of the Mailman UI, but I think 
it's worth saying that for the most part, the 2.x UI works well for people 
using screen reader technology.  The only area which provides some 
challenges is the membership management screen, as it can be difficult to 
associate each checkbox with the function it performs.  But even this can 
be managed using screen reader commands for reading tables.

I realise that Mailman 3.x will make it possible to create multiple UIs, 
as the functionality will be separated from the UI.  However, it is also 
my experience that alternate/specialised UIs can and do go unmaintained, 
and as such it is my hope that the (or at least a) standard UI shipped by 
default with Mailman will provide the needed accessibility.

So this is one of the reasons why I'm on this list, to keep an eye on 
developments and hopefully provide some feedback when a test server 
becomes available.

Right now, my UI wishlist is as follows:

1.  At least one UI with no *necessary* javascript. Maybe this won't be 
the main UI, but as a person who uses the Linux console with a text-mode 
browser, I like the fact that I can quickly fire up my browser to deal 
with a moderator request with no fuss.  Given that a package like 
Squirrelmail can operate completely without Javascript if the user 
chooses, this should surely be possible.

2.  Proper use of the label tag in association with form elements.  This 
was (or seemed to be done) fairly well for the most part, with the 
exception of those checkboxes I mentioned, but I'd hate to see this lost. 
What this means in practice is that screen readers will read the 
appropriate label text when focusing upon a form element.

There's probably other important stuff, but this is all that comes to mind 
right now.

Other non-accessibility-related things which I think are worth considering 
are:

1.  More useful archives with search capability.  I'm sure this is on a 
dozen wishlists.

2.  A friendlier front page per list.  Surely having 3 forms on the front 
page (or is it 4?) is a bit intimidating to some.

I've got some other feature requests based on 2.1.x functionality but I'll 
post that somewhere else more appropriate.

Geoff.