- From: Al Gilman <asgilman@access.digex.net>
- Date: Wed, 16 Dec 1998 15:39:47 -0500
- To: w3c-wai-ua@w3.org
At 02:26 PM 12/16/98 -0500, you wrote: >Hello, > >As per my action item in today's teleconf (raw minutes available >at [1]), here is a proposed structure for how UAs can claim >media-dependent conformance: > >1) The document lists a finite number of "media types", based on, but > not limited to, those defined by the CSS2 specification [2]. > >2) In the guidelines document, each media type is defined (only) as a >set > of priority 1 techniques. Thus, for example, the "tty" media type > (or perhaps the term should be "UA type") Let me offer UI profile as a technical term that is correct and let the editors worry about how to explain this to readers. The point is that this is one step removed from media types as used in HTML and CSS and so we should not use the same term. A UI profile states what resources are available for interaction with the user, preferenably in terms of a rough capability bin and not too exact detail. In other words all color graphics displays of greater than eight colors and greater than 640X480 pixels could be treated as one capability bin (not less than 50 Hz refresh, ...). Note that the media types as used in HTML and CSS only pertain to the display function. The failure modes that keep people from using the normal mouse command IF of the GUI desktop computing platform can be either in inability to control the mouse or in inability to interpret the screen cursor. The mouse command sub-function in the GUI is a closed loop of display and control sub-functions; a failure in any of these sub-functions breaks the loop and defeats the composite function. Text plays a central role in display diversity because of all data representations in current use, it has the widest fanout across display media. Likewise keyboard commands have a comparable central role in command diversity because AT to map alternative devices into keyboard emulation is highly developed and widely available. So mapping keyboard commands into alternate devices is readily attainable by the user. Mapping other command modes into suitable alternative devices is more risky. This is parallel to why we shadow video with audio descriptions and text descriptions. The video only works for a narrow class of devices; the text is more mappable to alternatives. The content we have to presume is multimedia. The trick is to map the constellation of content components into the constellation of UI components that are in the user's selected/adaptive profile. I think we are getting somewhere if we define UI profiles as collections of device capabilities. HTTP/CSS media classes are examples of device capabilities. Including a device capability in the UI profile means that the software can expect the user to use this capability. Then for each profile analyzed, you can come up with a corresponding technique profile of the minimum techniques needed to be effective in this UI profile context. Then for each software product, it can claim it supports X UI profile natively (because it implements some superset of the minimum techniques) and Y UI profile through adaptability (if it supports an add-on interface and there are widely available add-ons which take this interface and complete a UA configuration providing the rest of the necessary techniques for Y UI profile. Because the UI techniques actually depend on closing the loop through multiple devices, I think we need to treat conformance in terms of UI profiles, not UI components individually. Al
Received on Wednesday, 16 December 1998 15:38:51 UTC