Public Interface for A-Prompt and Integration with Other Tools

A-Prompt contains a public Application Programming Interface (API) that allows other programs to integrate and use the A-Prompt functionality. The API takes the form of a simple DLL with exported function calls that may be accessed by programs written in most common languages such as C, C++ or Visual Basic. It was our intention that HTML authoring programs would make use of this API and integrate the A-Prompt functionality much like a traditional spell checker utility. We envisioned that as the user authored their HTML document, A-Prompt would be called on a periodic basis to validate and repair its accessibility. We’ve had a great deal of interest in the API but have been unable to announce that a commercial HTML editor program has integrated A-Prompt.

Future development of the API

Version 2 of A-Prompt will contain an updated version of the API that exposes more components of the program’s functionality. It will be possible for host programs to have fine control over each repair that A-Prompt performs. The host program will also be able to control which accessibility checks and heuristics are applied in A-Prompt’s evaluation engine.

Open Standards for Checking and Repair

A common complaint from users performing accessibility checking is the lack of consistency between validation tools. All of the current accessibility checking software programs use different testing criteria. This lack of consistency is discouraging to users and weakens the acceptance of accessibility guidelines. If we liken accessibility validation to the use of a spell checker then we must promote the use of a single dictionary of testing criteria for all tools.

A-Prompt’s accessibility checking is based upon the Web Accessibility Initiative (WAI) technical document titled Accessibility Evaluation and Repair Techniques (AERT). This document lists, as much as possible, all the checks that must be performed to validate a document for compliance with the WAI’s Web Content Accessibility Guidelines WCAG). Unfortunately, not all the WAI guidelines can be validated by a series of checks and not all are detailed in the AERT. This gap has lead to the variance in the checking techniques used by different software tools.

The ATRC has been working with other accessibility validation tools to create a common set of algorithms for HTML accessibility. If adopted, this common set would also allow for the interoperability of checking tools. For example, a tool that just performs accessibility evaluations could pass invalid HTML code to a tool, like A-Prompt, that can repair the HTML code.

Each accessibility check that is performed by A-Prompt will be fully exposed and documented so that other checking programs can determine our compliance to accessibility standards. These checks will be made available to the user so they can modify or create their own standards. For example, some companies have currently adopted a low conformance rating but are moving towards a higher standard and will to include some, but not all, of the higher standard’s accessibility checks. A-Prompt’s checklist is stored in a separate file using the EARL standard format. The checklist file may be easily shared amongst users so they have a common set of accessibility checks. The checklist file may also be used in the creation of accessibility validation reports that will then be more accurate and detailed.

Expanded Registry & EARL

As part of the accessibility validation process, the user must make decisions about many of the document components. For example, if an image appears in an HTML document, the user must decide if the image is complex enough that it requires a textual description beyond what is contained in the short ‘alternate’ text. Even a relatively simple document may require dozens of user decisions in order to make a complete evaluation. These user decisions must be recorded and stored so the user is not asked to repeat their decisions each time the document is evaluated.

A standard method of recording this accessibility evaluation information has been developed and is used by A-Prompt. Called EARL, for Evaluation And Report Language, it is a Resource Description Language (RDF) dialect that allows accessibility checking tools to state exact information about their evaluations. Information stored in this standard format may be re-used by other tools to provide other accessibility reports. A-Prompt’s use of EARL is intended to reduce the number of redundant decisions that are required for a complete accessibility evaluation.

4. Conclusion

Ideally, all Web authoring interfaces, would in themselves provide utilities to prompt the creation of accessible content, this would insure that accessible authoring does not require retrofitting and becomes a naturally integrated, habitual step in creating resources for the web. Until this ideal is the norm rather than the exception, A-Prompt and systems like it provide the tools and model developers need to produce accessible web sites. Throughout it’s relatively long history, A-Prompt has been used to pilot and model the support of accessible authoring practices and has thereby played an important role in the market and in the efforts of the Web Accessibility Initiative. Ongoing development of A-Prompt is planned so that the tool will continue to enable developers using new techniques such as XML and dynamic web content or courseware environments to continue to create accessible content.