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

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?

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).

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?

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.
  
> - 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.

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

Tom

> Looking forward to more discussion on this...
> 
> Regards,
>   Shadi
> 
> 
> 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

Received on Wednesday, 20 May 2009 04:26:20 UTC