- From: Barry McMullin <mcmullin@eeng.dcu.ie>
- Date: Wed, 17 May 2006 16:57:26 +0100 (IST)
- cc: "EOWG (E-mail)" <w3c-wai-eo@w3.org>
On Mon, 15 May 2006, Andrew Arch wrote: > The following are DRAFT comments and discussion raised during the EO > teleconference of 12 May 2006 in regard of various WCAG 2.0 documents. > Feedback is sought from EO members before they are finalised for submission > to WCAG working group. Hi All - Apologies again that I have been unable to participate in the teleconference discussions. Many thanks to Andrew and Judy for synthesising these draft comments. Overall I think they are very clear and very helpful/ I have some slightly more substantive reaction to just a few of them, as follows: > 1. Conformance to WCAG 2.0 > * http://www.w3.org/TR/WCAG20/conformance.html > > 1.1 Comment: In the discussion of baseline and conformance EO has concerns > about the potential for misuse [e.g. authors can just declare their own > level of technology such as requires CSS2 and JavaScript 1.2. The > actual/potential audience, not just perceived/target audience or what > developers wish they could reply on, should define baseline. Minor typo: "reply" -> "rely" > 1.2 Comment: To achieve this EO suggests several strategies A) to give > guidance on what is a realistic baseline for most Internet sites today, W3C > should publish a ‘reasonable/realistic’ baseline recommended for a general > audience; B) update this ‘recommended’ baseline annually; C) place the > 'recommended' baseline outside of the WCAG 2.0 normative document; D) > provide an explanation about why the particular baseline is recommended This is a reasonable suggestion. However, it is obviously politically problematic because it potentially involves W3C in effectively endorsing some non-W3C technologies and not others. This is further complicated by the fact that W3C itself has much of the character of a vendor organisation. So ... I can quite see why EOWG members might suggest this, but I personally feel it may be taking W3C outside its appropriate role. But still, by all means, let us submit the comment and hear what the WCAG WG makes of the suggestion. A slightly different - but closely related point: Presumably, once WCAG 2.0 is finally approved, W3C will want to claim that w3c.org conforms to it? And that being the case, W3C will need to publish at least one *example* of what they currently think a "reasonable" baseline is. So perhaps that could be published even now? In any case, quite independently of specific baselines, I suggest that WCAG 2.0 itself needs to make *some* clearly normative statement(s) about what criteria a technology must meet before it would be eligible for inclusion in a baseline. Specifically, I *think* this sentence might have normative force, but this is less than clear: It is possible to conform to WCAG 2.0 using both W3C and non-W3C technologies, as long as the technologies are supported by accessible user agents, including assistive technologies. I would suggest something more like: All technologies specified in a baseline must be supported by accessible user agents, including assistive technologies. I think this means the same thing, but is more clearly normative (uses the "must" word!). Of course, it still begs questions as to what is the force of "supported", but at least it would make clear that one cannot include something in a baseline *completely* without reference to the availability of accessible user agents. Even less clear in the current text is whether there is any normative requirement for the availability of accessibility "techniques" guidance for all technologies included in a baseline. This is formally slightly tricky because the one example WCAG 2.0 techniques we have is explicitly *not* "exhaustive" - that it, while applying its recommended techniques implies meeting the success criteria, the converse does not apply. That is, there may be other ways of meeting the success criteria, apart from those in the current techniques document. This is probably unavoidable (i.e., it probably is not possible to enumerate *all* allowable techniques for most technologies of interest); but it does mean that a cynical technology provider could create an "accessibility techniques" document for a new technology, that is, in fact, completely inadequate. Nonetheless, I suggest that WCAG 2.0 should include *some* kind of normative requirement that for any technology included in a baseline, there must exist *some* form of "accessibility techniques" document that offers "reasonable" coverage of all applicable WCAG 2.0 success criteria that would be "comparable" in detail to that provided by W3C for W3C technologies (and yes, I know that "reasonable" and "comparable" are yet more weak and ill-defined words; but some requirement along these lines might still be a lot better than nothing...) > 2.2 Note: Send EO complement to WCAG working group on the detail in > “Understanding” Typo? "complement" -> "compliment" (At least in "British" English ... maybe American is different?) > 3. Checklist for WCAG 2.0 / Appendix B: Checklist (Non-Normative) > * http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixB.html > > 3.1 Formatting: the caption for each table (guideline number and title) does > not display in Opera 8 > > 3.2 Comment: Remove the ‘mouse-over’ highlighting colour - adds confusion > > 3.3 Comment: Change ‘L1’ to ‘Level 1’ etc, and add a heading of ‘Level’ to > the first column > > 3.4 Possible comment: In the ‘blurb’ explaining what the Appendix is for - > explain that it is intended that you can save he document and add comments > to the fourth column as a report. Alternatively, provide a simpler table and > also a downloadable (RTF) document for evaluation reporting and annotation > purposes Um ... is it just me, or does anyone else find it peculiar for EOWG to formally advocate the use of RTF technology in this context? Is there some accessibility advantage of RTF over HTML? (At first blush, I would *not* have thought RTF would be a candidate for inclusion in any WCAG 2.0 baseline - would it?) Well, that's my tuppence worth anyway. Best - Barry.
Received on Wednesday, 17 May 2006 16:00:10 UTC