--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:
- style sections of content.
- add generic structure to the document.
- 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/