[Mailman-Developers] ids, javascript, and Forms Acessibility
Laura Carlson
lcarlson at d.umn.edu
Fri Jun 30 16:19:04 CEST 2006
--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/
More information about the Mailman-Developers
mailing list