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

Re: terms for pictures and such (both coarse and fine categories, related)

From: Charles McCathieNevile <charles@w3.org>
Date: Fri, 5 Jan 2001 08:25:59 -0500 (EST)
To: Al Gilman <asgilman@iamdigex.net>
cc: WAI GL <w3c-wai-gl@w3.org>
Message-ID: <Pine.LNX.4.30.0101050825120.11374-100000@tux.w3.org>
OK, I get it and it makes sense to me too...


On Thu, 4 Jan 2001, Al Gilman wrote:

  This is a bit heavy going, but I haven't found time to make it simple.  I hope
  this helps a little to make what I meant clear.

  At 12:49 PM 2001-01-04 -0500, Charles McCathieNevile wrote:
  >On Thu, 4 Jan 2001, Al Gilman wrote:
  >  At 09:47 AM 2001-01-04 -0500, Charles McCathieNevile wrote:
  >  >How about using 'illustration' and 'decoration' as the two terms. It makes
  >  >more sense to me that we describe a table as an illustration of a point
  >  >paragraph of text, for that matter) than describing an image as an
  >  >
  >  >(except in courtroom drama <grin/>)
  >  >
  >  AG::
  >  No.  You miss the point.
  >  We need the unfamiliar concept, for which this is the most familiar term.
  >  You are trying to arrive at a partition composed entirely of colloquial
  >  terms.
  >I'm not sure what you mean by a partition. I am trying to arrive at a series
  >of documents that people can use and understand without looking up the
  >definitions section any more than they really have to.
  >It is worth being explicit in the definitions sense that we are using a rich
  >(but common) meaning for a term, and not a narrow one, if that is the case.
  >Besides, we use the verb "illustrate" to mean 'expand upon using graphics,
  >sound, whatever it takes' in a checkpoint, with text that makes it clear.
  >In other words, I'm trying to keep the language clear and simple, and think
  >illustrate / illustration does it better than exhibit. It still allows us to
  >be readily understood with the meaning we have, and we can reinforce that
  >with an explanantion of what we mean in the glossary.


  'illustrations' belongs in our working vocabulary.  'exhibits' belongs in our
  working vocabulary.  Quote "_the_ two terms" unquote does not belong in
  what we
  think we have _decided_.  It is too soon to know how many terms will be
  required in the end to say what we need to say.

  1.  I have no problem with calling illustrations 'illustrations.'  That wasn't
  what I said at all.  I do have a problem thinking we an get authors to call
  tables 'illustrations.'  But not to get their editors to call tables
  'exhibits.'  That's how they talk already.

  2.  As it turns out, we can't write the total corpus of documents we need
  (clearly) without using overloaded terms, that is to say using _both broad and
  narrow terms_ in talking about _the same thing_ _in different contexts_.

  You invoked the image of a partition, and gave the idea that 2. above was not
  true, when you used the definite article 'the' in "the two terms."  In
  particular, this was not responsive [did not correspond] to my request to
  insert (i.e. add) a more abstract notion into our working ideology.  I didn't
  say "call _the_ category 'exhibits'."  I said "Please, let's _think_ in terms
  of _a_ more abstract 'exhibits' category _as well_."

  I think it is fine to assert "illustrations and decorations are two kinds of
  graphics that should be treated differently by the author."  I absolutely
  object to saying "illustrations and decorations are _the_ two kinds of
  that should be treated differently by the author."  We need to explore what
  categories there are and what ways there are to handle them some more
  before we
  know how many categories are going to show up in the final explanation.

  I claim [broken record] that we need both to let the author call their object
  something that they can understand, like an illustration, and also have our
  infrastructure (a.k.a. data model, dialect description document or profile)
  provide the clear connection that illustrations so marked are members of some
  broader class [like exhibits] for which we have asked the User Agent to
  some minimum set of method handlers.  The "graceful transformation" methods
  likely to need these more abstract classes like 'exhibit' to cover the
  waterfront of applications gracefully (and affordably).  This way our access
  strategies don't break just because we introduce a new class of exhibits.  It
  helps provide room for creativity and coping at the same time.

  We need headroom for finding patterns within the problems we have with
  different kinds of items.  I just asked to insert one of these generalizations
  into the glossary along with the more immediately recognizable terms.  The
  general page structure case includes sidebars as much as figures and tables. 
  The sidebar is a story within itself, but has no one logical serial place in
  the longer story in the background.  A sidebar is the same kind of stuff as
  background story, but not an ordered part of a common narrative thread.  [the
  electronic book model forces us to pick some global linear order, but this is
  not actually the semantics of the content.]  Equations and diagrams, on the
  other hand, reflect changes in the pallette of what kind of stuff can go in
  there.  We need a document and site composition model that deals with both of
  these kinds of distinctions.

  A case currently at point has to do with WCAG-required patterns of equivalence
  among content fragments, and how the User Agent should provide connected,
  related, or in-context access to these fragments [see Checkpoint 2.3 in the
  latest draft.]  The point is that while the WCAG requires the _author_ to make
  these alternatives _equivalent_ in their (after human processing)
  effect, it doesn't require the formats to provide _dedicated_ content control
  mechanisms for disability access or for 'equivalents' required under the
  It only requires the author to employ the content control mechanisms that the
  format defines, so the user will have the opportunity to tune the presentation
  to meet their needs.  The User Agent completes the strategy by ensuring that
  "content control" means "user control."

  The User Agent should give all users full control (and efficient, in the sense
  of making the relatedness of the options obvious) over the ultimate outcome of
  the content-control features defined in the formats.  The access methods
  be keyed to "content control structures," not "WCAG equivalents structures." 
  It is the former, and not the latter, that the formats define.  Content
  is actually a _protocol_ supported by option structures in the formats.  The
  user agent requirement is to make sure the user can control the end result by
  some mechanism.  It can be interactive or by configuration only or whatever. 
  See the UAAG for details.  But the point is that the user agent methods attach
  to the more general class of "content control" structures, not specifically to
  just the equivalents that the author put there for disability access reasons.


  PS:  The term 'non-linear' is too narrow.  We need to get beyond 'single
  threaded' vs. 'other.'  Most of the rhetoric of page design is "multi-linear,"
  not "non-linear."  There is more than one thread weaving through the bag of
  contents.  Almonst nothing is in there that doesn't participate in one plot
  thread or another.  Some of the pieces participate in more than one.

  >chaals (although I may have still missed your point, in which case please
  >explain again)
  >  Among terms in common use, you get a lattice, a taxonomy, and not a
  >  partition.
  >  And the concepts that we need extend up and down into abstractions and fine
  >  distinctions beyond what is colloquial, i.e. people don't _ususally_ speak
  >  terms that broad or that narrow.
  >  Our vocabulary has to include overlaps, generalizations, and
  >  and both familiar and unfamiliar concepts.  We need to connect with the
  >  redundancy of actual common usage, and relate the uncommon notions we need
  >  get on with our job well to what is already there in the common notions.
  >  We need the non-colloquial sense of 'exhibit' from the tech editor
  >  community to
  >  complete our thinking about how the layout responds, because the
  >  with algorithms should probably be at this "not so natural to say" level.
  >  It's a compromise with the small brain power of computers.  And it is the
  >  general nature of how we can actually get the idiot computers to do smarter
  >  things.  Only ask them to do things a little smarter.
  >  Al
  >  >chaals
  >  >
  >  >On Thu, 4 Jan 2001, Al Gilman wrote:
  >  >
  >  >  At 11:45 PM 2001-01-03 -0800, Kynn Bartlett wrote:
  >  >  >At 04:56 AM 1/3/2001 , Marti wrote:
  >  >  >>Regarding the use of graphics, I would like to see some changes in the
  >  >  >>terminology used.  Graphics is too generic a term and I doubt that
  >  >  >>really wants two different sizes of all the 'decorative' stuff.  How
  >  about
  >  >  >>we call the images used to augment text "illustrations" to distinguish
  >  their
  >  >  >>purpose?
  >  >  >
  >  >  >This is a good idea, as it clearly identifies a _function_
  >  >  >rather than a specific set of _formats_.
  >  >  >
  >  >
  >  >  AG::
  >  >
  >  >  Please book the term 'exhibit' into the lingo.  This is borrowed from a
  >  common
  >  >  term referring to both figures and tables, but as intended it includes
  >  set-off
  >  >  equations as well.  Just the other day I discovered that we
  >  >  logos to be in this class.
  >  >
  >  >  This serves as a superclass for illustrations and other items that enter
  >  into
  >  >  the formatting logic in a similar way.
  >  >
  >  >  Al
  >  >
  >  >  >--Kynn
  >  >  >
  >  >  >--
  >  >  >Kynn Bartlett  <kynn@idyllmtn.com>                   
  >  > 
  >  >  >Sr. Engineering Project Leader, Reef-Edapta      
  >  > 
  >  .reef.com/
  >  >  >Chief Technologist, Idyll Mountain Internet  
  >  > 
  >  m/><http://www.idyllmtn.com/>http://www.idyllmtn.com/
  >  >  >Contributor, Special Edition Using XHTML    
  >  > 
  >  html><http://kynn.com/+seuxhtml>http://kynn.com/+seuxhtml
  >  >  >Unofficial Section 508 Checklist          
  >  > 
  >  section508><http://kynn.com/+section508>http://kynn.com/+section508
  >  >  >
  >  >
  >  >
  >  >--
  >  >Charles McCathieNevile   
  >  phone: +61 (0) 409 134 136
  >  >W3C Web Accessibility Initiative                     
  >  >Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
  >  >until 6 January 2001 at:
  >  >W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
  >  France
  >  >
  >Charles McCathieNevile    <mailto:charles@w3.org>mailto:charles@w3.org   
  phone: +61 (0) 409 134 136
  >W3C Web Accessibility Initiative                     
  >Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
  >until 6 January 2001 at:
  >W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,

Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia
until 6 January 2001 at:
W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France
Received on Friday, 5 January 2001 08:26:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:35 UTC