W3C home > Mailing lists > Public > wai-tech-comments@w3.org > December 2001

XHTML 2.0 Architectural/Accessibility Issues

From: Sean B. Palmer <sean@mysterylights.com>
Date: Sat, 22 Dec 2001 22:57:37 -0000
Message-ID: <02ba01c18b3c$0f7af6e0$dcbd0150@localhost>
To: <wai-tech-comments@w3.org>
Cc: "Al Gilman" <asgilman@iamdigex.net>
This is a pic-'n'-mix of issues; a summary of months of discussion in
various WAI and non-WAI fora, by various people (often Al or myself).
Since these issues are scattered aimlessly across the W3C, I wanted to
collect them up - to create an anthology.


* Listing vs. grouping vs. sectioning vs. paragraphing vs. theming
* Metadata - discrete, unary, linked
* Annotations, linking sections together
* Content of different modalities
* HyperLinks - XLink, what elements, how to type links, link eggs
* Classes, IDs, extensions. Extra semantics: action item, poem


* Listing vs. grouping vs. sectioning vs. paragraphing vs. theming

What does it mean to list/group/divide content? The flow/block/inline
structural paradigm appears to be an arbitrary out-of-date
classification mechanism created to keep the DTDs friendly. OTOH,
perhaps it's a usability issue, which is a more serious given that
people still hand edit HTML.

In particular, I want to be able to semantically categorize data
within an XHTML 2.0 document - to say when a particular section means.
The structuring is not the end-all of the situation - it is only there
to facilitate metadata association, which in turn facilitates styling
and rendering issues.

   Semantics <=> Structure => Style

It should have been made clear in XHTML 1.x whether or not to use a
group of <li> elements rather than a <p>, but it was not. In
particular, I believe that the elements of HTML are too heavily
influenced by paper documentation, where the structure of a document
is the only way in which the semantics can be predicted. If you see a
list of textlets with bullets by them, the immediate connotation is a
list. Since it's no longer 1980, I'm not particularly sure why we
should be left with such constructs.

Inline lists have been raised in many fora. This is a step in the
right direction; as Al said (something like): "elements are for what
they do, not where they go". I'd like to add that they're also not for
what they look like, or how they render in any modality. The bottom
line, as TimBL put it, is to "say what you mean, rather than what you
want done with it". More points on this subject under "Classes, IDs,

* Metadata - discrete, unary, linked

There have been many concerns over the metadata mechanism for XHTML
2.0. In general, people have argued that RDF should be used. I concur,
with a recommendation: XHTML still needs a simple metadata mechanism,
that can point out to better mechanisms.

That mechanism must be grounded in the Web. URIs must be used as link
relationships; there must be a clear mapping between XHTML 2.0 and RDF
defined. Metadata in XHTML 2.0 must not be limited - there only needs
to be enough functionality to link to some external metadata, and give
its type (which will usually be RDF).

Make sure the mechanism is extensible. If you use QNames, don't forget
to note the structure. Profile is redundant (IMO).

* Annotations, linking sections together

Following on from general "metadata", the GL group have often
expressed needs for:-

   *** Associating images with text, and stating a precise
   *** Providing annotations of content for semantic pragmatics, etc.
   *** Being able to provide labels for form mechanisms etc.

This is generally termed as "annotation". RDF provides an excellent
way to make annotations, but it means canonicalizing that link to the
metadata. It means making it as standard as rel="stylesheet" is now;
which is probably a good thing.

Annotation can also help when adding metadata about the varieties of
content of different modalities, which leads us neatly into...

* Content of different modalities

cf. http://lists.w3.org/Archives/Public/w3c-wai-gl/2001JulSep/1000
- The Alt/Object Problem

MIME types are getting to be more and more redundant (in that they
should be replaced with URIs) as time goes on, and genericity of
documents is an important factor. Consider fragment identifiers on a
document that is an audio run. The media type might be MP3, RAM, or
even an HTML transcript. The reference to "one minute into the audio"
should be the same across content types.

In XHTML 2.0, we want to make sure that the "choice not echo"
principle is observed. The "object" element is unacceptable. "switch"
is better, but XHTML should be more flexible.

* HyperLinks - XLink, what elements, how to type links, link eggs

XLink seems to be a standard, but I am not impressed with the fact
that "role" is so inflexible: only URIs are permitted. However, that's
a digression. As long as the links can be typed, that is enough.

Link eggs are an interesting principle, spotted by Al. A link egg is
where you have some context to the link, and then the actual funtional
part of the link. The context part of the egg could (for example) be
used as a title for the link, for when people using screen readers
(for example) scan through the links. "click here" becomes less of a
problem, in that light.

   <para>Try our <egg>site containing information on <a

* Classes, IDs, extensions. Extra semantics: action item, poem

If someone wants (traditionally) to ascribe extra semantics to a set
of elements, they have to use the "class" attribute. There is a
problem with that in that there is no way to define what this new
class means. It would be possible to come up with an RDF Schema that
people could follow to define what the new classes mean. It would then
be possible to retrieve this definition, using the afforementioned
metadata linking mechanism.

It would be easier if classes were grounded in the Web. QNames would
be an interesting way to do it, but I concede that there is no easy
answer. I've tried to implement each of the suggestions in previous
experiments, and all of them are ugly. But the current XHTML 1.x
solution of "class" is the ugliest.

Kindest Regards,
Sean B. Palmer
@prefix : <http://purl.org/net/swn#> .
:Sean :homepage <http://purl.org/net/sbp/> .
Received on Sunday, 23 December 2001 08:44:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:10 UTC