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