- From: Al Gilman <asgilman@iamdigex.net>
- Date: Sat, 28 Aug 1999 18:47:33 -0400
- To: w3c-wai-gl@w3.org, w3c-wai-ua@w3.org
Let me try again: I think that there are several related things here: * Validation of QuickStart performance in low-vision and no-vision usage scenarios. * Structural navigation within a page. * Navbars as functional groups. * The skip-navigation link. The QuickStart performance factor belongs in a role similar to a guideline in the Validation Techniques discussion. n. Performance Factor n.m Validation technique etc. The evaluation question for QuickStart capability is "can users with no visual display or viewing only a small fraction of the normal scope displayed surely and rapidly move to the meat of the page, where the information is conveyed that one only learns by visiting this particular page. This factor is a big problem in practice and deserves priority in planning and budgeting for user testing. In other words, until your site is under the control of a design practices guide which has been proven through user testing to support this QuickStart capability, get the site and prototypes for new site designs evaluated by qualifying end-users for this question. Recommended action: develop this topic in the Validation Techniques section of the WCA Techniques. Structural Navigation I do believe this is the way we want to head for XML. In HTML we are starting at a disadvantage; it is not even clear what one will get for a parse tree from many pages. This is also an area which is not as clear in the WCAG as one might wish. We have a variety of guidlines that dance around this issue but never really address it squarely. + 3. Use markup and style sheets and do so properly. + 12. Provide context and orientation information. + 13. Provide clear navigation mechanisms. + 14. Ensure that documents are clear and simple. One of the key points is that to maintain a clear and consistent page organization across the site, two simple techniques that really help are the following. (1) Write it out: Write down a site structural plan and style guide. Follow it. (2) Write it in: Use markup, especially TITLE attributes, to say how the parts of the pages follow the plan. Add DIV if you need a collector to show the block structure. TIP: if you use separate database queries to populate successive portions of the HTML, make each portion a separate DIV and relate the TITLE of each to its query. This is the point where I believe that the cognitive and blind interests line up in agreement. Recommended action: strengthen section 3.5 of the WCA Techniques to talk about making the block structure visible in the parse tree with the aid of DIV if needed, and the roles of the blocks clear in the TITLEs of the elements which root the principal parts of the page and their respective principal sub-parts. There is a document structure problem that this combines a variety of checkpoints. It would be better for this topic if the techniques were not farmed out under single checkpoints. In the user agent, some combination of markup and heuristics will make structural navigation useful, but we have not really found out what combinations work and which don't. Either it's all going to be heuristics, or the authors are going to need some automated feedback from the author tools to make this work. It seems to me we need at least one reference method for automatic List of Contents extraction for a page if we are going to get very far with this. This reference method needs to be the same in UA and AU documents, or presented in one place and cited in the other. Recommended action: ask ER-IG to consider, test, and recommend methods for extracting an effective document structure for existing pages. Capture the result in to the UA and AU documents. ** Navbars as structural groups. Because of the time it takes tabbing through links in audio mode, these should be explicitly grouped in a container both for ease of skipping when they appear before the meat of the page and in order to make it easy to navigate to them through structural navigation. MAP is arguably specifically for this purpose, although this is probably not a widely held idea among authors, yet. For the purposes of user agent structural navigation, it is not clear that a MAP should be treated much different from any other collector but one could announce it as a navbar if it is marked MAP. For orientation to the parts of a page TITLE should take precedence over element types for presentation to the user when present. Recommended action: Use MAP in the specific technique and examples for "grouping related links." Do not suggest that TITLE be given a fixed, conventional value. Title for navbars should be selected to reflect the specific structural plan of this site. Examples of titles for the first navbar at the top of the page might be "Credits," "QuickLinks around BozoVille," etc. ** Skip-navigation link. This is needed at the present time. The "until user agents" clause could be something like "until user agents support structural navigation which will guarantee a quick path to the meat of your pages." Those who find a visible link esthetically undesirable may hide this link using a one-pixel image with an ALT explaining the skip-navigation function. If there are more than, say, five links before the meat of the page, there should be one of these links as the first or near the first link on the page. Link counting is done without regard for TABINDEX in this case (until user agents...). Recommended action: State this technique somewhere in the WCA Techniques. It is actually better to do it in the new 3.5 under general navigation than under "groups of links" because the specific group of links one would wrap in a MAP is often less than the frontmatter one would skip with this link. A typical setup includes multiple bars within the frontmatter. Use it in the example of MAP for navbars, but don't define it there for the first time. Summary: Using MAP for navbars is fine, but it does not solve the QuickStart performance problem until user agents implement corresponing structural navigation, and it does not fully answer the User Agent question "How should we interpret markup in order to deliver structural navigation." In addition, the Validation Techniques section should address the QuickStart performance issue as a topic, because it is a major quantitative problem in the field today and understanding the issue will help web content authors respond with effective relief. Al
Received on Saturday, 28 August 1999 18:40:19 UTC