- From: Cynthia Shelly <cyns@whatuwant.net>
- Date: Thu, 17 Aug 2000 14:47:58 -0700
- To: "W3c-Wai-Gl@W3. Org (E-mail)" <w3c-wai-gl@w3.org>
In general -- great job! I found it much easier to navigate the document, and relate the specific work items to the goals they achieve. Some thoughts on specific sections: Checkpoint 1.4 - Does anyone know if Flash supports synchronizing captions? Is there a flash expert on the WG? Anyone know one we should try to recruit? Checkpoint 1.5 - text equivalents for client side image maps. A possible technique: can you hide the extra links with CSS, and provide an accessibility stylesheet that unhides them? Is there a good way to allow user-selected stylesheets on a per-site basis? This could be a very powerful way to enable accessibility features for those who need them, without changing the UI/Prettiness experience for those who don't. Checkpoint 5.4 The HTML technique "tables for layout" doesn't provide any more info that the checkpoint that linked to it. HOW do you do this? Needs some examples. Checkpoint 6.3 [Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.] Directly accessible scripts section: THIS ROCKS! I'm very happy to see this info included. We should add something about using keyboard shortcuts. For example: <span onfocus="click(this)" onclick="dofoo()" tabindex="1" accesskey="c"><u>C</u>lick here</span> alt-c will trigger the click event. You could also add this through script at runtime. For example, put a button on the page that registers focus handlers for all elements with click handlers. Alternative pages: Here are a couple of techniques for creating automatic server transfer to alternative pages: A lot of server-rendered already do "browser sniffing" to optimize for particular client technology. By adding an else clause to your sniffing script, you ensure that any browser you don't recognize gets that version. Many sites already have this else clause, but send a "get a new browser" message. Instead, write a version of the server rendering script that renders the content in linear form with much simpler HTML, content moved from script to html, etc. This is also useful for supporting old browsers in general. The above handles the case of a browser you don't recognize, but many (most? all?) browsers don't send the script status to the server, so you can't tell from server script if (for example) an IE 5 user has disabled script in the browser. One option for this case is to set a cookie on the client machine so that the user would always be redirected to the alternate page, and wouldn't have to follow a link to get there every time they went to your site. Cookies can be set from server script in response to a user navigating to a URL, so this would work on a modern browser (cookie supporting) with script disabled. Obviously, you'd want to inform the user that they were setting a cookie and have a way for them to unset it. On sites that support personalization, the user preference for the alternative version of the content can be just another personalized setting. Similar approaches could be used to change css or xslt style sheets on the server without user intervention. checkpoint 10.2 [form labels] IE5 supports the <label for> tag. It works great with win2k narrator, and ok with Jaws. Checkpoint 10.4 [empty controls] Are there still commonly used User Agents that have problems with this? How do we decide when an "until user agents" clause has been met? CSS Techniques technique # 3, units of measure: What about the x-small, small, medium, large etc CSS font sizes? I've found that these are much easier to use than ems (ems are very large, and it's difficult to get precise layout with them). These work pretty much the same way as <font size=n> tag in HTML, so they will be intuitive to authors used to font tags. They also resize when the font-size is changed in the browser (I've tested this on IE4 and 5, and Netscape 4.7 on Windows). Technique #11 Layout Does anyone have an example of an accessible use of absolute positioning? I've had a lot of trouble getting absolute positioning and resizable fonts to play nice. I think we might need to do some specific techniques and examples for absolute positioning. HTML Techniques 6.3 Keyboard access Accesskey seems to only work on items that have a tabindex (hrefs and form elements by default, but span, div etc only when tabindex is defined.) Is this behavior defined in the standards, or is this just an IE5 implementation detail? We may want to note this somewhere.
Received on Thursday, 17 August 2000 17:46:58 UTC