- From: Jon S. von Tetzchner <Jon@operasoftware.com>
- Date: Tue, 10 Mar 1998 09:34:23 +0100
- To: Jon Gunderson <jongund@staff.uiuc.edu>, Scott Luebking <phoenixl@netcom.com>, w3c-wai-ui@w3.org
We really want to focus on the user, not on the implementation as that quickly makes a bad UI. We also want things as practical as possible. We have already implemented a keyboard interface that allows jumps between elements of various types. We try to focus on what the user needs. Then we think about how to implement it. At 09:44 09.03.98 -0600, Jon Gunderson wrote: >I think we want to write the guidelines so they are easy to understand by >developers. Could browser developers respond to Scotts thoughts on the >format of the guidelines? >Jon > > > >At 11:54 AM 3/7/98 -0800, Scott Luebking wrote: >>Hi, >>I have a suggestion which might be helpful for writing the guidelines. >>It is often useful to write guidelines not so much from the perspective of >>the writer but from the perspective of the reader. This approach can often >>make it easier for the reader to understand. Since we want browser >>companies to understand the guidelines and agree to implement them, we need >>to think about how the browser company's might look at things. >>Also, the easier it looks to do, the more likely browser developers >>will do the needed work. >> >>My suspicion is that many of the browsers are written using object-oriented >>technology. The object-oriented technology has many advantages, but one >>challenge is that good object-oriented programmers need to think >>fairly abstractly about the issues, much more abstractly than programmers >>writing in C, etc. >> >>The guidelines reference things like headers, links, forms. One suggestion >>is to come up with an abstract class name for them. The term 'elements' >could >>be used, but I think a term which somehow conveys the navigation aspect might >>be very helpful. (Many elements in HTML are not related to navigation.) >>My suggestion is the term 'landmark elements' or just 'landmarks' for >short. >>(Actually, it might be useful to drop the 'elements' part in case there >>might be navigation points which don't exactly correspond to HTML elements.) >> >>If the abtract class is "landmarks", then various sub-classes can be: >> >> links >> headers >> paragraphs >> begin form >> end form >> input fields >> begin list >> end list >> list item >> begin table >> end table >> table cell >> >>The various types of landmarks actually have similarities in navigation. >> >>Explicit navigation >> >> e.g. go to link numbered 5 >> >>Sequence navigation >> >> e.g. go to next/previous header >> >>Navigation via list of landarks >> >> e.g. go to zip code field in form >> >> >>A few of the landmarks have actions associated with them. The landmark >>class structure could look like: >> >> landmarks >> >> headers >> paragraphs >> begin form >> end form >> begin list >> end list >> list item >> begin table >> end table >> table cell >> >> action landmarks >> >> links >> input fields >> >>The action landmarks could be triggered by explicit specification >>or by having the landmark highlighted in some way. >> >>Does this class structure make sense? >> >>Scott >> >> >Jon Gunderson, Ph.D., ATP >Coordinator of Assistive Communication and Information Technology >Division of Rehabilitation - Education Services >University of Illinois at Urbana/Champaign >1207 S. Oak Street >Champaign, IL 61820 > >Voice: 217-244-5870 >Fax: 217-333-0248 >E-mail: jongund@uiuc.edu >WWW: http://www.staff.uiuc.edu/~jongund > http://www.als.uiuc.edu/InfoTechAccess > > > -- Regards/Ciao/Kær kvedja/Vennlig hilsen/... Jon S. von Tetzchner Opera Software Jon@operasoftware.com http://www.operasoftware.com Opera - The browser that is made for you.
Received on Tuesday, 10 March 1998 03:47:10 UTC