Re: Requirements for Accessibility Description Language (ADL?)

Len (and ERT IG/WG et al.),
I had a look at your original ADL post
(http://lists.w3.org/Archives/Public/w3c-wai-er-ig/2000Nov/0018.html), which
is one of the things you invited me to participate on (thanks!). I found it
highly interesting, and am publishing my initial ideas about it here, for
the benefit of yourself and the ERT members, of which I am very pleased to
be a part of :-)

> - what shall we call this?  How about "Accessibility description Language"
> (ADL). To which of the following should it apply?
>     XHTML,  Any XML application, e.g. SVG?
>     HTML, HTML with syntax errors (what severity of errors can be
>       allowed?)
>     CSS,  ECMA Script,Other programming languages
>     CDATA
> What level should description point to?  Characters? Tokens? Tags?
> ("tags" is html and xml specific... what about other parsable languages?)

ADL on the face of it is IMO a good solution to the problems faced by this
group, in that it could in theory provide a descriptive logic based "pointer
and validation" language for WCAG.
Unfortunately, although in theory you would want it to be able to point
to/describe absolutely anything, the sad truth is that that is only possible
in XML languages: XHTML, SVG, MathML, etc. The reason is that although
CSS/JS/HTML and so on *are* parseable, the applications for doing so are not
geared up for this sort of processing. Well, CSS and JS aren't (however, see
[1]), but in HTML it may be possible, because it can be readily converted
into XML, and can use IDs etc.

You *could* make a language that points to CDATA, something like:

       content:"[CDATA here]", ADLrule:"[ADL rule here]"

But we would have to add cascading rules, etc., because you would have to
have complex descriptions such as:

       content:"any word:"and" that is adjacent to word:"will" but not
       charstring:"hasn't"", [...]

This would get increasigly, and eventually overly complex: you would have to
have a different set of rules for each language. The specification would be
bigger than XML, XHTML, and CSS combined! It would also require AI type
logic for complex languages and dialects etc.

My thinking is that you/we could simply write an XML/RDF description
language, i.e. ADL could be an XML subset (or rather, an RDF language, like
Dublin Core), exploiting the features of XLink, XPointer, and RDF. It would
be *easy* to write such a language up, if we (or rather I, as you already
know) what you require from it.
In fact, I have already suggested an XML namespace for WCAG
affirmations/assertions on WAI IG. For example, I wrote:
[[[
In RDF:
<rdf:RDF xmlns:dc="http://purl.org/DC"
     xmlns:wcag="http://www.w3.org/2000/wcag"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
<rdf:description rdf:about="http://rdf.pair.com/xchecker.htm"
     dc:title="Checkpoint Checker"
     dc:description="W3C WAI WCAG 1.0 Checkpoint Checker"
     wcag:version="1.0"
     wcag:level="AAA"
     wcag:proselevel="Triple A" />
</rdf:RDF>
The xmlns:wcag namespace is just an example: the WAI would have to create a
real and suitable one.
]]] -http://lists.w3.org/Archives/Public/w3c-wai-ig/2000OctDec/0324.html

Where wcag: is the namespace for ADL, or whatever (if it is going to be a
RDF element set/langauge, perhaps ADML would be better - Accessibility
Description Metadata Langauge).

An example of this might be:
<rdf:RDF xmlns:wcag="http://www.w3.org/2000/10/wai-er-adf"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
<rdf:description rdf:about="http://rdf.pair.com/xchecker.htm"
     dc:title="Checkpoint Checker"
     dc:description="W3C WAI WCAG 1.0 Checkpoint Checker">
  <wcag:assertion>
     <wcag:verification
        wcag:version="1.0"
        wcag:level="AAA"
        wcag:proselevel="Triple A">
 <wcag:list>
     <wcag:checkpoint="1.0" wcag:met="yes"
        wcag:prose="Provide a text equivalent for every non-text element "/>
     <wcag:checkpoint="1.1" wcag:met="yes"/>
     <wcag:checkpoint="1.2" wcag:met="yes"/>
       [...]
    </wcag:list>
   </wcag:verification>
  </wcag:assertion>
</rdf:description>
</rdf:RDF>

I hope you follow what it can potentially do - in the example above, it
simply asserts what level of comformance it is at, and goes through all of
the checkpoints providing information as to whether or not they have been
met, what they are etc. This small example provides an excellent backbone
for the things that you have been discussing: pointing directly into
documents and saying "this conforms to checkpoint 1.3", or "this bit
doesn't, but could be fixed", etc. The potential is enourmous. We could add
all sorts of things into the language to meet the points listed in the core
tenet: http://www.w3.org/WAI/ER/WD-AERT/
[1] In fact, it should be possible to convert HTML/CSS into an XML tree, and
apply the XML version of ADL (or ADML, or whatever) to it (just a maybe). At
the end of the day, we would be left with a modular XML/RDF application
for:-
1. Asserting
2. Validating
3. Recording
4. Processing
5. Reparing
accessibility features in any XML document, primarily XHTML/HTML. Note that
my code example above only gave a glimpse at point 1. listed above. i.e.
room to expand!

RDF is the W3C's (resource) description format, ideally suited to this task:
Accessibility *Description* Language. As further proof that RDF can fulfill
the needs of this group and ADL/ADML, here is a citation from
http://www.w3.org/TR/REC-rdf-syntax/
[[[
Resource Description Framework (RDF) is a foundation for processing
metadata; it provides interoperability between applications that exchange
machine-understandable information on the Web. RDF emphasizes facilities to
enable automated processing of Web resources. RDF can be used in a variety
of application areas [...] [e.g.] in content rating, [...]
]]]

Also, I'll go through some of the requirements listed in your original
post:-

     > Include summary statistics in output?

This can be done easily with any XML language. By counting how many of each
certain element, etc. that there are (simple example).

     > Include history of what was checked (e.g. "this alt text is OK
     > according to a human")

We could set a prose description element for this, and extract them for
display using XSLT etc. Validation histories could also be automatically
generated by validators using a module of the same language.

     > How robust in face of changed source?  I.e. if source changes, how
     > much of previous description can carry over?

Good question. If we use XPointer, some of the problems will be taken away,
but it is hard.

     > How scalable? Just pages?  Whole site?  Results of several
     > independed processes running on site?

Because we can use XLink and rdf:about etc., you can scale it to just about
any project!

     > What tools will read output?
     >     - evaluation tools
     >     - authoring tools

Using XSLT, you can make it machine and/or human readable. So both of the
above would find it useful.

     > Is output useful for user agents?

Hopefully: this is another topic I will discuss further at a future date.
This should be one of the final aims, but not initial discussions (IMHO).

I sincerely hope this is a good idea for ADL/ADML, and the IG/WGs feedback
on the matter from anyone would be most appreciated:-
What do you think about this approach?
Is this what you are looking for?
Would like like me to further expand these ideas?

Kindest Regards,
Sean B. Palmer
The Semantic Web: A Resource - http://xhtml.waptechinfo.com/swr/
"The Internet; is that thing still around?" - Homer J. Simpson

Received on Tuesday, 14 November 2000 15:56:15 UTC