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

Re: [proposal] additional success criterion for WCAG2 CP 1.5

From: Al Gilman <asgilman@iamdigex.net>
Date: Thu, 23 Aug 2001 18:10:26 -0400
Message-Id: <200108232151.RAA6838972@smtp2.mail.iamworld.net>
To: "gregory j. rosmaita" <oedipus@hicom.net>, <w3c-wai-gl@w3.org>
At 05:02 PM 2001-08-23 , gregory j. rosmaita wrote:
>aloha, y'all!
>
>this proposed success criterion for WCAG2 checkpoint 1.5 ("Separate content
>and structure from presentation") is intended to either replace or
>supplement the final success criterion for
>checkpoint 1.5 and to address "final form" document instances/objects...
>
>currently, the final "Success Criterion" for 1.5 reads:
>
><quote>
>To the extent that the technology allows (see checkpoint solutions) the
>markup or data model representing the structure of the content, must be
>logically separated from the presentation, either in separate data
>structures or in a style sheet.
></quote>
>
>note 2: optional qualifiers are enclosed in brackets -- the key concept is
>that an author can define presentation as long as the author utilizes markup
>that makes it possible for automated extraction of semantics and automated
>repurposing
>
><PROPOSED who="GJR">
>* Ensure all semantics are captured in markup in a repurposeable
>  form. The markup or data model representing the structure of the
>  content, must be logically separated from the presentation, either
>  in separate data structures (such as Schema) or in a style sheet.
>  Documents which use languages designed solely for presentation or
>  a document instance tailored for a specific purpose, such as
>  printing, which uses a final form tagset or absolute style rules
>  must adhere to the following caveats:
> + Associate final form objects with the higher level semantics
>          of the source, whenever applicable, so that the semantics
>          can be extracted from the final form object.
> + Final form (immutable) document instances must not be
>   promoted as being a generally suitable method of storing
>          content that can be used across a variety of devices.
> + The server should confirm that the client wants this
>          particular form before serving it.
>        + If purpose of using final form tagsets and/or absolute
>          presentation rules are intended to provide document
>          instances for a specific purpose, such as printing,
>          provide the same content in an accessible format.

AG:: 

This is much better, or at least we will have less work to do reconciling WCAG
and XMLGL if most of these ideas get in.

Perhaps what we are coming down to is that 1.1 -- provide alternatives -- is
for non-text and for hard-optimized (i.e. no longer fully repurposable)
content.

[Editorial -- I don't believe that Gregory intended the extra indent on the
last bullet]

Al

></PROPOSED>
>
>note 3: upon my umpteenth re-read of this, i'm not sure whether the
>caveats should be listed at this level, or be addressed in the
>checkpoint solutions layer -- and if there are caveats that kick in
>when people use presentational languages and final form tagsets,
>shouldn't we have a "final form/presentational" techniques document
>(not its actual name), which would subsume the PDF Techniques
>document, i suppose, or be the "parent" module to the PDF Tech's
>"child"?
>
>note 4: the first sub-list-item contains a "should" which probably
>should be a "must"
>
>note 5: i think that it may appropriate to include a reference to
>GL4 under this success criterion
>
>note 6: is it necessary to define "final form"?
>
>gregory.
>----------------------------------------------------------------------
>ASPERSE, v.t.  Maliciously to ascribe to another vicious actions which
>one has not had the temptation and opportunity to commit.
>                    -- Ambrose Bierce, _The Devil's Dictionary_
>----------------------------------------------------------------------
>Gregory J. Rosmaita, oedipus@hicom.net
>              Camera Obscura:
<http://www.hicom.net/>http://www.hicom.net/~oedipus/index.html
>----------------------------------------------------------------------
>  
Received on Thursday, 23 August 2001 17:51:04 GMT

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