[Mailman-Developers] Forms Acessibility (was Re: Hi! I'll be your intern for the summer :)) summer :)

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