This is a good start, but we need more granularity in an ER tools. For example we can say, "element X meets checkpoint 1.1." in the terms of their scheme it would be, "<conform:meets rdf:resource="http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505#text-equivalent"/>
However, if it does not, we also need to say why. For example, "text equivalent is a filename" or some of the other heuristics "flags" we've created.
But, we could make claims based on AERT or actually, it's the technology-specific checkpoint-type of things that we've discussed for WCAG 2.0. For example, in WCAG1.0 we have Checkpoint 1.1: Provide a text equivalent for every non-text element. The specific checks under that should be:
What a text equivalent should not contain:
Text equivalents may contain:
If each of these points are given a URI, then someone could claim, I have provided alt-text and it meets checkpoint 1.1 b/c it "communicates the same info." or an evaluation tool could say, the text equivalent contains a file name and therefore most likely does not meet checkpoint 1.1.
Therefore, the conformance scheme should also contain the idea of "suspicious." So that evaluation tools can flag suspicious things that need manual checks.