Re: Terminology

Hi, Charles

I'm not sure we are using semantic information in the same way.
Blind users would find a web page helpful where links are in order
according to most likely to be used.  Given an arbirtrary wen page,
no software could order the links according to frequency of use.
The software would need to know the purpose of each link, but would not be
able to figure that out from the HTML.  This is an example
of semantic information which is lost when semantic information is
encoded into HTML.

Remember I'm proposing that different formats be made available
for dynamically generated web pages.  This helps reduce the amount
of work needed.

How many different formats do you think are needed?

Given ease of use versus the frequency of talking about the same page,
which do you think is more important?  How often do people talk about
particular web pages as compared to actually using the web pages?
My suspicion is that people spend much more time using web pages
instead of talking about them.  It would seem to make more sense
to optimise for ease of use than ease of communication.

The example I've put up comes from talking with blind users and
seeing what their needs are for working with web pages.  In the
original version in my example, a table is used so that the results
are nicely lined up to be visually appealing.  Blind users don't
need that type of formatting and there's not a strong reason
for their page to be in a table.  Web pages which are organized
so that the most important information comes first benefits blind users.
Creating a similar order of importance is not as easy in a visual
situation since the media is two dimensional rather than the one
dimensional experienced by users.

Scott

> There is in fact a great deal of semantic information that can be extracted
> from HTML if it has been encoded, but there are a lot of visually oriented
> designers who are sufficiently bloody-minded about the importance of visual
> presentation that they will hard-code the "underbrush" into content while
> leaving out the semantic information that would make their page useful across
> different hardware and software setups.
> 
> It is true that there is a limit to the amount of information that can be
> extracted from the current versions of Explorer, Opera, Netscape, Neoplanet,
> Doczilla and Lynx. Structured browsers can provide more (e.g. Amaya) but more
> still will be available when RDF and XML are implemented and shippable (in
> part this is not really possible, because the XML linking mechanism has not
> yet been finished).
> 
> The idea of providing a non-graphic version which has been optimised is not
> intrinsically bad. The idea that this restructured view of a page, and a
> completely unstructured view as propogated on the web today adds up to
> accessibility is wrong, for the reasons I outlined in my previous message on
> the topic. In order to make this approach work to provide accessibility the
> workload increases to provide various different presentations optimised for
> various groups, and becomes isolating to the extent that different groups of
> users are not getting the same page and have difficulty in talking about what
> is ostensibly the same thing in a way that other groups can recognise.
> 
> I would suggest that you are doing a good job on presenting the page to one
> group of users, but that it would be more profitable to focus your efforst on
> the original page.
> 
> As a visual user I perfectly understand the visual imperative for
> communication. My basic training in Graphic Communication also gives me an
> understanding that there is more to it than having a lot of fancy images -
> there are plenty of examples of visually designed and visualy appealing but
> almost unusable sites out there. Those just demonstrate that it is possible
> to do a bad job in many media at once as well as to do a good job. I would
> encourage you to continue with the approach of having a site which a
> primarily visual user is comfortable with, but I would encourage you to turn
> some of your talent to making that version itself better for users.
> 
> Charles McCN

Received on Monday, 20 December 1999 00:50:41 UTC