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

Hi all,

Ref: <http://www.w3.org/WAI/demos/bad/draft/2009/report>

Please find an updated draft report format for discussion. I have some 
specific questions for input:

- Does the indication of "Guideline", "Success Criteria" or "Technique" 
help identify the level of detail or is it just adding complexity?

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

- Is it helpful to have a split indication for the result of meeting a 
Success Criteria versus the result of meeting a Technique/Failure?

- Are the expand/collapse icons and functionality easy to understand 
(even though they do not currently work, can you imagine it)?

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

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
> 
> 
> Thomas Jewett wrote:
>> Sounds good -- I think that assumptions will fit
>> well in the introductory part of the report, with
>> SCs/failures/techniques as the main section.
>>
>> One reason that I separated out Failures is that
>> they have their own checks, which are essentially
>> the reverse of the Techniques checks although
>> less specific. I think this is a bit of overkill
>> in the document, but again I'm trying to illustrate
>> use of the standard (as written) to the max extent
>> possible.
>>
>> Cheers,
>>
>> Tom
>>
>> On Thu, 07 May 2009 09:00:37 +0200
>>  Shadi Abou-Zahra <shadi@w3.org> wrote:
>>> Hi Tom,
>>>
>>> I'm not sure that it is only the Failures that we want to list to 
>>> show that a Success Criterion has not been met. We can also show 
>>> Techniques that have not been implemented, so that conformance with 
>>> the Success Criterion could not be demonstrated. Having said that, it 
>>> seems that we we'll need to clearly state the assumptions under which 
>>> the evaluation took place (including mentioning Accessibility 
>>> Supported Technologies).
>>>
>>> I'll work on a draft format based on your input below for discussion.
>>>
>>> Thanks,
>>>   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 Monday, 18 May 2009 08:19:59 UTC