[Mailman-Developers] ids, javascript, and Forms Acessibility

[Laura Carlson]

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