W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: Reconsider SVG 1.2

From: David Woolley <david@djwhome.demon.co.uk>
Date: Sat, 20 Nov 2004 12:40:19 +0000 (GMT)
Message-Id: <200411201240.iAKCeJD03513@djwhome.demon.co.uk>
To: www-svg@w3.org

> I agree semantics would be extremely useful in some use contexts, e.g. if 
> people are intending to use SVG to replace HTML + CSS, in others, I'm not so 

I suspect that is a major growth area for SVG, especially in the mobile
market, where the lack of inclusion in out of the box Windows or Windows
Update is not a blocking factor, and there isn't a large body of HTML 
hacks for cut and paste coders.

My impression is that many commercial web designers only think visually,
and therefore try to use HTML+CSS as a page description language, not
a document language.[A]

It is the HTML type uses that tagged PDF addresses, but there is a whole
spectrum of uses of (near) final form graphical presentation languages,
nearly all of which have semantics attached to them that is deeper than
what is represented in the graphics metafile.

Technical diagrams often have very strong topologies that are lost
in low level graphics languages.  Business graphics have underlying
real data sets.  Maps have strong topologies, but final form graphics
may end up separating labelling from symbolic and topographic layers.

> sure.  Ultimately, SVG could be considered accessible without semantics. 
> Users extracting meaning from visual parsing of the displayed document have 

With suitable AI, so would JPEGs.  Also, the whole point of most use of
graphics is not the graphics themselves but that they make it easy to
convey information (or, in the commercial world, emotional messages[B]).
They are also used to achieve instant recognition (logos, and branding
in general).  If accessibility depends on describing the detailed structure,
that benefit is lost even more than if the information hadn't used grphics
in the first place.

> learnt to infer meaning from various visual attributes, the same goes for 

This, itself, is a serious accessibility issue.  There are many users,
especially the elderly, and those in their middle age that haven't been
brought up with computers, who haven't learnt, or can't[C] learn, the many
graphical metaphors used on the modern web, even when observing them
through their eyes.
> pretty much any form of communication.  Therefore, provided those visual 
> attributes can be conveyed non visually, there's no reason why a blind user 

Semantics helps not just the blind and can help ordinary users.  In particular,
it allows machine processing (which may have negative commercial impact, of

> couldn't associate meaning with the attributes.  Using current output 
> modalities that are sequentially based, such as speech or Braille, this will 

One has to serialise even bitmap graphics for computer uses, but proper
encoding of semantics doesn't constrain one to linear presentations.
If one looks at an old feature of PDF, called bookmarks in PDF
terminology, but I would call it an outline tree.  The well marked up
HTML and CSS specifications allow this to be derived by the html2ps tool
used to set the PDF versions of those specifications.  The result is that
you can quickly navigate the document structure.  This use of proper
markup is also used by some minority HTML browsers.

Another possible use of good semantic markup would, in the case of a web
application, be the ability to overlay standard forms of user interface
controls onto the custom designed controls, so that people without a 
long education in web design conventions didn't need to decipher the
design metaphor to find and use them.

> be a long and tedious process that would make SVG, whilst accessible, not 
> very usable, so semantics can play a big part in boosting the usability of 
> SVG.
> As an aside, it's down to the ua and authoring tool vendors to ensure their 
> products are 508 compliant, but having accessibility included as part of the 
> spec would help tremendously in this effort.

508 provides a regulatory environment which forces businesses to take account
of such issues, but it is not the only such legislative framework and the need
of users (if not authors) would exist without it.  Other parts of W3C have
typically taken more than a bottom line view to what goes into specifications,
e.g. features that conflict with the creation of a world wide web are
discouraged, even though commercial authors like them, and few commercial
sites want anything but incoming links to home pages.

The problem with SVG is that, to a large extent, it "externalises" the issue
by saying you should use a higher level markup and transform client side, but
ignores the reality that most authors will just send the SVG and in HTML
replacement applications, will likely have not authored it with tools that
represent the semantics, or failed to use the relevant capabilities of such

The HTML+CSS model is to decorate a more semantic model with presentational
details.  The tagged PDF approach is to decorate a presentational form 
with semantic data.  To a large extent, SVG is presentation alone.  That's
almost OK as a technology, but the reality is that SVG is being developed
as a product (in my view, as a way of competing with Flash[D], even though
Flash now has SVG support), and users are using it as a single technology

[A] I think this is largely because commercial web pages are, very often,
    advertisements of the non-informational type and are created by people
    with visual arts training, not with verbal communication training.

[B] These are not good candidates for semantic markup as they are often
    not objectively justifiable, so cannot safely be stated explicitly.

[C] Reasons, in the elderly, can vary from a fairly common fear of making
    mistakes and getting lost, to degenerative diseases of the brain.

[D] People will argue that SVG is used for more technical graphics than
    is Flash, but I think that is more to do with how Flash is marketed and
    I think the big growth area in SVG will be commercial art, not technical
Received on Saturday, 20 November 2004 12:41:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:52 UTC