In the last year, I have been doing a lot of reading and thinking about the Semantic Web and the potential benefits in the area of Web accessibility. I like the idea of the Semantic Web; I like the idea that it seems so abstract but that when you look closer, it is the complete opposite. I also like the idea of the big picture it provides. And how it can actually make you believe that things make sense in the largely undiscovered country that is the World Wide Web.
I have to admit however that up until recently, I did not see much practicality in all this stuff. I remember when I first started exploring this field a couple of years ago. I felt like “wow, this is really cool but how useful can it be to me, to the stuff that matters to me.” At the time, it was not very clear. It just seemed like a bunch of W3C rock stars geeking off. And that “Semantic Web cake” they kept adding layers to did not help matters.
I think that more than anything, more than social networking and [geo]tagging or folksomies and promises of tools that can organise your schedule so you can go to the dentist and make your daughter’s soccer game, EARL is what really brought it home for me.
what is EARL ?
Aside from being the main character of a wildly successful US television sitcom, EARL (acronym for Evaluation and Report Language) is basically a technology in development at the W3C to convey information about test results. Though it was originally intended to be used with regards to accessibility audits of Web resources, it can also be applied to activities related to generic quality assurance and validation. And it could theoretically be used to communicate information about any kind of tests done on any test subject.
EARL is expressed in a Resource Description Format (RDF) vocabulary as well as reusing other RDF vocabularies such as those provided by the Dublin Core Metadata Initiative (DCMI) and the Friend Of A Friend (FOAF) project. This allows you to provide information in a way that is machine-understandable which is important because it enables different technologies to use and exchange information about the test results (auditing tools, user agents, search engines, etc.).
So while for most humans, reading an actual EARL report would be rather tedious, a machine would immediately “understand” the information conveyed, such as what resource was tested and when, what standard or set of requirements the resource was compared to, who conducted the test and if the resource passed or failed the test. This is obviously a really simple example (based upon a yet to be finalised spec) but if you look through the draft Schema and its companion guide, you will find various examples, some illustrating all sorts of other complementary information that can be expressed with EARL.
why is that useful ?
Suppose you are a Web developer who is mandated to audit a Web site that was audited the year before by another firm. If, like you, they used tools capable of generating EARL reports, you could have an application combine that information to help you track the evolution of the resource. And this could be achieved regardless of the fact that you may be from a different linguistic community. This data, in addition to information on what changes were made to the resource since the initial tests, could help you to quickly identify what possible training issues and/or authoring strategies need to be addressed so people do not make things worse when adding or modifying content.
Or imagine you are a user with a disability involved in e-learning activities. EARL could make it easier for your user agent to offer content according to your specific needs, i.e. a resource that has the appropriate accessibility features. This is dependent on other things, such as a user profile (for example, see the IMS Learner Information Package Accessibility for LIP), but the possibilities do exist and EARL could help make the matching more reliable.
Or you could be a major corporation that must comply with your country’s accessibility standards. Instead of just slapping a “Randy-approved” logo on a Web page, you could provide a conformance claim that links to an EARL report as proof. Or you might be a big search engine that wants to include accessibility criteria in its querying capabilities. Instead of using some obscure top-secret algorithm, you could use the cold hard facts provided by EARL reports to offer search results based on accessibility of resources.
You could probably achieve most of this with other metadata strategies but the neat thing about EARL is that your declaration is based on actual tests, on facts derived from those tests. Of course, EARL is not a guarantee. The trustworthiness of the information it provides is dependent on auditing tools that correctly interpret the relevant requirements, the stuff they are comparing the resource with, in this case WCAG or some other associated standard. And the human auditor performing the tests needs to get it too. But much like its televised alter ego, with the appropriate conditions met, EARL can do a lot of good.
what is happening with EARL now ?
For the moment, EARL is not an official W3C Recommendation so it is important to keep in mind that the present work will likely change or evolve on some levels but things seem to be moving along smoothly. This is good news because for a while, it was unclear what would become of this work. After a couple of very rough drafts, the last one released in 2002, EARL was in limbo and very few people seemed to care. But more recently, the Working Group was started up again and they have made great progress, releasing two working drafts in the last year, the latest on September 27th (for which comments are sought until October 25th). And with any luck, we may even see EARL go to Last Call before the end of this year.
And despite its present unofficial status, it is already in use and in some cases, it has been for a few years now. For example, Webaim’s development version of WAVE produces EARL reports as does the ATRC’s AChecker and A-Prompt software, HiSoftware’s AccVerify, Sidar’s Hera, Webthing’s Accessibility Valet and the CTIC Foundation’s stand-alone version of TAW3. Another example is the Opquast project. This online quality assurance service allows users to monitor their Web site with regards to the Opquast set of best practices and EARL is among the formats offered for reports.
Also, various projects in Europe are experimenting with EARL, through the WAB Cluster. BenToWeb develops the tool “Imergo” which can export EARL and is also a plug-in for a content management system (RedDot). This EARL export is still experimental but already in use with the European Internet Accessibility Observatory project (EIAO) which is basically a giant crawler that tries to monitor European Union Web sites for conformance to (the automatically testable checks of) WCAG. EIAO uses EARL to collect results from different tools and to process the results internally.
So clearly, many stakeholders already recognise the usefulness and great potential of this technology and we can expect that more and more people, from toolmakers to developers to policy makers, will follow.
where can I learn more ?
A good place to start is the Evaluation and Repair Tools Working Group home page. Here you will find the W3C’s official information about past, current and related work. And of course, the chair of the Working Group, Shadi Abou-Zahra, is always very helpful. Indeed, he has been very supportive with me and I could not have gained a better understanding of EARL without him.
Beyond that however, there is not all that much information readily available at the moment, especially for audiences who have limited technical knowledge. And any information there is seems to be mainly available in English (a French version of this article is also available).
As things progress however, more and more people will be learning and writing about this very cool technology and more importantly using it. And hopefully, EARL can look forward to some very good karma.