Re: [Moderator Action] RE: feedback on data format for WCAG-EM reports

Hi Wilco,

On 25.6.2014 16:25, Wilco Fiers wrote:
> Hi Shadi,
>
> Thanks for the fast response! Great stuff! I'll address the key issues below:
>
>> # webPage
>>    - EARL does not provide such a class -- might be good to add here;
>>    - also needs to consider the notion of "web page states";
> Wilco: I think this should maybe be a subclass of http:Response with an optional 'state' property added to it. I think that addresses both issues.

I think a web page is much more than an HTTP response. Consider a series 
of redirect and authorization exchanges until you actually receive any 
content from the server. Also a web page could pull additional content, 
for example for dynamic (AJAX) applications.

So, I think we need to think about a "webPage" resource. Maybe this 
needs to become part of EARL. I will try to propose something interim.


>> # reliedUponTechnology
>>    - maybe this should be a class too? with dct:title and a URI to any publicly available specification for the technology;
> Wilco: Excellent idea. I'll work that into the file
>
>
>> # dct:conformsTo
>>    - actually WCAG-EM results do not include conformance claims;
> Wilco: You are absolutely correct. I'll change this.
>
>
>> # additionalRequirement
>>    - could also be a list; maybe rename to additionalEvalRequirement?
> Wilco: All of these are properties of the evaluation class, so I didn't add 'eval' to any of the names. Though admittedly that makes them a bit vague here and there. I guess it's a question of consistency. I'm not bothered either way. I will leave this up to your best judgement.

Good point regarding naming.

But did you model that there may be multiple additional requirements?


>> # dct:date
>>    - what does this date stand for? is it different from dct:date in earl:TestResult class (provided for each assertion individually)?
> Wilco: This is date is the property of the evaluation. In WCAG-EM it's described as "Date for the evaluation (completion date or duration period)". I think dct:date fits this sufficiently. The date on each individual earl result in my thinking was going to be a time stamp of when it was entered. It helps to account for issues in a report that might have already been fixed before the report was completed. This occasionally happens to me and colleges.

Thanks for clarifying. Maybe good to add to the schema description too.


>> # Specifics
>>    - what is that?
> Wilco: Evaluation specifics is one of the things WCAG-EM has as an optional part of reporting. It seems to be a bit of a catch all option for evaluators to record any miscellaneous details. I could rename it to evalSpecifics, like you suggested for additionalRequirement. I am not sure if that makes all that much of a difference.

Yeah, this one seems ambiguous. Please add comments to the schema too.


>> # dct:abstract
>>    - I like reusing existing terms but I need to re-read the definition;
> Wilco: This is a summary of the evaluation for in the report.

Yup, I get that. But is DC "abstract" a good mapping? I need to check.


>> # commonPages
>>    - think this should be a list of webPage;
>> # essentialFunctionality
>>    - also could be a list;
>> # otherRelevantPages
>>    - think this should be a list of webPage;
> Wilco: The list question is an interesting one. I do not think these should be web pages. This will be part of the exploration, and I think it would be sufficient for users to provide titles or names of sections or any other kind of textual indication they can use during this step. We could allow this in webPage, but I think that wouldn't be sufficient once an auditor is defining their sample.

In WCAG-EM "common web pages" and "other relevant web pages" are pretty 
much web pages or web page states. Do evaluators typically take notes of 
such pages, then include them later on, or should we combine this?

As to essentialFunctionality, yes, this is a description ... but a list 
of such descriptions, I imagine.


> As for the lists, I think this makes sense from a data perspective. I did not do this because I don't think I want to force auditors into using some sort of widget to define lists. I think a single textarea for any of these things would be better as it would give them more flexibility.
> I suggest leaving this issue open until we figure out what we want these fields to look like in the tool and then match the output from that to the data format.

Agree. By the way, this goes back to my "scratchpad" idea -- an open 
text field where evaluators can enter notes along the evaluation...


>> # structuredSample and randomSample
>>    - maybe create an abstract "webPageSample" class for the two?
> Wilco: Makes sense to me. I haven't really looked at subclasses or anything like that. I'll add this to the file.
>
>
>> # Misc other comments
>>    - maybe also need an overall "wcagem:Report" class?
> Wilco: By report, do you mean that this would be a pointer to where the report could be found or what it's HTML would be? I can see some advantages, but I could also see some problems arising from that as it is basically a duplicate of the data in a different format. It's worth exploring though.
>
>>    - maybe package conformanceTarget, commissioner, and additionalRequirement into an abstract wcagem:EvaluationScope class?
> Wilco: Good point. I just realized there are actually two different ways the word 'scope' is used in WCAG-EM. The evaluation scope (step 1) and the website scope (step 1a). I'll better distinguish between the two. Should I then also add the website to the evaluationScope? That way you would go: evaluation > evaluationScope > website > websiteScope

Yes, we use the term twice so we need some differentiation.

Looking good...

Best,
   Shadi


> Regards,
>
> Wilco
>
>
>

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Activity Lead, W3C/WAI International Program Office
Evaluation and Repair Tools Working Group (ERT WG)
Research and Development Working Group (RDWG)

Received on Thursday, 26 June 2014 08:35:35 UTC