At 2 September 2004 9:53:28 AM, Liddy Nevile <[log in to unmask]>
wrote to the Link mailing list
<http://mailman.anu.edu.au/pipermail/link/2004-September/058345.html>:
>The DC Accessibility Working Group has a proposal for an accessibility
>element for DC. ... http://www.ozewai.org/DC-term-proposal/ ... discussion
>should take place on the dcAccessibility list ...
>http://www.jiscmail.ac.uk/lists/dc-accessibility.html ...

As requested, below are some comments. Please note that I am not an
accessibility specialist, just an IT practitioner who is asked to look at
the issue occasionally. One example last November was for the Beijing 2008
Olympics <http://www.tomw.net.au/2003/bws/>.

COMMENTS ON THE PROPOSAL FOR AN ACCESSIBILITY ELEMENT FOR DC

These are comments on the proposal for an accessibility element for  Dublin
Core (undated document) <http://www.ozewai.org/DC-term-proposal/>. This is
important work by respected international experts. But by trying to provide
the history of the development of the proposal and justification of it,
what is actually proposed has been obscured. The proposal should be allowed
to speak for itself, otherwise its adoption as a standard may be at risk.

What is needed is a brief overview of the proposed standard, abstracted
from the standards document itself. To those involved in the complex and
frustrating task of standards development, all of the details of how a
standard is created are very interesting and relevant. However, to the rest
of us they are irrelevant and are almost unintelligible. The standard must
be usable in and of itself.

While I have been involved in standards development in the past (for the
Australian Government, IEEE and the Australian Computer Society) in this
case I am just a potential user. What I want to know is: What is the
standard for? Could I implement it? Could I teach it to my students? Could
I use it in the specifications of a system? Will it stand up under cross
examination in court? I suspect that buried down in the proposal somewhere
the answer is "yes".

Some specific comments:

* ONE DOCUMENT PLEASE: It would be useful if there was ONE document clearly
identified as the proposal. There are thirteen documents listed on the
"Index of documents for DC Accessibility Proposal"
<http://www.ozewai.org/DC-term-proposal/>. There are two different
documents titled "overview". It is not clear which document make up the
actual proposal, or if they all are part of it.

* WHO IS DOING THIS?: There appear to be two different sets of documents
provided. The first four (Overview, Criteria, Decision Tree Table, Proposal
Requirements Table) are from "DC Accessibility Working Group". The
remaining documents (Overview, Best Practice Guide , Information model, XML
Schema, XML Binding and four XML examples) are from IMS Global Learning
Consortium, Inc. Presumably the same list of experts in the IMS document
were on the DC Accessibility Working Group, but it doesn't say that.

Overview <http://www.ozewai.org/DC-term-proposal/overview.html>:

* DEFINE WHAT YOU ARE TRYING TO DO AND WHY: The first overview document
doesn't explain what accessibility is. A short definition (perhaps cited
from W3C) would be useful so everyone knew what they were talking about and
why.

* SAY WHAT IS PROPOSED UP FRONT: The last three paragraphs of the overview,
which say what is proposed, should be moved to top of the document. This
should be reworded to state succinctly what is proposed before going on to
justify the choice. Then the background of how that was arrived at should
be given. As it is the reader is likely to have lost interest after
thirteen paragraphs of how various groups tried various things. Even if the
reader gets to the end of the overview, the description of what is proposed
is obscured by a justification of why.

AccessForAll Meta-data Overview, Version 1.0 Final Specification, 12 July
2004
<http://www.imsproject.org/accessibility/accmdv1p0/imsaccmd_oviewv1p0.html>:

* DON'T REDEFINE TERMS: The second overview document says: "In this
document, the term disability has been re-defined as a mismatch between the
needs of the learner and the education offered.". However, what it is being
redefined from is not stated.



Tom Worthington FACS     [log in to unmask]  Ph: 0419 496150
Director, Tomw Communications Pty Ltd             ABN: 17 088 714 309
http://www.tomw.net.au                PO Box 13, Belconnen ACT 2617
Visiting Fellow, Computer Science,  Australian National University
Publications Director,  Australian Computer Society