Mailman 3 June 2006 - Mailman-Developers

Forms Acessibility (was Re: Hi! I'll be your intern for the summer :)) summer :)
by Laura Carlson 11 Sep '06

11 Sep '06

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

4 3

SoC: status update
by emf 04 Jul '06

04 Jul '06

http://wiki.list.org/display/DEV/Summer+of+Code Gentlebeings, I have updated the summer of code page above to indicate my current progress and record the synthesis of the opinions I have received so far. Thank you for the excellent feedback you've provided so far; don't be shy about continuing, either here or on the wiki. ~ethan fremen

4 5

Hi! I'll be your intern for the summer :)
by emf 03 Jul '06

03 Jul '06

Hey, all; I'm ethan fremen, and I've been selected for a WebUI Summer of Code project. I'll keep a running log of my progress at http://wiki.list.org/display/DEV/Summer+of+Code My svn branch is https://svn.sourceforge.net/svnroot/mailman/branches/soc2006-webui ; feel free to check it out as the inclination strikes you. I'm especially interested in getting any feedback, either on the wiki or here, about any and all WebUI - or UI in general - ideas in people's heads. While the SoC project is fairly constrained, I want to at least make the future easier. ~ethan fremen

9 35

Re: [Mailman-Developers] ids, javascript, and Forms Acessibility
by Laura Carlson 30 Jun '06

30 Jun '06

--On Friday, June 30, 2006 12:00 PM +0200 emf wrote: > I'm thinking of using Kid to generate pseudo-random numbers for ids. > This works great, except when someone wants to use an id selector in > CSS or getElementById() in JavaScript. > If I do this, I'll have to use class attributes (which happily can > contain many values) to disambiguate form elements for JavaScript, > and JavaScript will have to add/remove class attributes to change > display for CSS. This is fine save that View Source becomes more > opaque for someone who just knows CSS and HTML. I'm not quite sure what you have in mind here, Ethan. But for CSS, mailman admins could use selectors based document structure the majority of the time, IF the documents are structured an intelligent way. This method would also have the benefit of dramatically reducing stylesheet size and aid maintenance. Classes and IDs aren't always needed for CSS! If every type of element is going to have the same style, adding a class to every one is redundant. It is best to eliminate cases of classitis and divitis where valid XHTML will do. In school, most people were forced to write essays in a standard outline format. That is exactly the way that XHTML works. Web pages should always have structured textual content in organized hierarchies (outlines). It might be useful to think about a print stylesheet to help you think about page structure. If you'd want a print document to look like an outline, or magazine article, you'd think of heading priorities, lists of useful references (links), and what items belong in a header, footer, or sidebar. So... - For headings, use h1 - h6 - For paragraphs, use p - For lists where the order isn't important, use ul and li - For lists where the order is important, use ol and li - For lists where you're defining something, use dl and dt - For quotes, use blockquote with a corresponding cite attribute - For links, use a with a corresponding title attribute. - For bold text, use strong - For citations, use cite - For images, use img with a corresponding alt attribute and longdesc if needed. - Use table, td and tr for tabular data only. - Use div and span to: 1. style sections of content. 2. add generic structure to the document. 3. or when warranted by lack of style sheet support. Use of most any element instead of or in addition to those listed above (for the corresponding purpose) will reduce the semantic quality of the document. It is that simple. Think very hard about the document tree and selector behavior. This is necessary (as painful as it may seem at first) to enable you to visualize a document's structure mentally and determine what selectors can be used to address parts of it. Give serious attention to the logical structure of a web page. Not only will your attention make it inherently more accessible, it will help insure that you are correctly pinpointing what you really want styled. This allows you to target selectors to accomplish precise tasks. So a key to writing smart style sheets is mastering selectors. Using structure and selectors in an intelligent way can dramatically reduce stylesheet size and aid in maintenance. >> TABINDEX >> >> having a sensible natural order to start >> with, meets WCAG requirements for HTML documents. > > I think this is a good idea, but I'm not going to control the global > order of the pages the controls sit in, which is probably an argument > for forgoing tabindex all together. I agree. > I have some "global" controls I was going to > have sit "on top" of the content, and float it right. Now it sounds > like I should put the global controls after the content, and use > absolute positioning to put them on the right. Constrains the > page-flow a bit more than I would like, but it is probably worth it. Float is probably a better way to go. It allows for more fluid layouts and a large degree of control over elements. It would be good to add skip links to jump over global controls and navigation links. Skipping navigation is important for accessibility [1]. Joe Clark explains the theory and coding techniques well [2]. Skipping navigation aids people who use screen readers or other types of assistive technologies so they do not have to wait for the assistive technology to work through and announce each of the standard navigational links before getting to the intended content. Navigation links can be tedious to wade through. Sighted people with good mobility can ignore them. A blind person using a screen reader must experience the links one after another, which is very inconvenient. So when there are lists of navigational of links, there needs to be a link to an anchor that skips them to get to the actual content of the page. They were originally intended as a navigation aid for people with disabilities, but they are a also very useful to mobile phone users. As Clark says, it is best to keep skip navigation links visible [3]. You can hide the text in links that allow users to skip the navigation, but then you have the problem that this hides an accessibility feature from those who can see and who cannot use a mouse. All the Best, Laura [1] http://www.access-board.gov/sec508/guide/1194.22.htm#(o) [2] http://joeclark.org/book/sashay/serialization/Chapter08.html [3] http://joeclark.org/book/sashay/serialization/Chapter08.html#h4-2020 More Skip Navigation info: http://www.d.umn.edu/goto/accessibility#skiplinks ___________________________________________ 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/

1 0

Re: [Mailman-Developers] Accessibility Testing Tools (was Re: Hi! I'll be your intern for the summer :)) Hi! I'll be your intern for the summer :))
by Laura Carlson 30 Jun '06

30 Jun '06

--On Thursday, June 29, 2006 8:09 PM +0200 emf wrote: >> One of the tools that I have my students use is to test forms is the >> WAVE. [5] It will spot violations like missing labels, labels not >> associated with inputs, empty labels, etc. and notify you with >> icons. [6] > > Great! I will use that and Cynthia. Sounds good, Ethan. If you need any help interpreting the automated tools analysis and recommendations, please let me know. To be effective, accessibility checkers should form part of a wider process that includes an informed person acting on their recommendations. Where accessibility is concerned, human judgement is key. Knowledge is the best tool for ensuring accessibility. The tools are only useful if you know what they're looking for, and if you know how to interpret their suggestions (including allowing for special cases in your code that generate false alerts in the evaluation). They will also only verify a fraction of the things you need to do -- the rest of the checkpoints require "human judgement"-- i.e., knowledge. 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/

1 0

Acessibility Testing Tools (was Re: Hi! I'll be your intern for the summer :))
by Laura Carlson 29 Jun '06

29 Jun '06

--On Thursday, June 22, 2006 4:15 AM +0200 emf wrote: > If you know of a way that I can > actually test JAWS or another screen reader, I would be grateful for > the pointer. David Andrews already mentioned the demo versions of JAWS and Window-Eyes [1]. Thank you Dave for offering to help test! Dave can provide valuable insights and expertise. Human Evaluation is very important [2]. Ethan please do download and try a screen reader. But like Dave said, it is best for inexperienced users not make design decisions based on their experiences with screen readers. Its just too different from someone who uses the technology on a daily basis, because they have to. Home Page Reader [3] is also a good tool for web developers and designers who are looking to try out a speaking browser. It will give you somewhat of an idea of how the blind or visually impaired would experience your pages. It presents a web page in two different views. It places the graphics view, a true rendering of the Web page, in the upper portion of the program window. Then, it shows a text view of the Web page in a window below that graphics view. Again, you'll gain an appreciation for what a blind user would hear when listening to your Web page. There is a free 30 day free demo available. There is also a tutorial on Testing Web accessibility with Home Page Reader available [4] One of the tools that I have my students use is to test forms is the WAVE. [5] It will spot violations like missing labels, labels not associated with inputs, empty labels, etc. and notify you with icons. [6] Cynthia [7] is also one online tool that every web developer should be familiar with. In the hands of someone trained to do accessibility checks, it's really no better or worse than any of the other tools. Cynthia analyzes web pages and checks for a set of accessibility problems that can be checked for automatically. Although it is a very limited program, it is also a good program. It can help with the checking process. The rest needs to depend upon human judgement. There's a great little Colour Contrast Analyser Firefox Extension [8] by Gez Lemon I have found useful lately. It saves time and helps take the guesswork out of determining accessible color combinations. It can go through a page and check (give you pass or fail) on luminosity contrast ratios, difference in brightness, and difference in color. Many, many more helpful accessibility tools exist. To get an idea of the number visit the Tool Section of the Web Design Reference. [9] All the best, Laura [1] http://tinyurl.com/e9bno [2]http://webaim.org/articles/process/human.php [3] http://www-3.ibm.com/able/solution_offerings/hpr.html [4] http://www-3.ibm.com/able/guidelines/web/webhprtest.html [5] http://www.wave.webaim.org/wave/index.jsp [6] http://www.wave.webaim.org/wave/explanation.htm (Scroll down to the forms section) [7] http://www.contentquality.com/ [8] http://tinyurl.com/awlqm [9] http://www.d.umn.edu/goto/tools ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN 55812-3009 http://www.d.umn.edu/goto/webdesign/

5 4

a picture, and a problem with the Debian package
by Fil 24 Jun '06

24 Jun '06

Hello, here's a nice picture. The answer is in the mail http://www.flickr.com/photos/82626280@N00/172609494/ More seriously (or, maybe, less), I've spent a few minutes trying to figure out a problem a user was having (on irc). The problem was that she had configured the list to be in Spanish, but it kept sending welcome messages in English. I finally traced it to the Debian installation, which has weird symlinks: /var/lib/mailman/templates -> /etc/mailman ls -al /etc/mailman/ total 36 drwxr-xr-x 4 root list 4096 2006-04-22 19:46 . drwxr-xr-x 95 root root 8192 2006-06-21 10:41 .. drwxr-xr-x 2 root root 4096 2005-10-04 18:17 en drwxr-xr-x 2 root root 4096 2006-02-10 17:46 fr that's 2 languages only! whereas /usr/share/mailman/ contains all the templates (including es/, which she linked into /etc/mailman/ and solved the problem) For me, if this is confirmed and not a weird thing on my and her Debian installation, it's a problem that should be solved. -- Fil

2 3

Fwd: Re: Hi! I'll be your intern for the summer :)
by David Andrews 22 Jun '06

22 Jun '06

>Date: Wed, 21 Jun 2006 21:50:57 -0500 >To: emf <i(a)mindlace.net> >From: David Andrews <dandrews(a)visi.com> >Subject: Re: [Mailman-Developers] Hi! I'll be your intern for the summer :) > >>Ethan Freeman Said: >>Thanks for all the references. If you know of a way that I can actually >>test JAWS or another screen reader, I would be grateful for the pointer. >> >>~ethan fremen > >Hi: > >I am a blind guy who runs a bunch of lists who is hanging out here, just for this. I will be happy to help you test your pages. Also, you can download demo versions of JAWS http://www.freedomscientific.com and Window-Eyes http://www.gwmicro.com > >However, unless you are an experienced user, there can be dangers in sighted guys doing this kind oftesting. I spent half an hour on the phone one day trying to explain to a developer how you entered data into a web form, and why it was different than from him and his mouse. Some of the cues are pretty subtle, and unless you are used to them you might not realize they aren't there if things are kind of sort of working. > >Dave

1 0

Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)
by emf 21 Jun '06

21 Jun '06

larryt(a)winfirst.com wrote: > I'm not aware of anything about mod_python that would make your work > not also support FastCGI and SCGI. Am I correct? I don't know for certain; I was planning on at least trying to implement RSS feeds as an output filter, which as far as I know means I'm hooking into Apache's request stack at a level FastCGI and SCGI don't touch. I suspect there is a way to wrap things so that they'll work as a fastcgi/scgi/cgi, but I don't know that I'm going there. ~ethan fremen

1 0

Re: [Mailman-Developers] Hi! I'll be your intern for the summer :)
by Laura Carlson 21 Jun '06

21 Jun '06

On Thu, Jun 15, 2006 at 09:01:12PM -0400, emf wrote: > I'm especially interested in getting any feedback, either on the wiki > or here, about any and all WebUI - or UI in general - ideas in > people's heads. Hi Ethan, I mentioned this about a year ago [1], it would be great if the Mailman templates, like the general list information page and the user specific options page, were accessible and standards compliant. For instance when the end user views the current pages, they get form labels that are not explicitly associated with their controls. Using the <label> element is the best way to ensure that people using screen readers and other assistive technology have access to all the information necessary to complete forms online. This makes it possible for screen readers to explicitly identify the onscreen text as a label for the <input> element. The <label> element and its for attribute were added to HTML specifically to support accessible labeling of form controls. - The <label> element assigns a label to a form <input> element (one label to one input). - The for attribute defines the explicit control that the label is associated with. - The for attribute must match the <input> element's id attribute's value exactly. - Each id attribute must be unique within a document. Example <label> with for and id attributes markup: <label for="name"> Your name <input id="name" name="name" title="Enter your first name." size="40" type="text" /> </label> So...for each form control, place its label in a <label> element. A <label> is attached to a specific form control through the use of the for attribute. The value of the for attribute must be the same as the value of the id attribute of the form control. When form fields are not labeled explicitly, screen readers will skip over the text on your form when users try to enter data. For example, a screen reader will simply say, "Edit" or "Edit box," forcing the user to guess what information is being requested. Screen readers will not speak any text on a form that is not placed inside a tag such as a link, label, button, or legend. When form fields are labeled explicitly, the browser can tell the user definitively which label applies to the given control. Usually, clicking on the label positions the cursor in the form field, or toggles the value of radio buttons or check boxes. This is intuitive for many users and provides a larger target for the mouse. Use of the <label> element is especially important if tables are used to lay out a form. Another advantage of using the <label> element is that you can have more control over how field labels appear, using style sheets. Related forms accessibility references: http://joeclark.org/book/sashay/serialization/Chapter12.htm http://www.accessify.com/features/tutorials/accessible-forms/ http://www.webaim.org/techniques/forms/ http://www.d.umn.edu/goto/accessibility#forms Also adding alt attributes to images [2], using good html heading structure [3] [4], and validating to W3C standards [5] [6] would aid accessibility. All the best, Laura [1] http://tinyurl.com/ey8tu [2] http://www.d.umn.edu/goto/accessibility#alt [3] http://www.webaim.org/techniques/semanticstructure/ [4] http://www.d.umn.edu/goto/standards#structure [5] http://validator.w3.org/ [6] http://www.d.umn.edu/goto/standards#validation ___________________________________________ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN 55812-3009 http://www.d.umn.edu/goto/webdesign/

2 1