- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Thu, 4 Mar 2010 09:03:45 +0000
- To: xn--mlform-iua@xn--mlform-iua.no
- Cc: www-archive@w3.org
Lief 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 The distinction may be clear to you, but the proposal as drafted appears to treat WCAG2 Techniques and Understanding WCAG2 as though: * They are part of the WCAG2 standard. * They formally define HTML semantics. * They impose conformance requirements on authors. For example, your change proposal includes the following text referring to techniques: * "How can we also not break WCAG2 H39 and WCAG2 H73?" * "H73 requires table summaries to go into a summary='*' not because authors eventually would refuse to place such content inside the caption elemetn (it doesn't discuss it from that angle), but because placing it inside caption would break the caption's table identification role, as defined in H39." * "you break the purpose of the caption – especially as H39 defines it" * "This opening 'permits' authors to break H39." * "The removal of summary from HTML5 can also be said to break H73. However, since a main purpose of H73 is to avoid that authors break H39, it is arguably more fundamental that H39 is broken." * "Authors are currently not permitted to freely place such content into the caption – not according to HTML4, and certainly not according to H39!" But this isn't the case. WCAG2 Techniques are not part of any formal recommendation, cannot define HTML semantics, are entirely informative (and therefore impose no author conformance requirements), and are an ongoing draft published without W3C endorsement. See especially the "Status of the Document" section at: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/ > This is a Working Group Note "Techniques for WCAG 2.0". These > techniques are produced by the Web Content Accessibility > Guidelines Working Group to provide guidance about how to > conform to the Web Content Accessibility Guidelines (WCAG) 2.0 > Recommendation. Techniques are referenced from Understanding > WCAG 2.0 and How to Meet WCAG 2.0. Please note that the > contents of this document are informative (they provide > guidance), and not normative (they do not set requirements for > conforming to WCAG 2.0). [snip] > Publication as a Working Group Note does not imply endorsement > by the W3C Membership. This is a draft document and may be > updated, replaced or obsoleted by other documents at any time. > It is inappropriate to cite this document as other than work in > progress. 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/ 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". The Web > Content Accessibility Guidelines Working Group considers this > document to be important for understanding the success criteria > in the Web Content Accessibility Guidelines (WCAG) 2.0 > Recommendation. Please note that the contents of this document > are informative (they provide guidance), and not normative > (they do not set requirements for conforming to WCAG 2.0). [snip] > Publication as a Working Group Note does not imply endorsement > by the W3C Membership. This is a draft document and may be > updated, replaced or obsoleted by other documents at any time. > It is inappropriate to cite this document as other than work in > progress. 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. 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. It is not necessarily a big problem (for WCAG2 or HTML5) if HTML5 makes a particular HTML technique inapplicable. However, WCAG2 conformance requirements are not the be all and end of all of accessibility. There may be HTML features that could increase accessibility without being required for WCAG2 conformance. These should be argued for in their own terms, ideally grounded in the WCAG2 principles (perceptibility, operability, understandability, and robustness). 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. 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. -- Benjamin Hawkes-Lewis
Received on Thursday, 4 March 2010 09:04:18 UTC