- From: Charles (Chuck) Oppermann <chuckop@MICROSOFT.com>
- Date: Wed, 6 Jan 1999 18:41:51 -0800
- To: love26@gorge.net, w3c-wai-au@w3.org
<< It might be nice to include (perhaps in 2.11?) the ability to test not just the text rendering but any of the other proposed versions such as "how does this look in lynx, pwwebspeak, homepage reader, IE, Opera, Netscape?" >> How in the world could that get acomplished? FrontPage needs to figure out how Opera interprets HTML and render that? Think of all the different versions of browsers. Should Lynx 2.7 or 2.8 be used? This is impactical. If the author wants to know what their content looks in another browser, should use that browser to verify. << The proposed 2.4 is *extremely central* to this whole process because it is where we have hit the most resistance ("interface bloat" excuse). >> Can you elaborate on this comment? I'm not certain what you are refering to. Charles Oppermann Program Manager, Accessibility and Disabilities Group, Microsoft Corporation mailto:chuckop@microsoft.com http://www.microsoft.com/enable/ "A computer on every desk and in every home, usable by everyone!" -----Original Message----- From: love26@gorge.net [mailto:love26@gorge.net] Sent: Tuesday, December 29, 1998 6:47 AM To: w3c-wai-au@w3.org Subject: re: proposed changes It might be nice to include (perhaps in 2.11?) the ability to test not just the text rendering but any of the other proposed versions such as "how does this look in lynx, pwwebspeak, homepage reader, IE, Opera, Netscape?" This has so much in common with ER that the co-ordinating group should address the maintenance of this issue since the (rather slow) progress of the UAs (they don't even implement CSS2! and we're looking to XML, etc.) is most discouraging to people trying to use the author guidelines within a text editor and how far behind that are the AU tools going to be? How can we encourage the tool designers to make it simple for tool users to be made aware of how their output will look/sound on a TV, Palm Pilot, Cell Phone, braille display, etc.? The proposed 2.4 is *extremely central* to this whole process because it is where we have hit the most resistance ("interface bloat" excuse). I would prefer the language to be a bit more forceful, "provide mechanisms" somehow strikes me more passive than need be. We won't "require", etc. but something beyond what's here might be called for. It seems that this section and 2.10 could be combined. In general in all pertinent cases emphasis might be warranted on all the descriptors such as whether a table is a *real* table or just a lazy formatting device. -- Love. ACCESSIBILITY IS RIGHT - NOT PRIVILEGE http://dicomp.pair.com
Received on Wednesday, 6 January 1999 21:41:57 UTC