- From: Nils Ulltveit-Moe <nils@u-moe.no>
- Date: Mon, 11 Apr 2005 12:22:48 +0200
- To: Chris Ridpath <chris.ridpath@utoronto.ca>
- Cc: Johannes Koch <johannes.koch@fit.fraunhofer.de>, public-wai-ert@w3.org
Hi Chris and Johannes, I think it would be an advantage if EARL was defined with an option to be able to convey the HTML source, a digital signature of the source and also the HTTP header of the document being tested, in a similar way to what Annotea does when it wraps in the HTML annotation in an RDF description. If more than one resource is involved in the assessment, then the protocol might have the option of wrapping in all the resources involved in the assessment, and their original URL during the assessment, to be able to recreate the scenario. This would be useful as evidence for e.g. large scale automatic accessibility assertions, to show what the page looked like when it was assessed, and to show that the pages involved have not been tampered with. Having the original HTML page as evidence, is useful to detect transient faults in pages that are created dynamically. If all neccessary information is available to recreate the fault, then it will be easier both to verify that accessibility assessment tools work correctly, and it will be easier for the web designers to locate transient faults, since that should be clear from the evidence pages. Without such facilities, it will be hard for the web designers to fix transient faults that are detected by the accessibility assessment tools just by chance. I think this should be an optional possibility, not mandatory, since not all tool vendors will use this. Mvh. Nils Ulltveit-Moe man, 11,.04.2005 kl. 03.10 -0400, skrev Chris Ridpath: > > With HTTP, the content of a resource is not defined with a URL but may > > vary not only over time, but also with Accept* headers, cookies or POST > > parameters. Would it be better to include this information as properties > > of TestSubject? Should there be a way to include the content that was > > actually tested in the EARL report? > > -- > I think there's nothing wrong with storing this sort of information in the > EARL report but it still won't fix the problem of the report getting out of > sync with the content. The content of a resource, even specified with > exactly the same GET or POST properties, can change over time. The only sure > way to make sure the report and content stay in sync is to store a copy of > the content that was evaluated. > > Perhaps we could put in an EARL property for storing a URI to a copy of the > document that was evaluated. Accessibility checkers could store a copy of > each page they evaluate and then include the URI of that page in the report. > > We could also provide a provision for EARL to actually store a copy of the > page within the report. This might not be such a good idea because all the > included items like images could not be stored within the EARL report. > > Cheers, > Chris > > -- Nils Ulltveit-Moe <nils@u-moe.no>
Received on Monday, 11 April 2005 10:19:09 UTC