XHTML 2 current WD makes achieving WCAG 1.0-A compliance impossible; a proof

Dear W3C,

See what you think. Here's a proof-by-construction, with real-world live
test cases:

(1) In XHTML 2, "Working Draft 26 July 2006", the <title> element does not
permit child elements. So cases exist where it is quite possible to comply
with

a.) the WCAG 1.0 priority 1 guideline 4.1 "Clearly identify changes in the
natural language of a document's text", because mixed-language text within a
title can not be marked up correctly.

In case you think I am just pointing this out frivolously, here's a
real-world example, written by me recently. See
http://www.tosg.org.uk/turas2006-09.gd.htm . This is a page written in
lang="gd" (Scottish Gaelic) which advertises a touring theatre company's
recent tour with a double bill, two plays one with a Scottish Gaelic title,
the other with a title which is a Sanskrit word, transliterated into the
Latin alphabet. The correct markup would be to wrap those words with
lang="gd" and lang="sa", as is done in the header elements within the page
(see also the English language page
http://www.tosg.org.uk/turas2006-09.en.htm). However doing the right thing
would within a <title> would be invalid.

b.) the priority 3 guideline 4.2 "Specify the expansion of each abbreviation
or acronym in a document where it first occur" because the correct markup is
not permitted within a <title>.

(2) The same is true for all human-language text which is given in
attributes rather than elements. So meta elements, title attributes for
example may not contain mixed-language text, and comply with WCAG priority
1, nor may they contain abbreviations or acronyms marked up correctly. Given
that title attributes are provided for accessibility reasons, this is bad.

On the same page mentioned earlier, you will see that meta-data can not be
marked up correctly. I hardly need point out that various pieces of text
within attributes of child elements of <head> are exposed to users in real
web browsers. Examples include; the title attributes of various other types
of link-rel, such as link rel="bookmark" in particular, link rel="start",
most notably link-rels to stylesheets which have titles and many others.

a) take a look at the real-world example (simplified below from the one on
the site):

	<link rel="meta" title="ICRA" href="OurICRAPolicy.rdf" />

"ICRA" is an abbreviation? Acronym? Whatever, it should be expanded with
correct markup.

And forthcoming updates to the website will feature
b) <link rel="bookmark" title="Navigation" href="#nav" /> where the title
attribute's text is in a human language. This could at some point need to be
mixed-language, or contain abbreviations which should be marked up. You
already get the idea, I'm sure.


Conclusion.

Of course, this is all equally a problem for XHTML<=2.0 and HTML4.xx.

I hope you will agree that it is a crazy situation where current and
proposed future ?HTML markup standards make it quite impossible to comply
with WCAG ?.? at even its most basic level.

So. Proposed over-arching principle before yet another broken
non-WCAG-compliant markup standard gets released. Suggested design principle
might be:

(I) XHTML specifications shall not require that human-language text be
specified in attributes. All text that is in a human language or languages
shall be capable of being expressed in elements.


(II) All elements that contain human language text shall permit the use of a
single common specified set of child elements taken from a core set of
accessibility-related and language-marking elements. (To be defined.) To be
clear, no element that contains human language text shall be specified as
permitting only a text node as its child.

XHTML 2 is the only chance to get things right, since it breaks BC so
radically anyway. Don't miss it.

Looking ahead, one final real-world-ish example.

(3) My speech synthesizer, within Opera 9.0, reads the tour dates on the
above-mentioned web page as "9/11" = "nine elevenths", because I can't tell
it that this is of type "date/format=uk" (read: "9th November" for users in
Britain). It would be extremely helpful if future markup could contain
semantic or realizational hints (tbs). And no, before you suggest it, CSS is
not the way (!) a date is a semantic concept, in any case, no-one should
even be thinking about _requiring_ assistive technology to read CSS in order
not to fail.

Anyway, Markup design patterns that block these kind of much-needed
developments should be laid to rest _before_ XHTML 2.

Enough sermon for one day.

Best,

Cecil Ward.

Received on Wednesday, 11 October 2006 14:48:51 UTC