RE: A "one size fits all" personalized web page?

No, I am not suggesting any such thing. I have attempted to clear the air of
what seem to be peripheral misunderstandings (and I have stated clearly that
I agree that telling the user to go figure it out y themselves is a big ask)

I will hopefully have the time to make my suggestions for how to do this
tomorrow. After all, it is all very well to say "don't do X", but it is
inconsistent with my stated position that doing something a bit good is
better than not doing anything at all.

Charles

On Wed, 12 Jan 2000, Scott Luebking wrote:

  Hi, Charles
  
  I think you are not differentiatiating between strings of characters/text
  and semantic information/content.  I might be wrong, but I suspect
  that you might not have some background in certain key concepts from
  the field of linguistics/cognition.  This might be causing you not to
  understand the points I'm making about both semantic content and
  the limitations of software with regards to understanding semantic
  content on web pages.
  
  
  I suspect you might not have done a user analysis of what you are
  proposing.  What you are recommending could result in something like
  this type of greeting being set out from a campus web site.
  
      Dear freshman student,
  
      Thanks very much for signing up for your personalized web page
      at the campus administration web site.  Your personalized web page
      will provide you access to a wide range of administrative services
      and functions.
  
      If you are a blind student, the personalized web pages have no
      options to tailor the web pages to your specialized neededs.  We
      have been advised that no matter what how little computer
      technology background you have, you would prefer to take the time
      to learn the computer technology needed to tailor the web pages
      to your special needs rather than our trying to develop some
      formats designed with input from other blind students.  Towards
      this goal, we are providing courses in cascading style sheets
      (CSS) so that you can spend many hours learning this highly
      specialized technology.  Also, we are providing online a list of the
      many of classes used by the HTML in your personalized web page.
      Please remember that devoting hours to developing CSS for your
      personalized web pages will not be considered a reasonable explanation
      for not completing the work needed for your classes.
  
      .
      .
      .
  
  
  
  I'm afraid that HTML classes won't handle the problems either.
  Basically, user-side CSS is not a reasonable solution for the average
  blind user with limited computer technology.
  
  Scott
  
  
  
  
  
  
  > Scott,
  > 
  > the following is long, and addresses only the argument that there are not
  > semantics in HTML.
  > 
  > consider the following table:
  > 
  > <table>
  > <caption>Inventory of boy's possessions</caption>
  > <tr>
  >    <th>Number of books</th>
  >    <td>5</td>
  > </tr>
  > </table>
  > 
  > Which, as I understand it is a semantic presentation of the information you
  > were trying to give (see below on "visual formatting and semantics"). If you
  > consult the HTML specification it will tell you that a table has a summary
  > attribute whose content summarises the table, and a caption which "describes
  > the function" of the table.
  > 
  > Any row may have header cells, and data cells. It is possible to explicitly
  > associate the headers with each cell, to ensure complete unambiguity of the
  > semantics, but there is a specified algorithm for inferring semantics, in
  > particular how headers relate to data.
  > 
  > In simple summary we have a property of the boy, which is the number of books
  > he owns, and that prperty as a value, which is 5. That information is encoded
  > (in my example) using the avilable semantics of HTML. There is a default
  > presentation defined, although there is no reason why I coudn't write the
  > following CSS
  > 
  > tr {display: block}
  > th {display: block; float: right; font-weight: bolder}
  > td {display: inline; }
  > caption , .adverts {display:none }
  > 
  > To display the table as
  > 
  >          5    (bold:Number of Books:bold)
  > 
  > We could take a more complex table:
  > 
  > <table>
  > <caption>Inventory of boy's possessions</caption>
  > <thead>
  > <tr>
  >    <th>Types of book</th>
  >    <th>fantasy</th>
  >    <th>technical</th>
  >    <th>blue</th>
  > </tr>
  > </thead>
  > <tbody>
  > <tr>
  >    <th>Number of books</th>
  >    <td>5</td>
  >    <td>6</td>
  >    <td>7</td>
  > </tr>
  > </tbody>
  > </table>
  > 
  > Which, with our stylesheet might be rendered as
  > 
  >        (b:blue  technical  fantasy  Types of book:b)
  > 
  > 5 6 7                          (b:Number of books:b)
  > 
  > where (b: ... :b) denotes bold text
  > 
  > (for those who can't see it, the spacing is also messed up)
  > 
  > (shows the limitations of the stylesheet. Let's tidy it up a little, changing
  > it to:
  > 
  > tr {display: block}
  > th {display: inline ; text-decoration: underline}
  > th:first-element {display: block; float: right; font-weight: bolder}
  > td {display: inline; }
  > caption , .adverts {display:none }
  > 
  > 
  > giving us
  > 
  >    fantasy   technical   blue   (b:types of book:b)
  >    ~~~~~~~   ~~~~~~~~~   ~~~~      ~~~~~~~~~~~~~
  > 
  > 5 6 7                         (b:Number of books:b)
  >                                  ~~~~~~~~~~~~~~~
  > 
  > 
  > (longdesc: all headers are underlined, the spacing is wrong but the ordering
  > is correct.)
  > 
  > Now we're getting somewhere near what a table does in formatting.
  > 
  > However, for each of these examples, a conforming parser using the HTML
  > specification's specified algorithm would make the correct semantic
  > associations, and they can easily be extracted from the source. (the tablin
  > tool does that, for example).
  > 
  > I think your argument about lacking semantics in HTML is misapplied here - it
  > is true that there are semantics which are not reliably native to HTML in a
  > machine-readable way, but there also are a great deal of semantics encoded in
  > HTML in a machine-readable way. Just becuase I can't infer that a paragraph
  > is talking about the weather in Melbourne ion tuesday from reading the markup
  > doesn't mean I can't infer anything at all. In fact if the information is
  > classed sufficiently than all I need is access to the scheme used for the
  > classing (This can be expressed using RDF) and I can extract those
  > semantics. The limitation is whether the author understands the semantics of
  > what they are writing sufficiently to make them explicit, and that is a whole
  > different ball of wax.
  > 
  > But where we come to here is "the semantics of visual formatting".
  > 
  > Visual Formatting and Semantics.
  > 
  > Something most o us who are sighted take or granted is the semantics inherent
  > in visual formats. When we see a page of text, with a few lines on the top
  > right hand side, followed by a short line o fixed form, followed by some
  > paragraphs, followed by a line which is left-aligned to the center of the
  > page, we may make a numbr of assumptions. At my school (white,
  > english-language, Australian, ...) I was taught to recognise that the things
  > at the top right constitute an address, that the short line at the beginning
  > constitutes a greeting, that the paragraphs constitute the main body of the
  > letter, and that the last, off-centre line is a signature, and that the
  > document as a whole is a personal letter. (in all probability)
  > 
  > Similarly, if i see the following
  > 
  >       Inventory of boy's possessions
  >   
  >       ---------------------------
  >       |  Number of books  |  5  |
  >       ---------------------------
  > 
  > (the second line of text has a border, and the "5" is seperated from the rest
  > of the line by a vertical internal border)
  > 
  > I assume that this is in fact tabulated information, with a heading or
  > caption.
  > 
  > It is clearly wrong to assert that there are no such semantics implied. There
  > is a whole school of typographical study and communication that does very
  > extensive work on what the implied semantics are, and how best to understan
  > them and to apply them to a given situation. However, it is just as clear
  > that those semantics are not well extracted by, for example, a speech
  > synthesiser. In particular, they are not as well extracted as the semantics
  > of the table we have discussed above. (emacspeak is perhaps the best example
  > of this that is easily available - understanding tables is something that
  > developers have found notoriously difficult to implement well in non-visual
  > platforms).
  > 
  > As you have pointed out, this is not something that people always find
  > intuitive. Indeed, many authors do not understand it enough to make use of it
  > without assistance. And the way that it is presented does make a difference
  > to its comprehensibility.
  > 
  > There are, we agree, limits to the things that can be reliably expressed by
  > HTML semantics in such a way that a user can easily and reliably transform
  > them. Those semantics exist, and can be ecxtracted, but for an individual to
  > figure it out involves communicating the method the author used - in effect,
  > involves the user having access to the particular ways in which the basic
  > HTML semantics were extended. In fact the role of class attributes is to
  > extend those semantics, and the role of the tite attribute is to provide a
  > human-readable version, but that relies on high-quality user agents,
  > essentially ones which allow editing of content, for the user to get real
  > value. These things are abundant (more so than "standalone browsers", by
  > number of products) but are not widely used in that way. But the real
  > question is how to deal with extending the semantics of HTML in a way which
  > is useful to the people in the real world, and I will address that in a
  > seperate message.
  > 
  > cheers
  > 
  > Charles
  

--
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
21 Mitchell Street, Footscray, VIC 3011,  Australia

Received on Wednesday, 12 January 2000 13:37:10 UTC