table of contents

Evaluation and Repair Language: User Scenarios

Draft in Progress. Changes from previous version marked "(new)".

Len Kasday, Institute on Disabilities/UAP at Temple University
kasday@acm.org

Introduction

This is a collection of user-oriented scenarios illustrating possible uses of the Evaluation And Repair Language (EARL).  See Sean Palmer's EARL Overview
and Minutes and discussions following December Face to Face.  (@@combine these scenarios with Overview?  Or reference from overview?)

EARL would initially be a means for expressing in a machine readable form (almost certainly XML, and very probably RDF):

• results of evaluating web pages and web sites against the Web Accessibility Content Guidelines
• specifications of repairs to those pages @@new proposal: no consensus yet.

The language would be extensible to

• evaluations of languages, e.g. as defined by their schemas
• evalutions of user agents
• evaluations of authoring tools
• evalutions against other types of specs, e.g. validity.
• @@repair of above??

The following scenarious assume the existence of tools to create and process EARL documents.   They include:

Evaluation and Repair Reports

User: Person writing evaluation for client's web site, utilizing one or more evaluation tools that output EARL

This user would potentially be able to:

1. Run one or more evaluation and repair tools
   • The output would include results of the user's human judgment if the tools provided those features.
   • The output would include recommendations for repair made automatically or recorded from the user to the extent the tools provided those features.
2. Combine outputs of two or more tools.
3. Add recommendations for repair
4. Compare results to one or more accessibility standards (WCAG, 508, internal intranet standards) to determine compliance(s) (new)
5. Format output according to desired standards
6. Ship EARL output to customer for use in customer's repair procedure as described below.

Web Page and Site Repair

User: person responsible for repairing a web site in accordance with evaluation results (run by the user or a third party)

This user would potentially be able to:

1. Use EARL with an editing tool to see where repairs are needed.
2. Accept or reject any repair suggestions included in EARL input
3. Manually perform other repairs.

Third Party Accessibility Services

An institution may need to use a web site that is not accessible, and no way to induce the site owner to make it accessible.  For example, images may have missing ALT text. Daniel Dardailler's ALT Server paper  described an approach in which a third party maintained ALT text images on a server.  This could be generalized to any type of repair.

User: Person with a disability using a web site that is not accessible, but for which a third party has specified repairs.  

This user would potentially be able to:

1. Combine the repair information with the web site information locally in his or her computer.
2. or have them combined in a proxy server.

Group Judgments of Web Pages

(see ER thread "Cursors face defining moment on the Web"

Users may wish to comment on pages or sections of pages as they browse which could be collected and optionally aggregated on an annotation server.  This could involve digital signatures to check who comments came from.

TestSubjects of multiple types

(refer to the notes from the 13 March 2002 chat)

• the testsubject as a specification fails XAG, but as a document passes WCAG
• an authoring tool needs to be tested as a user agent as well as an authoring tool according to ATAG)

rev. 2/16/2001 LRK