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

Hi Cecil,

No problem with your sermon. :) But you are preaching to the
converted...everything you describe has been part of our 'guiding
principles' in XHTML 2 for a very long time. The place to look for
what you are talking about is in the new metadata features. We've put
a lot of work into these--in particular, coordinating with the RDF
community--and we feel that they help in a number of areas, such as
device independence, accessibility, internationalisation, and more.

In the new metadata story for XHTML 2, the following are now equivalent:

  <div carrot="lettuce">
    ...
  </div>

  <div>
    <meta property="carrot" content="lettuce" />
    ...
  </div>

  <div>
    <meta property="carrot">lettuce</meta>
    ...
  </div>

As you can see, the third technique gives you exactly what you want.

Note that I've carefully avoided giving an example closer to the ones
that you posted, since although the metadata part of XHTML 2 (called
RDFa) is nearly complete, some subtle issues remain, and I think they
lie in the same space as your mark-up. I'm thinking here about
reification, and whether the following equivalence would be possible:

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

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

In the current drafts of RDFa this *is* possible, but there are strong
arguments for getting rid of this type of construct altogether.
However, I'm going to feed your use cases back to the RDF-in-XHTML TF,
as something that we need to be sure can be supported. (It would be
great if you joined that list, and I've CCd them.)

Embarassingly enough, I have an outstanding action item on the HTML
WG, where I was supposed to write up how @rel="bookmark" could take
advantage of the internationalisation features of RDFa, and I have
never got round to it! You have prompted me to do so.

Anyway, I think the key point is that XHTML 2 *is* going in the
direction that you are advocating, and your use cases must be fed into
the thinking that is going on around trying to solve the few remaining
RDFa issues so that we can be sure we don't lose important
functionality.

Regards,

Mark

On 11/10/06, Cecil Ward <cecil@cecilward.com> wrote:
>
> 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 23:29:01 UTC