W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2001

RE: Proposal for 1.5 success criteria

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>
Message-ID: <004a01c1872e$94223640$b2176880@trace.wisc.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:17 GMT