W3C home > Mailing lists > Public > public-wai-eo-badtf@w3.org > May 2009

Re: draft #2 report format for discussion (was Re: Report format)

From: Shadi Abou-Zahra <shadi@w3.org>
Date: Wed, 20 May 2009 09:40:50 +0200
Message-ID: <4A13B402.5090000@w3.org>
To: Thomas Jewett <jewett@csulb.edu>
CC: public-wai-eo-badtf@w3.org
Hi Tom,

Thanks for the comments, please find some responses below:

Thomas Jewett wrote:
> Hi, Shadi/all --
> I like the format -- but have comments (of course :-)
> One nit-pick: should we say WCAG 2.0 "Requirements"?
> Even though normative, the top three levels are still
> a "Recommendation" -- would that be more politically
> correct?

This is only the table header. I initially called it "Requirement", then 
added the "WCAG 2.0" in front. I see how one can misread it now, we can 
easily revert back to just "Requirement" (or something else) instead.

> One large concern:
> I don't want to get into this and have Shawn or someone
> else on the EOWG ask "what happened to the failures?"
> I personally still believe that omitting them doesn't do
> justice to the whole document. Yes, maybe this implies
> another level of expand/contract (one for failures,
> another for techniques used to fix).

Absolutely. I did not mean to imply omitting the failures by not using 
them in my draft mockup. The idea is that they would be at the same 
level of the Techniques. In other words, beneath the Success Criteria 
there could be a listing of Techniques and/or Failures depending on the 
actual context and evaluation.

> And one new thought for discussion:
> We'll have to talk about methodology in the report. For
> the moment, our only obvious procedure is to "read the
> code" -- probably not very encouraging for many
> practitioners. How can best we address this?

I think this is out of scope for BAD. We need to evaluate brute-force, 
by looking at the source code and using all sorts of other tricks based 
on what we have in the Techniques and Failures.

> Other comments follow your message:
>> - Does the indication of "Guideline", "Success Criteria" or 
>> "Technique" help identify the level of detail or is it just adding 
>> complexity?
> I think we need these (plus Failures) for clarity and
> conformance to the document.


>> - Does the inclusion of the requirement handles and Technique titles 
>> (like "Text Alternatives", "Non-Text Content", or "Using CSS to 
>> include decorative images") help people who are new to accessibility?
> Yes, definitely -- no one can memorize them all. I'm
> really hoping that we can get some automated support for
> building the list, though -- ctrl-C/ctrl-V for every
> one will be painful, to say the least.


>> - Is it helpful to have a split indication for the result of meeting a 
>> Success Criteria versus the result of meeting a Technique/Failure?
> Not sure what you mean here -- good discussion item.

The result column is split in two at the level of Techniques/Failures. 
Is that good or bad (clear or too complex)?

>> - Are the expand/collapse icons and functionality easy to understand 
>> (even though they do not currently work, can you imagine it)?
> Yes, easy to imagine, and Richard Ishida's code is
> ubiquitous on the W3C site -- should be no problem for
> anyone.


>> - Should we include the details (page and line numbers for the errors) 
>> within the table or try using the annotations approach (use an icon to 
>> link to details that are at the bottom of the page)?
> I like the idea of line numbers, with a couple of caveats:
> - the code has to be fixed in concrete before we start; even
> one line more or less will throw everything off.
> - we'll have to be clear that line numbers are in the
> UN-annotated versions; not sure the best way to do this.

Good point. That will be a pain on the long run...

> Talk to you in the morning (ok, afternoon for y'all; I get
> coffee, you get beer)...

Heh! I hope folks will leave out the beer till after the call ;)


>> Shadi Abou-Zahra wrote:
>>> Hi Tom, all,
>>> Ref: <http://www.w3.org/WAI/demos/bad/draft/2009/report>
>>> Please find a draft report format for discussion. This is only a 
>>> static mockup so none of the show/hide functions work. I hope it 
>>> gives the basic idea:
>>>  - we list conformance of the Demo to individual Success Criteria
>>>  - for each of these, the user can zoom into the Techniques-level
>>>  - there will be some "expand-all" functionality (and other toggles)
>>> What do people think of this approach?
>>> Note: for many SCs (like 1.1.1) there will be probably be a looong 
>>> list of related Failures and Techniques (probably several ones for 
>>> each Demo page). Any ideas how we could manage this? I'm thinking of 
>>> another layer of show/hide details (this time for the actual 
>>> locations). Thoughts?
>>> Regards,
>>>   Shadi

Shadi Abou-Zahra - http://www.w3.org/People/shadi/ |
   WAI International Program Office Activity Lead   |
  W3C Evaluation & Repair Tools Working Group Chair |
Received on Wednesday, 20 May 2009 07:41:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:51 UTC