[Mailman-Developers] Forms Acessibility (was Re: Hi! I'll be your intern for the summer :)) summer :)
lcarlson at d.umn.edu
Thu Jun 22 16:22:25 CEST 2006
--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.
The W3C identifies two different types of labels: implicit and explicit
. 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."
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." For an illustration of
this visit Roger Hudson's Web Essential 05 Association Examples .
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
Something to be aware of is that the current opinion of many
accessibility experts is that accesskeys mostly work against
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 . However, John Foliot's
and Derek Featherstone's   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
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  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 L. Carlson
Information Technology Systems and Services
University of Minnesota Duluth
Duluth, MN 55812-3009
More information about the Mailman-Developers