• Guidelines Home
• Criteria for VIP
• Guideline Language (this page)
• Publications
• Back to Intro

Problem

In the early version of our tool, NAUTICUS only one set of guidelines was supported for automatic inspection: the criteria for visually impaired. In NAUTICUS the specification of the guidelines to check was implemented directly in the tool code. Such an approach has several drawbacks: firstly, the tool is designed to support just one type of guideline-based evaluation; secondly, if a guideline changes or if a new guideline has to be added or deleted, the tool must be modified at the implementation level. This makes the tool limited and difficult to maintain and update. Thus, in order to overcome such limitations we have designed a solution based on the definition of an abstract guideline language.

Generally speaking, a guideline is expressed in natural language, which automatic tools cannot handle. Hence, in order to support developers in using guidelines, our approach is aimed at expressing guidelines so that they can be dealt with automatically. Furthermore, our investigation has focused on developing a tool free from guideline definition constraints: MAGENTA .

Briefly, such an approach allows designers to:

• Easily add new guidelines, modify or delete existing ones;
• Define and use different sets of guidelines;
• Separate implementation checks from the definition of guidelines;
• Avoid repetitive recoding of the tool by the implementers.

This makes the tool more adaptable to different kinds of automatic guideline-based inspections. In addition, guidelines can be better handled by persons different from those who have implemented the tool.

Guideline abstraction

When a guideline must be defined so that a tool can deal with it automatically, the problem is to describe the guideline expressed in natural language in technical terms. To this end, we have defined an abstract language for describing a guideline in technical terms.

In practice, the solution consists of abstracting guideline statements in a well-defined language.

In defining a guideline abstraction, the main features and elements characterizing the guideline itself can be shortly summarised as:

• General features, such as name, identification, description, source, etc.;
• Objects involved in the checking process, i.e. which tags, attributes, properties have to be considered in the inspection;
• Conditions referred to objects (i.e. what type of check has to be performed).

All the above elements have to be considered for structuring a guideline. It is necessary to specify the general features, the tags or properties involved in the checking process and the conditions that have to be verified for detecting if the principle has been applied or not. So, in order to define a certain abstraction level we have defined guidelines in terms of:

• Criteria, which express the general design principles of the guidelines and their features, such as description, type, etc.;
• Checkpoint/s, which indicates what has to be technically verified in the static code (i.e. which tag or attributes must be checked);
• Checkpoint relations, which indicate the boolean conditions to consider in order to satisfy the guidelines (i.e. and|or); a criterion to be satisfied could require one or more checkpoints, so relations among the checkpoints should be specified.

For example, a statement such as “all images presenting in a Web page must have an alternative description” or “Tables should have a short summary description” have to be formalised in some manner that can be handled by the automatic tool. Thus, we want the guideline statement to be abstracted and appropriately specified. This implies that the guideline is previously structured and then specified in our XML-based language.

The language GAL

As described above, we define a guideline in terms of a number of elements: checkpoints expressed with objects, operations and conditions to be verified. All abstracted guidelines are specified by an XML-based language we defined and stored in external files. In specific, an XML-Schema has been defined in order to define the general structure of our Guideline Abstraction Language (GAL). Through the XML-Schema some restrictions on data types can be defined and controlled, such as URL source addresses, evaluation date, and especially possible values for objects > and conditions.