- From: Charles McCathieNevile <charles@w3.org>
- Date: Fri, 27 Oct 2000 11:23:20 -0400 (EDT)
- To: Timothy Stephen Springer <timsp@ssbtechnologies.com>
- cc: WAI ER IG List <w3c-wai-er-ig@w3.org>
Hi all. I put together a sample XML file of conformance to specs as one of the form field values at http://www.w3.org/1999/11/11-WWWProposal/atagdemo in the form of RDF. The simple schema outlined there can be readily adapted (I have an action item from somewhere to do it, and there was a thread here on how to) and can already be used to specify a lot of the stuff required, by making the conformance statements refer to AERT URIs instead of ATAG checkpoints (as in my example) or just being XML statements (as in Chris') Because this stuff is metadata, and uses URIs as pointers it doesn't need to involve editing the document itself at all. Charles McCN On Wed, 25 Oct 2000, Timothy Stephen Springer wrote: All- I have put together a short set of ideas for a what a possible XML evaluation document could look like. To begin the conversation here is a quick proposal of what such a document could look like: <?xml version="1.0" encoding="UTF-8"?> <!-- PI if we want to define a DTD / schema for verification --> <PAGE url="http://www.yahoo.com"> <VIOLATIONS priority="1" total="optional"> <VIOLATION key="foo" total="optional"> <ELEMENT line="optional"> <!-- XHTML opening tag for element --> <IMG src="here" alt="Wretched Alt" /> </ELEMENT> </VIOLATION> </VIOLATIONS> </PAGE> Primarily I would suggest initially limiting the scope of the evaluation document to capturing data relating solely to the violations for a particular page, rather than combining the page itself and violation data. This will limit the scope of the document, solely to evaluating the accessibility of a page. The reason I would give for this is that the response we [SSB Technologies] have been getting from the market is that developers seem to want evaluation independent of repair. For most sites that have dynamically produced content evaluation and repair are very distinct issues and data portability between the two has limited appeal. If we preserve the original document state we are assuming that doing so will allow us to create separate evaluation and repair tools that use XML to transport data between. My experience, however, has been that the vast majority of web developers consider evaluation and repair separately. Thus a schema that combines the two may well just add more unnecessary work. When evaluating a document the developer wants to know what the issues are. They want summary reports and information sorted by priority. Evaluation data should answer the questions: 1.What must I do? 2.In what order must I do it in? To this end a document that orders violations linearly by way of the original HTML v. by priority weakens our ability to address these questions succinctly. Concretely assuming we create an XML evaluation file [XML of the form proposed by Chris] that maintains a version of the original HTML document. With that document one cannot produce priority ordered or summary reports via XSLT. This is due to the current constraints of XPath and XSLT. (I won't get into the why of this here but would be happy to discuss it off the list). Whereas if the evaluation document is focused on report production (which is what I think the demand is for) such a report can be produced. With that said I must admit that a solution that retains the original document would be the most elegant. While I think it may not be *totally* necessary it does seem to be the best solution. My only concern would be that in preserving the original document we retain a way to extract "reporting" information from the underlying XML doc via XSLT. The second issue I would like to address is the DTD / schema for the document. I believe that it is important that all evaluation tool makers should be able to extend the document to export custom data. To this end it is important that we maintain an unrestrictive document. I am not well versed in DTDs or XML schemas to know the technical language for this but my proposal is simple. Define a base set of required elements & attributes but allow tool authors to add additional elements & attributes while maintaining a valid document. The third issue is that of having a particular unique identifier for each possible violation. I am open to this however there are some important considerations. Primarily we currently divide the WCAG based on the underlying architecture of the program. To give an example our program flags "Images without alt attributes", "Images with null alt attributes" and "Images with suspicious alt attributes" all as different violations. We do this because it gives the most detail to our clients as well as mapping to our programmatic architecture. Is this division dictated by the W3C? No. Are we altering the WCAG in doing so? No, just being practical in our approach to dividing it. So what does this mean? It means that the division of violations can be subjective based on underlying programmatic architecture. Thus if we get into the business of assigning particular violation identifiers we have to be careful to either make them: 1. Map to the architecture of evaluation engines or 2. Independent of the architecture of evaluation engines Going the later route means that we will have to be less specific, obfuscating the nature of the problem. Going the former means that we are writing practical specifications and we may have to make tradeoffs based on current technical feasibility. Pursuant to the above, another question arises from defining specific divisions of the WCAG. Who should maintain the text that describes the violation? I envision these descriptions in the vein of those included with Bobby and A-prompt. I would prefer that the W3C maintain descriptions of violation problems. The idea being that if the W3C maintains the descriptions it will avoid re-writes of the guidelines that could "weaken" the accessibility violation. To give an example company eAccess (I have no idea if this is a real company. Hope note) builds an evaluation product that tests all of the WCAG. They profess to be compliant with the WAI but include their own descriptions of accessibility. For IMG alt violations their descriptive text mentions that "page authors should include alt tags only if they feel like it, or on every other Tuesday." Obviously an extreme example but I believe tinkering with the wording of the violations should be out of the hands of companies trying to evaluate accessibility. Finally (sorry this is so long) it makes sense to store the elements in the evaluation document (however that ends up) in XHTML. The arguments for this our fairly simple: 1. It is a more accurate representation than storing them as CDATA 2. It should be fairly easy to do with an evaluation engine that builds a DOM (Document Object Model) 3. It will speed adoption of XHTML Okay that's it! I have attached to this e-mail copies of the proposed XML file as well as a copy of the XML we currently produce with InSight (our evaluation engine). While by no means complete they should both be good food for thought. TimS -----Original Message----- From: w3c-wai-er-ig-request@w3.org [mailto:w3c-wai-er-ig-request@w3.org]On Behalf Of Chris Ridpath Sent: Monday, October 23, 2000 8:52 AM To: WAI ER IG List Subject: Evaluation Results In XML We have been working on a means of storing the accessibility evaluation of an HTML document. Our current approach is to store the evaluation in an XML document. The XML doc contains the original HTML with any accessibility problems marked with new XML elements. For example, the following snippet contains the evaluation of an IMG element that is missing the 'alt' attribute: <problem problemName="MISSING_IMG_ALTTEXT" problemID="1234"> <![CDATA[ <img src="rex.jpg" longdesc="rex-desc.html">]]> </problem> The XML file that contains the above evaluation is attached to this message. Each accessibility problem is given a code number so it may be referenced. A report tool can take the XML document and prepare a report of accessibility problems. A repair tool can take the entire document, or pieces of the document, make repairs then update the original XML document. The original XML document can be easily converted back to HTML by XSLT or a simple program. If the group can agree on a set of specifications then all tool makers can generate and use the same XML evaluation document. Comments? Chris -- Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 134 136 W3C Web Accessibility Initiative http://www.w3.org/WAI Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia September - November 2000: W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France
Received on Friday, 27 October 2000 11:23:42 UTC