Re: "tableinfo" Change Proposal and status of WCAG2 supporting documents

Added CC to public-html-a11y@w3.org

Benjamin Hawkes-Lewis, Thu, 4 Mar 2010 09:03:45 +0000:

Online version of Benjamin's original letter: 
http://lists.w3.org/Archives/Public/www-archive/2010Mar/0011


> With reference to the HTML5 Change Proposal you've drafted to
> introduce a "tableinfo" element:
> 
> 
http://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/tableInfoProposal&oldid=5010 
> http://lists.w3.org/Archives/Public/public-html-a11y/2010Mar/0077.html


   [ ... ]

> Similarly, you cite:
> 
> 
http://www.w3.org/TR/2008/NOTE-UNDERSTANDING-WCAG20-20081211/content-structure-separation-programmatic.html

> 
> as "WCAG2". It isn't. WCAG2 is the Recommendation here:
> 
> http://www.w3.org/TR/WCAG20/


Let me quote the WCAG intro: <http://www.w3.org/WAI/intro/wcag>

]]What is in WCAG 2.0
WCAG 2.0 has 12 guidelines that are organized under 4 principles: 
perceivable, operable, understandable, and robust. For each guideline, 
there are testable success criteria, which are at three levels: A, AA, 
and AAA.[[

I also feel tempted to cite HTMLwg co-chair Sam Ruby:

]] This has lead to a Wonderland debate about what HTML is. [[

http://intertwingly.net/blog/2010/02/18/Adobes-non-Formal-non-Objection


You want to have a wonderland debate about what WCAG2 is. However, I 
don't want to participate.

> You're quoting from Understanding WCAG2. If we look at the Status
> of the Document we find:
> 
>> This is a Working Group Note "Understanding WCAG 2.0". [...]

May be you are aware of the fact that in the interpretation of a law, 
the parliaments preparatory documents are often important?

> Understanding WCAG2 includes a helpful appendix with suggestions
> about how to cite WCAG2 and supporting documents:
> 
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/appendixA.html

> 
> Note especially:
> 
>> Techniques, which are listed in Understanding WCAG 2.0 and
>> described in other supporting documents, are not part of the
>> normative WCAG 2.0 Recommendation and should not be cited using
>> the citation for the WCAG 2.0 Recommendation itself. References
>> to techniques in support documents should be cited separately.

Having listened to your insinuations about what you present as a 
justifiable interpretation of concrete expressions in my change 
proposal: What do you imagine yourself that this quote is telling us? 
That one should not ever quote the WCAG techniques? The only thing that 
is possible to read out from that quote is that what is directly stated 
there. Namely, one should not cite or present those techniques as is if 
they are taken from "the WCAG 2.0 Recommendation itself". I have not 
broken that rule. (Can I even - according to you - break it? It is, 
after all, just something said in an appendix ... )
 
> It *is* a big problem (for WCAG2 or HTML5) if HTML5 makes it
> impossible for authors to create content that conforms to both
> WCAG2 and HTML5. So the question of actual normative conformance
> requirements versus informative guidance is significant.

I am member of the HTMLwg, and I look at concrete proposals. The 
techniques are very useful to me because they are concrete application 
of the WCAG REC, applied on a problem governed by a concrete 
specification - HTML4. If you can point to anyplace where H39 and H73 
breaks HTML4, then please tell us. (I personally sense a some what 
stricter interpretation of what a table summary and a table caption is, 
in those WCAG2 techniques, than in HTML4 - and I have also tried to 
make this clear, in the debate - in fact, it is at least indirectly in 
my change proposal.)  WCAG 2.0 [I did not say "the REC"] H39 and H73 
specifically point to what HTML4 says about <caption> and @summary. But 
makes a point about saying that it does so "for information purposes 
only, no endorsement implied". So WCAG2 does not endorse HTML4. 
Nevertheless is it written within the boundaries which HTML4 defines.

I completely refuse to lead an accessibility discussion about two HTML4 
features - <caption> and @summary - without understanding both HTML4 
and how HTML4 have been understood, by WCAG2 and elsewhere.

> It is not necessarily a big problem (for WCAG2 or HTML5) if HTML5
> makes a particular HTML technique inapplicable.

My suggestion about a <tableinfo> element means that WCAG H39 and H73 
must be updated (I say so in the proposal), so i don't see how you 
bring anything new to the table here.

[....]
> So I suggest redrafting your proposal to make it clear where your
> argument depends on clear WCAG2 normative requirements, where it
> depends on debatable interpretations of those requirements
> informed by Understanding WCAG2, and where it depends on wider
> purported (and ideally documented) accessibility benefits.

I am sorry, but this is a bit too lofty for me. If you have concrete 
issues, then please bring then on the table.

> In terms of what WCAG2 does require, I'd note that while WCAG2
> does prefer programmatic identification of relationships, this
> does not mean every relationship requires its own HTML feature.
> For example, a verb has a relationship to the rest of a sentence,
> but this does not mean WCAG2 necessitates the addition of
> "sentence" and "verb" elements to HTML. There has to be some sort
> of judgement call about how useful a particular relationship - or
> distinction between relationships - is.

A finally something almost concrete. And what do you build these 
statements on? Can you point to WCAG2 - perhaps even to the REC - to 
underline your points about judgement call etc?

The Understanding WCAG2 section that I cite is pretty clear: One should 
strive from programmatic identification. Why do *you* think that the 
part from Understanding WCAG2 which I cite in the Change Proposal, says 
that it might be a judgement call whether to *both* have a table 
summary right before the <table> as well as inside @summary? (I am sure 
that you see the underlying problem: it leads to duplicate information.)

Here is my interpretation of why it says so: @summary is not well 
enough supported/implemented. Support for <caption> is much more 
universal.  Another interpretation is that specifically duplicating the 
table summary like this might not be of too much harm (it might in fact 
be more good than harm - I could well imagine that).

Besides, you seem to forget that HTML5 already allows block level 
content inside <caption>. This means that HTML5, as it stands, allows 
what you refer to as "programmatic identification of relationships" - 
just place into <caption>, and voila. Should I read what you say here 
as if you are against what HTML5 currently says on this?

Btw 'programmatic identification of relationships'? I have not used 
that term. It seems like you are mixing two subjects: the subject of 
programmatic determination and the subject of identification. I talk a 
lot about 'table identification' in the CP. If you stuff the <caption> 
with lots of explanatory material, then it looses its identification 
role. That's the whole point of my proposal.

Thus you seem to ignore that the point in my change proposal has little 
to do with programmatic identification - HTML5 solves that problem. The 
issue in my change proposal is the role of the <caption>. Everything 
else in my proposal is derived from that. Both @summary and <tableinfo> 
are means to separate the explanatory content from the table 
identification string - the table caption.
-- 
leif halvard silli

Received on Thursday, 4 March 2010 12:29:49 UTC