W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2004

Re: [4.1] Overview and summary of guideline 4.1

From: Charles McCathieNevile <charles@w3.org>
Date: Sat, 24 Jan 2004 07:58:57 -0500 (EST)
To: Joe Clark <joeclark@joeclark.org>
Cc: WAI-GL <w3c-wai-gl@w3.org>
Message-ID: <Pine.LNX.4.55.0401240739570.24899@homer.w3.org>

On Tue, 20 Jan 2004, Joe Clark wrote:

>The biggie is the <embed> element. It's the only *truly* dependable
>way to call multimedia in a page. The problem? It isn't official
>HTML. Use it in your page and you will never validate. (I now cannot
>find the page in which somebody tried to make <object> work across
>every browser he [sic] had, but found the only code that functioned
>without a hitch was <embed>.)
>There are options, though.
>* The best one is to custom-hack your DOCTYPE. It's XHTML, which is
>XML, which is eXtensible. Want to use <embed>? Write a DOCTYPE that
>makes it legal.

right. The modularisation of XHTML work was done explicitly to make this sort
of thing easy. <http://www.w3.org/TR/xhtml-modularization>. Of course if you
want to use the latest technology you'd choose to write XML Schema instead.
It allows for a spcification whose syntax includes more semantic information.

>* You can also faux-write the <embed> element using JavaScript. The
>designer of OneTrueFit.com, a very nice compliant site, did that.

I guess we have different ideas about what is nice...

>>Is validity an accessibility issue?
>>The need to use technologies according to specification is a broader
>>issue than most of the guidelines in WCAG. In issue 572 as well as
>>on the mailinglist, people have wondered whether this guideline
>>should be in WCAG because they feel it's not about accessibility.
>>Others have argued that valid markup increases the chances of
>>correct rendering of the content which directly benefits
>Correct. Looking for prior art?

This was discussed (along with the other checkpoints) when WCAG 1 was being
developed. And it wasn't a new idea then, either.

>>Transitional standards allowed?
>>A certain level of backward compatibility is built in the
>>transitional variants of the HTML specification. It is not clear
>>whether 4.1 means you can only use the strict HTML specification or
>>if the transitional variants are allowed as well.
>It's worse than that. The following are both Priority 2:
>    11.2 Avoid deprecated features of W3C technologies. [Priority 2]
>           For example, in HTML, don't use the [248]deprecated FONT
>           element; use style sheets instead (e.g., the 'font' property in
>           CSS).
>   3.2 Create documents that validate to published formal grammars.
>           For example, include a document type declaration at the
>           beginning of a document that refers to a published DTD (e.g.,
>           the strict HTML 4.0 DTD).
>    11.1 Use W3C technologies when they are available and appropriate for
>           a task and use the latest versions when supported. [Priority 2]
>I think it should be clear to us in 2004 that valid code used
>semantically (a concept that's too new to have been included in WCAG

Huh? The expression of the idea might not be the best, but why do you think
there are so many checkpoints in guideline 3?

>trumps the avoidance of "deprecated" features. The fact is that
>a Web page containing deprecated features like bgcolor or my
>favourites, <small> and <big>, can still be a valid Web page and
>isn't hurting anybody.
>The three guidelines above contradict each other. 11.2 says don't use
>deprecated elements and attributes, but you can pass 3.2 by
>validating your page even if it includes them. But 11.1 will flunk
>you if you dare to use anything but XHTML 1.1!

No, they don't contradict each other. They specify things that were adjudged
to be helpful to accessibility, within the priority levels. If you want to
meet a conformance level of double-A you need to meet all of them (meeting
11.1 by using valid XHTML 1.1 automatically covers you for meeting the other

>>Clarify if transitional specifications are allowed or not
>>W3C already made provisions for backward compatibility in the HTML
>>standards by creating the transitional versions of HTML 4 and XHTML
>>1. The requirement "depricated features are avoided" is interpreted
>>by somepeople as "Only use strict HTML" for HTML documents. Other
>>people, including myself do not think that this is the case, because
>>WCAG would not require a higher level of validity than the HTML
>>specifications. If the markup follows HTML specifications, whether
>>it's HTML 4.01 transitional or XHTML 1.0 strict, you pass.

You might like to ask people who were around making the decisions what they

Or read the specifications, like experts do. HTML 4 clearly marks a number of
things as "deprecated" - they appear as such in HTML transitional, and don't
even appear in HTML strict. A priori, one would expect the definition of
deprecated to be consistent across the specifications, no?

Using HTML Transitional might allow conformance to 3.2 - and if not using any
deprecated elements or attributes also allow conformance to 11.2. It's hard
to see how it can meet conformance to 11.1

Syntactically, HTML allows documents to be constructed entirely of p elements
with bits of styling. Semantically this isn't the case, which is why a bunch
of checkpoints insisted on semantically correct conformance to the
specification. Semantically, HTML is quite happy about having all the real
content included through a flash object. WCAG is clearly not happy about
Received on Saturday, 24 January 2004 08:02:39 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:07:32 UTC