- From: Gregg Vanderheiden <GV@TRACE.WISC.EDU>
- Date: Mon, 17 Dec 2001 13:11:06 -0600
- To: "'Al Gilman'" <asgilman@iamdigex.net>, <w3c-wai-gl@w3.org>
Interesting approach. Should it be more than "adjust" ? That sounds like "increase font size" but not "change to speech output" Hmmmm Perhaps "Provide all content and structure in a fashion that it can be separated easily from any one presentation format." Or "Provide all content and structure in a fashion that the user can select a different presntation format and still retain all content and structure." Or something like that Wordy -- but we can edit it down to obscurity later. Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Human Factors Dept of Ind. Engr. - U of Wis. Director - Trace R & D Center Gv@trace.wisc.edu <mailto:Gv@trace.wisc.edu>, <http://trace.wisc.edu/> FAX 608/262-8848 For a list of our listserves send “lists” to listproc@trace.wisc.edu <mailto:listproc@trace.wisc.edu> > -----Original Message----- > From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On > Behalf Of Al Gilman > Sent: Saturday, December 15, 2001 1:23 PM > To: w3c-wai-gl@w3.org > Subject: Re: Proposal for 1.5 success criteria > > ** Summary: > > The success criterion for Checkpoint 1.5 is that UAAG Guideline 3 works for > the > content you provide. the user can adjust the presentation details while and > the > structure and content are preserved in spite of this change. > > The navigation and orientation success stuff may wind up at Checkpoint 1.3. > > Checkpoint 1.5 should be rephrased "Enable user adjustment of > presentation." > > ** Details > > The problem is in the problem statement. > > "Separate presentation from structure and content" is a pseudo-technical > description of the solution. It is neither a user-experience description > of of > the operational requirement nor a correct technical description of the > technical requirement. > > There is no technology-free content criterion for "separate presentation > from > structure and content." The separation is not present in the direct user > experience. The user always experiences the structure and content in some > binding, whether to display media properties or in the case of structure > binding to navigation verbs. There are requirements for indirect user > experience that relate, here: control of presentation and input-acceptance > property bindings to the content, and systematic control of > reading-location in > the content. But these are not one but at least two. The content > requirements > are, as in checkpoint 1.3 to provide machine comprehensible > representation of > enough information so the user agent can provide the functionality. > > The success criteria here are: > > + Details: The user is able to adjust presentation[*] properties[*] to > optimize their information exchange with the content appropriately for their > circumstance[*]. > > + Navigation: The user is able to browse the content selectively, making > informed decisions as to where to go, what to spend time with. > > + Orientation: The user is able to maintain a sense of the rhetorical context > for fragments and locations in the content[*] when there and in the case of > navigable destinations, before going there. > > [... and furthermore] > > + The orientation is preserved when using the navigation for selective > browsing. > > + These presentation control and navigation with orientation capabilities > operate independently. > > + Relative emphasis is preserved under presentation adjustment. > > The operational capabilities required here should be described with a "for > instance" _plus_ a reference to the UAAG for details. > > [* Note 1: presentation here included binding to input device functions.] > > [* Note 2: This is where the metadata come from. The dimensions of > presentation: graphical and color resolution, emphasis input device > independence, ... that have to be adjustable to work around disabilities is > something that we will be more effective if we can achieve a consensus > reference model for.] > > [* Note 3: 'circumstance' here is synonymous with 'delivery context' in the > Device Independence draft. I don't know if the fact that it rolls up client > device, environmental factors such as background glare and noise, and > human > performance factors involved in disabilities will be clear by this point in > the > document. If not, one can expand it here, but I would hope we would have a > buzzword for this by this point in the text.] > > [* Note 4: This delicate wording is trying to throw a blanket over a range of > things. Two examples follow: screen reader speaks row and column > indices; > 'overdone' paragraph styling is helpful for those with reading difficulties. > See the RFB&D website for an example of the latter.] > > Al > > drafts and more details follow > > At 09:10 PM 2001-12-14 , Cynthia Shelly wrote: > >Here's my action item from the 6th - reworked success criteria for 1.5 > > > >You will have successfully separated content and structure from > >presentation if: > >1. A user can change the presentation to meet his/her needs, for > >example by applying a different stylesheet > > AG:: In the spirit in which you dropped the 'data model' mechanism, would > this > be better stated as "for example by enlarging text font, changing colors to > enhance contrast, and generally employing the capabilities described in > UAAG > Guidelines 1 and 4 that their User Agent affords"? > > >2. The following can be derived programmatically from the content: > >a. A logical, linear reading order > >b. Hierarchical elements, such as headings, paragraphs and lists > > AG:: > > Here I think that we have to get a wee bit technical. While existing > heuristics for structural navigation detect headers and will move you there, > the headers are not "hierarchical elements." They are label elements that > mark > the start of hierarchical subdivisions of the content. At least in the DAISY > digital talking book navigable-space model, the model takes pains to make > "what > the header introduces" the hierarchical unit and "the header" its > representative in the summary Table of Navigation. > > The capabililities the user should have are pretty well covered in UAAG > Guidelines 9 and 10 on navigation and orientation. > > The requirement to provide _as content_ distinctions in emphasis, which > can be > re-bound to different interface phenomena, deserves more work in our > modeling > of the problem. No format technology yet supports this well IMHO. > > > /TR/UAAG10 > > The techniques for satisfying these are discussed at an even more summary > level > in XAG Checkpoint 3.2. > > /TR/xag > > This model deserves more work, but here is this morning's summary of > what > structure needs to be recognizable: > > 1) logical sub-units which make reasonable sense to browse by themselves. > 2) a terse identification of each of these for orientation > 3) a navigable destination for each of these for navigation > > > >c. Relationships between elements, such as cross-references and > >associations between labels and controls > >d. Emphasis > > > > AG:: > > Emphasis consists, in its device-independent representation, of > relationships > between classes of content. But for this audience it is probably best to > state > c. and d. both. > > > > >I've taken out the stuff about markup and data models. This is mostly > >because I don't think it matters how the structure is made > >programmatically available, as long as it *is* made programmatically > >available. This approach is also more flexible for future technologies, > >and a lot less wordy. I added #1 because I felt that user control > >needed to be made more explicit. > > > >Let me know what you think, > > The success criterion for structure is, in my mind, affording a capability of > selective reading. That the user can find, choose and browse portions of > the > content when that is all they need and it affords a significant savings in > time > or UI effort. The two 'where' conditions in this statement are entirely > user-side. The content can't know in advance. There are some things that > can't be separated, such as legends that must accompany certain material. > That > is all handled in the DAISY model. > > As I get into this, Cynthia has hit on something important. > > This is not one checkpoint, or what we need here is not one checkpoint. > > There needs to be content support for user control of styling, and content > support [including orientation] for navigation. Those are distinct > operational > requirements of the user as it is clear in the UAAG. > > *Separation of presentation from structure and content is not achieved in > the > direct user experience*; in the direct user experience they are experienced > together. Separation is only required and only attainable in a) the indirect > interaction of the user with the content through browser controls and b) the > encoding technology of the content. Style adjustment and structural > navigation > are two user capabilities that participate in the indirect user interaction > with the content. They live in a meta layer. Style control and navigation > are > browser-supplied functions. In the UI they live in what Rich Schwerdtfeger > would call "the chrome." The user associates them with the browser, not > the > page. *They should operate independently.* This is the user operational > requirement. > > The content requirement is to express structure and style in sufficiently > machinable ways that support the UAAG-described manipulation of style > and > content. See the XAG and the techniques for how. > > The closest thing to a non-technical requirement to separate presentation > from > structure and content is a) the restyling and navigation operational > capabilities set out in the UAAG and b) that these shall be reasonably > decoupled in their operation. Beyond that it's all representation-dependent > requirements to meet the technical needs of the user agent so it can > comprehend > and manipulate the presentation and structure while still providing full > access > to the content. > > Al > > >Cynthia > >
Received on Monday, 17 December 2001 14:13:56 UTC