--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/ _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
