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 Saturday, 15 December 2001 14:11:34 UTC