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

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

From: Scott Luebking <phoenixl@netcom.com>
Date: Tue, 11 Jan 2000 18:03:45 -0800 (PST)
Message-Id: <200001120203.SAA28637@netcom.com>
To: charles@w3.org, phoenixl@netcom.com
Cc: A.Flavell@physics.gla.ac.uk, w3c-wai-gl@w3.org
Hi, Charles

Please forgive my not responding sooner.  I've been down with the flu
for a couple of weeks and am just now fighting through a bad email
backlog.

I believe that a key problem is that I'm using the terms "semantic
information" and "semantic content" in ways different than I think you
and Gregory might be using it.  My use of "semantic information" and
"semantic content" is more similar to how a human-computer specialist, a
linguist, a cognitivie scientist might use the the term.

For example,

      "Le garcon a cinq livres."

      "Il ragazzo ha cinque libri."

      "El muchacho tiene cinco libros."

are statements in different languages.  The "text context" is different
in each line.  However, the semantic content or semantic information
is the same for all the lines.  The semantic information could be
represented as ~the boy has five books~ .  (Notice that I'm using the ~
to indicate semantic content or information rather than quote which
would indicate textual content.)

On web pages, there can be great variety for conveying semantic information.
For example, if there is a table:


    Inventory of boy's possessions

    ---------------------------
    |  Number of books  |  5  |
    ---------------------------

the semantic information ~the boy has five books~ is still the same
even though the presentation is different.


I believe a critical aspect of accessibility is getting to the "semantic
information" on the page.  Naive users often confuse "semantic
information" with "presentation".  They tend to focus on presentation
when frequently what is more important to them is the semantic information.
However, "semantic information" is often an abstract concept
they are either unable to work with or are uncomfortable with while
"presentation" is more "real" to them since they can read it.

The choice of presentation can make it is easier or harder to understand
the semantic information on the web page.  For some users, one type of
presentation will be easier.  For other users, another type of
presentation will be easier.  Sighted users will often do better with a
lot of visual cuing.  However, use of visual cuing will add to the
"underbrush" that blind users will have to fight through with their
screen readers.  Information presented more textually and more in order
of semantic content importance will often be preferable to blind users
as they are extracting the semantic information from web pages.

A conceptual limit in computer science is that once HTML is generated,
in general, software cannot extract the "semantic content" represented in the
HTML.  A corollary of this fact is that HTML cannot be transformed
according to the semantic content of the page.  (It is very important that
you understand this computer science limitation otherwise you won't understand
my arguement since it is a key factor in my analysis.)

Augmenting HTML via "title", "rel" or "class" is not a solution either.
Do you see why?  (Hint:  do a "step by step" analysis of the process
from the user's point of view.)


Also, look at what you are assuming about about a user's "ability to
understand what what is being given to them".  I think that a detailed
analysis will show the leaps you are making.


I believe in the diversity of human beings, including how they move
from presentation to "semantic information".  A web site which recognizes
this diversity and provides varieties of presentation with the
same semantic information makes it easier for the various users.
I believe my approach will result in web pages which are easier to use
by a wider range of users with less technical demand on them.  The software
will generally do a better job because the programmer will have a better
understanding of the "semantic information" involved than will a user.
(I believe that what I am proposing is compatible with what Chuck brought
up.)  Your approach does not recognize the issue of "semantic
content" as I've defined it, it cannot offer as many posibilities which would
be more appropriate.

I'm also getting the feeling that you might value one type of presentation
over another.  Why are you assigning values like that?  If some user finds
some presentation easier to use when moving from presentation to
understanding "semantic content", why would you assign a "lesser" value
to it?


Again, the core issue is semantic information or semantic content.  For
the discussion to make sense, we need to have the same understanding
of these terms.

Scott

PS  The example shows about web pages organized according to semantic
content or information.



> Scott,
> 
> my point about semantics in HTNML and my point about poor design being
> allowed to persist seem to me closely related. Of course there is no
> information about sports in the example you have given, but that is not an
> artifact of it being coded in HTML, rather it is that you have not supplied
> that information in the first place.
> 
> If you look through the WAI Authoring Tool Guidelines you will find code such
> as
> 
>   <a href="#def-something" rel="glossary">something</a>
> 
> which uses HTML coding to provide semantic information. The move towards XML
> and RDF are to make it easier to customise this information, but it is
> perfectly feasible and reasonably common to do it in native HTML, although
> there is a serious problem with tool developers being backward about creting
> tools that support this. You should look through the HTML specifcation for
> the attributes title, rel, and class in particular, and for elements such as
> blockquote, samp, cite (also an attribute) which are designed to code
> specific types of semantics (the class mechanism allows for the general
> encoding of semantics).
> 
> Some of the features of poor design that I am arguing against are:
> 
> departing from the notion that everything that is useful should be a
> first-class object - in short, that it is harmful if the information that one
> link is related to sprot and another is not is only available to a back-end
> engine which will release it or not based on its interpretation of user
> needs. This is a fairly central part of the way I understand Tim's design for
> the web, although it is a principle applied much more widely in general
> information systems design. This is also the major problem I have with the
> approach you have described - it takes away from the user the ability to know
> what is going to be given to them, by doing the interpreting of what they
> want for them, based on further information that is not available to them. I
> think this is also linked to the discomfort people expresed about getting a
> "different" version of content. Of course it could just be that I am
> misunderstanding the way your material is built in practise.
> 
> promoting the continued existence of sites that do not meet user needs, on
> the basis that an alternative is available. This is a repair strategy, not an
> aim. I believe that Chuck and I are expressing similar ideas, in that
> Universal Design is the goa we would like to achieve, and feel it is
> possible. At the same time, we are explicitly reognising that there is a
> danger in assuming that one answer will fit everybody - although this is the
> principle behind universal design it is only true if the desin is good, and
> that always needs to be tested more. However, the risk is not significantly
> altered if there are a couple of alternatives - as I pointed out with the
> scenarios I wrote earlier in this thread, there are a large number of
> alternative cases to be covered (which is why I think Universal Design
> principles offer the most effective and efficient approach to solvin the
> problem).
> 
> Cheers
> 
> Charles
Received on Tuesday, 11 January 2000 21:03:55 GMT

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