W3C home > Mailing lists > Public > public-wai-ert@w3.org > April 2005

IMS and DC and EARL

From: Charles McCathieNevile <charles@sidar.org>
Date: Tue, 05 Apr 2005 23:06:24 +1000
To: Mum <liddy@sunriseresearch.org>, "public-wai-ert@w3.org" <public-wai-ert@w3.org>
Message-ID: <op.sorf0yj2w5l938@researchsft>

Hi folks,

This is an attempt to giv a quick overview of the use that the Dublin Core  
Metadata Initiative and the IMS group intend to make of EARL.

These are two important groups - Dublin Core metadata is perhaps the most  
common in the world. In easily found published RDF it is second only to  
FOAF, and most Dublin Core is not currently in RDF although it is moving  
slowly in that direction. It is also generaly produced by organisations  
who we expect to take accessibility seriously - governements and large  
institutions both private and public. Dublin Core formally gave in  
principle approval to an accessibility element which would be applicable  
to all resources described in Dublin Core, and the usage which is proposed  
for recommendation is to point to an EARL statement.

IMS is an educational consortium producing and describing "learning  
objects" (this is a gross oversimplification). Again, they describe the  
accessibility of things, and again they represent a number of very large  
producers and consumers of information.

(I have cc'ed Liddy because as well as being my mother she is the Chair of  
the Accessibiltiy group in Dublin Core, and more heavily involved in the  
IMS accessibility work than anyone I could think of at short notice. She  
should be able to correct anything I say that is wrong).

Roughly speaking both these groups are looking at using profiles to match  
resource to users. So while they mare use WCAG as a source of tests (or  
the source of tests, if it manages to provde enough) they then develop  
profiles for particular groups of users, and check whether a resource  
matches the requirements in that profile.

 From a user's perspective, if things are labelled accurately with the  
tests they pass, there is a wider range of choice where the user can  
reasonably believe that something is useful to them. This is because  
although very few resources pass every accessibility test, many of them  
will meet the needs of some group of users. This will often apply to  
resources not meeting any particular conformance level for WCAG (such as  
resources which meet the requirements of Section 508 - all of which have  
equivalents in WCAG but which are scattered across the different priority  

Thus it becomes important to have the atomic test results.

These groups extend the original results with a heavy emphasis on using  
equivalent resources to enable accessibility. In the IMS case the  
resources might be completely different - since the primary goal is  
generally to teach some concept, one equivalent might be constructed by  
adding subtitles or captions to a film, while another equivalent might be  
a completely different intereactive learning activity.

Again, this means knowing about passing tests at an atomic level, to  
describe whether or not a few atomic-level replacements are available that  
can be used in some circumstance. For example, something that relies on 4  
or 5 images could use longdescs of those images to work for a blind  
student in one case, and those descriptions might in fact be RDF assocated  
directly with the images rather than via longdesc in the HTML source of  
the page. On anoher occasion, one of the images might be better replaced  
by a seperate module, while the rest work fine with descriptions. And so on

I hope that is not too terse, and is reasonably accurate. Where I have  
made a mistake I hope Liddy will correct it, or someone else from the  
relevant groups.

I have been reasonably heavily involved in Dublin Core, but only very  
tangentially in the IMS work.



Charles McCathieNevile                      Fundacion Sidar
charles@sidar.org   +61 409 134 136    http://www.sidar.org
Received on Tuesday, 5 April 2005 13:06:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:52:49 UTC