Standardisation guidelines

A standardisation activity has been defined within the Work Package 4 of the WAI project, to ensure that the Web related access technologies will be propagate to the official standard bodies, such as the International Standards Organisation (ISO). The detailed objectives of this activity concern:

• the identification and assessment of the international state of the art with regards to current, on-going and anticipated future standardisation activities;
• the identification of requirements for Web accessibility and development of recommendations;
• the dissemination of the results to the relevant national, European and International standardisation bodies.

To achieve these objectives a four-phase approach has been adopted: data collection, data analysis, consolidation & recommendations, and dissemination (see Figure 0).

Figure 0 - Phases of the project

As a first step, a thorough investigation of the international state of the art regarding ongoing work on accessibility guidelines, recommendations and standards, available policies and legislation, as well as prevailing concepts and principles for making the Web accessible, has been conducted. The collected data has been subsequently analysed in the light of the emerging Web-applications and services and the current trends on Web technologies, and the specific points where further work or interventions need to be initiated have been identified.

This deliverable presents a summarising account of the activities carried out in this context, focusing on the data collection and analysis processes. More specifically, the deliverable reports on:

• the selection of appropriate data collection, consolidation and dissemination methods, and a thorough investigation of the efforts related to Web accessibility at European and International levels;
• the analysis of the collected data regarding current development of guidelines and recommendations, standardisation activities and national policies aiming at identifying gaps and new requirements for standardisation work.

1. Data Collection

The objective of the data collection task was to review the current and on-going standardisation activities related to Web accessibility, at European and International levels, considering current work on guidelines and recommendations, standardisation initiatives and national and international policies. Following the defined plan, the data collection phase started with a thorough investigation of the state of the art on Web accessibility related standardisation activities focusing on:

1. the on-going work on guidelines and recommendations in the context of W3C Web Accessibility Initiative and other relevant initiatives;
2. related activities and actions in the context of national and international standardisation organisations; and
3. new proposals as formulated by the industry, designers and developers of Web-based applications and services, and user organisations.

As a result of this activity, the current state of the development of guidelines and recommendations on Web accessibility has been documented, and a list of standardisation committees and existing and on-going standards where accessibility work could be propagated, has been drafted.

This investigation has been conducted utilising alternative channels and data collection methods including direct contacts with relevant organisations, search of available material on the Internet, bibliographic review, and participation in appropriate conferences, workshops and scientific fora. More specifically, the data collection process has facilitated through:

1. the active involvement of FORTH in organisations and committees relevant to the WWW (e.g. W3C, UseWeb, Internet Society) and the disability community (e.g. RESNA, AAATE, COST 219, HELIOS-HANDYNET);
2. the involvement in standardisation organisations and committees at European (e.g. ETSI, CEN, CENELEC) and International levels (e.g. ISO);
3. the review of relevant bibliography and information available on the WWW;
4. the participation in related conferences and workshops; and
5. direct contacts with key actors in the disability, ergonomics and standardisation fields.

A list of the organisations that were reviewed, and a list of Standardisation Committees, where standardisation work on Web accessibility could and should be propagated is provided below:

2. Recap of Data Collection and Analysis

The data collection and analysis phases have resulted in the documentation of the current state of the art concerning the development of guidelines and recommendations on Web accessibility, and in the drafting of a list of standardisation committees and existing and on-going standards where accessibility work could be propagated.

Regarding standardisation work on accessibility, it is likely that the only available standards related to accessibility are de facto industry standards, which have been adopted by the Web community and concern specific platforms, or proprietary technologies. Official international or national standards in this field are not yet available, due to the short history of the Web and the rapid evolution of the associated technologies. However, standardisation organisations (e.g. IEEE - Internet Best Practices Study Group, Internet Society - Internet Engineering Task Force) have recently expressed an intention to start standardisation activities related to the Web, including accessibility. From the analysis of the collected data the following conclusions were derived:

• Many organisations are currently involved (have started or plan to start activities) in standardisation in the area of Web Technologies (ISO, ANSI, CEN, IEEE, Internet Society, NISO).
• The existing or on-going standards (on Web technologies) concern mainstream technologies, and there are not special efforts on accessibility.
• A new working item on accessibility (in general, as an ergonomic element) has been recently accepted by the ISO TC 159 SC4 WG5.
• Accessibility standards are needed in core Web technologies, such as: (a) structural languages (e.g. HTML, XML), (b) presentation languages (e.g. CSS), (c) object models (e.g. DOM), (d) scripting (e.g. JavaScript), (e) emerging Web technologies (e.g. Java, DHTML).
• Recent interest has been shown in the provision of an accessible Information Society (in Europe) and Information Superhighways (in USA), and related initiatives are in progress (e.g. CEN/ISSS and European Commission Mandate SOGITS N1032-EN 06/05/98 in Europe).

3. Consolidation & Recommendations

3.1 Methodology

The currently available guidelines and recommendations related to accessibility are characterised by their focused scope, which results from their association to a specific platform or technology (e.g. HTML accessibility guidelines). In contrast, the development of guidelines and recommendations explicitly targeted to standardisation activities requires the adoption of a more general approach to accessibility, which is independent of a specific technology platform and addresses the requirements of the broadest possible user population. To accommodate these requirements, the methodology followed in the project has adopted the general principles of design for all and universal accessibility as applied in Human Computer Interaction, as a basis for the development of accessibility guidelines and recommendations targeted to the various stages of the interactive software development life-cycle. As a result, a set of process-oriented guidelines has been developed, introducing the different steps in a design process, which need to be followed when designing for accessibility. Moreover, the implications of these guidelines upon user interface development have been translated to specific features that interaction technologies and respective development tools should support, in order to facilitate the development of accessible interactive applications and services. Specifically, the relevance of the developed design guidelines and software technology requirements, to the Web environment was examined, addressing both Web-based interaction platforms (e.g. HTML, XML, CSS, XLS, VRML, TVML, Java, etc.) and Web application development tools (e.g. HTML authoring tools, etc.).

Figure 1 presents the different steps followed during the project in the development of accessibility guidelines and recommendations, as well as their relevance to the current Web technology.

This section provides definitions of some of the key terms, as well as contextual clarification, that are needed to facilitate a better understanding of the range and scope of the material to be presented.

The term universal design or design for all (the two terms are used interchangeably in this deliverable) is frequently associated with different connotations [Story, 1998]. Some individuals consider it as a new, politically correct, term, referring to efforts to introduce "special features" for "special users" in the design of a product. To others, universal design is a deeply meaningful and rich topic that elevates what designers like to call "good user-based design" to a more encompassing concept of addressing the needs of all potential users. In the present context (see also [Stephanidis et al, 1998]) the term is used to reflect a new concept, or philosophy for HCI design that recognises, respects, values and attempts to accommodate the broadest possible range of human abilities, requirements and preferences in the design of all computer-based products and environments. Thus, it promotes a design perspective that eliminates the need for "special features" and fosters individualisation and end-user acceptability. As already pointed out, the term is used interchangeably with the term design for all users. This does not imply a single design solution suitable for all users. Instead, it should be interpreted as an effort to design products and services, in such a way, so as to suit the broadest possible end user population. In doing this, it is more than likely that there will be different solutions for different contexts of use.

Universal accessibility is traditionally associated with disabled and elderly people and reflects the efforts devoted to the task of meeting prescribed code requirements for use by people with disabilities [Bergman and Johnson, 1995; Story, 1998]. However, due to recent technological developments (e.g., proliferation of interaction platforms, such as wireless computing, wearable equipment, user terminals), the range of the population which may gradually be confronted with accessibility problems extends beyond the population of disabled and elderly users. In the present context (see also [Stephanidis et al, 1998]) universal accessibility implies the global requirement for access to information by individuals with different abilities, requirements and preferences, in a variety of contexts of use; the meaning of the term is intentionally broad to encompass accessibility challenges as posed by diversity in: (i) the target user population profile (including people with special needs) and their individual and cultural differences; (ii) the scope and nature of tasks (especially as related to the shift from business tasks to communication and collaboration intensive computer-mediated human activities); (iii) the technological platforms and associated devices through which information is accessed.

In the present context, the term interaction platform refers to any software tool providing implemented (or the means to implement) interaction elements which, in turn, can be used to construct a user interface. Such software tools include the traditional user interface development toolkits, such as Windows95^TM, Motif, Athena Widget Set, as well as some current and emerging Web technologies such as structural languages (e.g. HTML, XML), presentation languages (e.g. CSS), scripting languages (e.g. JavaScript) as well as emerging Web technologies such as WebTV, Java, etc.

To establish a clear connection between the software technology requirements and the Web technologies which they are addressing, this document employs a document-centred view of the latter, i.e., Web technologies are conceived as complementary languages, protocols, etc., which are used for the construction of documents, made up of information entities. Such entities may have a structural, presentational, or behavioural role (or combinations thereof), in general, or in the specific context of the document they appear.

Following the above assumptions, the term structural language will be used to refer to those constructs that enable the specification of the structure of a document, and in particular, the synthesis of a document from individual information entities. The term presentation languages will be used to refer to those constructs that enable the specification of the presentation attributes of information entities. Similarly, the term behaviour languages will be used to refer to those constructs that enable the specification of the interactive behaviour of information entities. Note that presentation is a mandatory prerequisite for behaviour (i.e., an entity cannot "behave", if it is not somehow "presented" to the user), but the opposite is not necessary (i.e., an entity may have a physical "presence", but no behaviour associated to it).

To facilitate the presentation and analysis of the software technology requirements, the present document adopts the model of Figure 2 for the decomposition of interactive software. This model has been derived as an abstraction of existing interactive software models, such as model-view-controller (MVC) [Goldberg & Robson, 1984], and presentation-abstraction-control (PAC) [Coutaz, 1990], as well as related meta-models, such as Seeheim [Green, 1985], and Arch [The UIMS Developers Workshop, 1992]. It should be noted that the model presented here does not seek to act as a generic interactive software structuring one, but rather to capture commonalties in the aforementioned models, and to introduce a (conceptual) separation between three main components of interactive software. Furthermore, note that the naming adopted for the components has been intentionally selected to relate to Web technologies.

According to this model, an interaction platform incorporates of complementary facilities that:

1. Support the definition of elements (information entities) that have uniquely defined semantics and a specific meaning for end users; these facilities are conceptually grouped under the content component of the model.
2. Support the definition, for each of the aforementioned elements, of presentation parameters / attributes that affect the way in which users perceive an element and the different (interaction or other) states it can assume; these facilities are conceptually grouped under the presentation component of the model.
3. Support the definition, for each of the aforementioned elements, of behavioural parameters / attributes that control how interaction with these elements affects the overall system state, as well as what the users conceive these effects to be; these facilities are conceptually grouped under the behaviour component of the model.

It can be observed, that, according to the above model, a "complete" interaction platform on the Web would comprise a mixture of structural, presentation and "interaction" languages (e.g., combination of HTML, CSS and Javascript / DHTML). However, contemporary Web technologies diverge from the model in two main aspects: firstly, widely popular structural languages, like HTML, do not exhibit a clear separation between semantics (e.g., a paragraph of text) and presentation (e.g., the font in which a paragraph is presented); secondly, a large portion of the behaviour model of interactive elements is implicit and established by convention, due to its employment by vendors of popular Web-access user agents. The authors expect that both of the above shortcomings will be remedied through the evolution of Web technologies, especially in view of the accessibility problems that the lack of such a separation introduces.

Along the above lines, the term element will be used to refer to information entities, as these are defined by their structural, presentation and behaviour semantics as a whole. The term authoring tool will be used to refer to development tools / environments that enable the construction of documents, combining, as necessary, the languages that constitute a particular interaction platform on the Web. Finally, the term user agent will be used to refer to software applications that are capable of carrying out the presentation of, and support interaction with, documents developed for one or more interaction platforms.

The recent literature on accessibility and universal design provides several collections of general design principles, guidelines and recommendations for building accessibility into interactive computer-based products (see Figure 3). Design principles refer to high-level design objectives, which realise the notion of accessibility. Principles give rise to guidelines which may relate either to the syntactic- or physical-level of interaction [Akoumianakis and Stephanidis, 1998]. Guidelines are typically subject to further interpretation, so as to reflect the requirements of a particular organisation or design case. Finally, recommendations are unambiguous statements about physical artefacts.

To illustrate the contextual difference of the above terms, let us consider the following simple scenario:

Figure 4 depicts how a designer may progressively identify, select and interpret accessibility principles and guidelines into concrete recommendations. Thus, for instance, the software ergonomic principle which requires that: "the user interface should enable the user to initiate and accomplish a task" may translate to the two guidelines depicted in Figure 4, which in turn, give rise to recommendations of the physical "character" the interface.

However, neither the software ergonomic principle, nor the derived guidelines and recommendations offer any guidance to designers as to how they should proceed to identify and select appropriate interface components. Moreover, there is no account of any special features that the development tools should possess in order to realise a particular design.

To address the above, the present document presents: (a) three process-oriented design guidelines that extend user-centred design towards universal accessibility; and then (b) derives four software technology requirements for constructing interactive software platforms and tools that ensure accessibility by the broadest possible end user population, including people with disabilities. The intention is to extend the accumulated wisdom on accessibility and universal design in HCI, by focusing on the conduct of design, and by identifying required properties of user interface software technologies and development tools.

The present document argues that the above issues could be addressed by: (a) the formulation of process-oriented design guidelines, intended for designers, which identify steps to be followed within a human-centred life cycle; and (b) the derivation of software technology requirements, intended for interaction platform and development tools, which specify features that need to be supported by these technologies in order to construct interactive applications which are accessible by the broadest possible end user population, including people with disabilities.

Our interest is not to suggest specific (alternative) interaction techniques to support accessibility by different user categories, including disabled and elderly people. Instead, we are concerned with process-oriented design guidelines and corresponding software technology requirements, which result in the development of interactive systems accessible by the broadest possible end user population. The process-oriented guidelines are intended for designers and identify steps to be followed within a human-centred life cycle. On the other hand, the derived software technology requirements provide guidance to developers of interaction platforms and development tools for interactive applications, as to the required features that these technologies should support. It is expected that these contributions augment the accumulated accessibility wisdom beyond mere adaptations, towards universal design practice.

One important observation related to the accessibility of interactive applications and services by different user groups, including people with disabilities, is that no single interface implementation is likely to suffice for all different users. This simple observation leads to the conclusion that designing for the broadest possible end user population requires the provision of alternative interface manifestations depending on the abilities, requirements and preferences of the target user groups. To attain the above target requires a human-centred design activity, which has three additional key requirements, namely:

• enumeration of design alternatives;
• encapsulation of design alternatives into abstractions; and
• rationalisation of the resulting design space.

Figure 5 depicts these steps and reveals techniques that may be used to accomplish each one. These required steps could be formulated in the following design guidelines:

Design alternatives are necessitated by the different users and contexts of use, and provide a global view of task execution. This is to say that design alternatives offer rich insight into how a particular task may be accomplished by different users in different contexts of use. Since users differ with regards to abilities, requirements and preferences, tentative designs should aim to accommodate the broadest possible range of user capabilities, across different contexts of use. Thus, instead of restricting the design activity to producing a single outcome, designers should strive to compile design spaces containing plausible alternatives.

Once the design space has been compiled and documented, the design activity should proceed towards the encapsulation of plausible alternatives into abstract design components which are reusable and extensible. The need for abstraction is two-fold. Firstly, abstractions may be used to de-couple a design concept from any particular physical realisation, which is bound to a specific interaction platform; thus, through abstractions, a design concept may be mapped onto alternative physical counterparts. Secondly, abstraction provide a mechanism to support incremental design and design updates, as requirements mature, or evolve; thus, the original design space may be extended to include new physical realisations, necessitated by new contexts of use, or made possible by novel interaction technologies.

Rationalisation of the design space entails a principled approach to defining the reasoning behind each alternative. This enables the designer to map design abstractions to physical counterparts and provide the evidence for the mapping. In order to produce the necessary evidence, designers may have to assess alternatives with end users, or carry out experimentation to develop comparative results and decide on maximally preferred options. Such experimentation may be carried out using alternative user-centred design techniques, including subjective user assessments, performance measurement, GOMS analysis, etc. The need for rationalisation necessitates a shift from artefact-oriented design towards process-oriented and analytical design, whereby the reasoning behind an artefact is equally important as the artefact itself.

Having reviewed the process-oriented guidelines for universal design in HCI, this section aims to derive key software technology requirements related to Web-oriented interaction platforms, as well as to authoring tools and user agents supporting those platforms. In order to achieve this, we will briefly elaborate the implications of the design guidelines upon user interface development.

First of all, enumeration implies a conscious effort to populate design spaces (e.g., design pluralism) by extrapolating plausible usage scenarios and encountering artefacts suitable for different contexts of use. Moreover, many of these artefacts may be conveyed in different design languages and alternative modalities. Iterative prototyping of these artefacts demands the availability of tools to create versions which will enable users to experience and comment on the envisioned artefacts. Through such iterations, initial sketches become progressively high fidelity prototypes.

What is important to note is that a single user interface presentation will most likely not suffice to accommodate all plausible alternatives. Thus, developers will be confronted with the requirement to select and integrate different modalities (e.g., visual and non-visual ones) or media. However, it may also be the case that due to novel design properties, a specific platform (e.g. a behaviour language) may need to be augmented to support additional interactive behaviours, or the platform may need to be extended with elements that will encapsulate the new interaction semantics.

Secondly, encapsulation of alternatives into abstractions requires that developers need constructs to map abstract components to concrete interaction elements in a manner that is intuitive and relieved from the specifics (e.g., programming model) of a particular interaction platform. This, in turn, necessitates a shift towards specification of interactive behaviours rather than programming.

The above translate into several software technology requirements which need to be supported in order to provide the grounds for constructing universally accessible user interfaces. These requirements can be summarised as follows. An interaction platform is considered to provide comprehensive support for universal accessibility, when it meets the software technology requirements of abstraction, augmentation and expansion. An authoring tool, or a user agent is considered to provide comprehensive support for universal accessibility, when they meet the development requirement of platform integration. Figure 6 depicts the relation of the platform-level software technology requirements to the components of the interactive software model presented earlier. Similarly, Figure 7 depicts the relation of the tool-level development requirement to the components of the generic model for interactive software. Table 1 presents the same information collectively, in a tabular form.

In the remainder of this section, we review each one of those requirements and discuss its relevance to currently available and forthcoming Web technologies.

Abstraction refers to the capability of a platform to support the specification of information entities and their respective interactive behaviour, by means of abstract interaction elements relieved from media or modality dependencies. The requirement for abstraction stems from the need to derive specifications of interaction constructs that can be reused across multiple categories of end users, with differing sensory and motor abilities and skills (which, in turn, may introduce different requirements in terms of how interactive entities are conceived and manipulated). For abstraction to be possible, there should also exist a well defined protocol for mapping abstract interaction entities to concrete elements in the underlying interaction platform.

According to the above, abstraction applies to the content and behaviour components of the interactive software model (see also Figure 2).

When applied to Web technologies, abstraction is defined as : (i) the capability of structural languages to specify document contents in a media- and modality-independent manner; and (ii) the capability of behaviour languages to expose, and make available for manipulation, the platform- / content-specific behaviour of elements, in a manner that is entirely decoupled from physical interaction properties.

The requirement for media- and modality-independence posed above necessitates a strict separation of semantics and presentation description (e.g., document contents are described in HTML, while their presentation is specified in its entirety through CSS). Without this separation, semantic-level entities are unnecessarily bound to particular types of modalities or media, thus inevitably causing inaccessibility for certain users or within certain contexts of use. As an example of lack of such separation, consider the <P> (paragraph) tag in HTML, which, although a primarily semantic construct, contains modality specific attributes (e.g., alignment of the paragraph in a page) which are specific to visual presentation. It should be noted that a separation mechanism provided by the well documented abstraction model, enables the mapping of multiple alternative presentations to a single semantic entity at a time (pre-defined mapping scheme).

In terms of behaviour, abstract interaction objects are high-level interactive entities reflecting generic behavioural properties having no input syntax, interaction dialogue, and physical structure. Syntax, dialogue, and structure need to be defined separately within the interaction and presentation description. Thus, the respective description languages have to provide the facilities to define abstract interaction objects, and to define schemes for mapping these abstract objects to appropriate physical alternatives (i.e., concrete elements with specific physical structure, input syntax and interaction dialogue). Furthermore, a pre-defined collection of abstract interaction object classes and appropriate pre-defined mapping schemes should be provided.

The task within this example is to design a Web document that is usable by potentially all visitors, independently of their abilities or preferences, or of the context of use. This document shall provide the visitors with three choices. Approaches in the past to solve this task had a structure similar to the following:

The MENU tag includes the list of names to appear in a pull-down area and defines the width and font for this interaction element. Note that the attributes of the MENU tag, refer (and restrict) to visual presentation on screens. Furthermore, the I/O activities to select an option (i.e., input activity and visual feedback) is implicit and part of the related metaphor due to various widely acknowledged implementations of it.

Abstraction refers to the requirement to separate the presentation and the interactive behaviour (bound to specific input and output devices) from the content definition of an interaction element. This might result, for example, in the following abstract interaction object (AIO):

This representation relates neither to a specific medium or modality nor implies a metaphor for presentation. Abstraction provides a mechanism to link this abstract interaction object with both the presentation and the behaviour description.

One presentation description could be the following:

(with MENU type e.g., as a predefined presentation primitive). Much in the same way, a separate description of the abstract object's interactive behaviour (i.e., I/O strategy, dynamic behaviour, and functionality) is necessary. The following example describes the well-known interaction behaviour of a visual MENU implementation:

Note that here it is also necessary to provide a mechanism to map the attribute values of an AIO definition to appropriate behaviour descriptions.

Augmentation is defined as the design and implementation process through which additional presentation patterns or interaction techniques are "injected" into the original (native) set of presentation and interaction primitives supported by an interaction platform, thus leading to improved accessibility or enhanced interaction quality for specific user categories. The need for augmentation arises from the fact that it is sometimes desirable to provide extended presentation or interaction facilities, beyond the original collection, which address untypical, or unforeseen end-user requirements, or novel context of use. Newly introduced presentation patterns or interaction techniques become an integral part of the existing set of presentation and interaction primitives, while already existing software that makes use of the original primitives "inherits" the extra features, without requiring modifications or redevelopment.

Augmentation applies to the presentation and the behaviour components of the interactive software model (see also Figure 2).

The need for augmentation arises mainly from shortcomings, or design deficiencies regarding the supplied presentation and interaction entities of existing Web-based interaction platforms (i.e., collections of content-, presentation-, and behaviour-descriptor "libraries") and their interpretation by user agents. Moreover, since documents on the Web are built by utilising such "libraries", these shortcomings and deficiencies are propagated to the recipients of these documents.

To facilitate augmentation for presentation, the presentation language has to provide the means to add new primitives to the basic set of (modality- or media-specific) attributes. This, for example, would entail the capability to introduce a new output medium (e.g., force-feedback tactile display) and the respective presentation attributes (e.g., "hardness", "weight"). Such new primitives can subsequently be used together with the original set of attributes, to improve access to information, presented via the augmented modality or media. Augmentation supports this process via well-documented mechanisms.

The requirement for augmentation at the level of physical interaction facilities is evident, for example, in the case of providing access to HTML hyperlinks or clickable maps by motor-impaired users. In this case, additional interaction techniques are needed, which will enable motor-impaired users to access the documents interaction elements through specialised input devices (e.g., binary switches) by adding scanning functionality to the aforementioned interaction elements. To facilitate augmentation, the interaction language has to provide means to add new techniques to the basic set of interaction primitives.

Proceeding within the example, we assume now that the Web document is expected to be presented within a bright environment of use (e.g., public information kiosk). As a consequence, it is desirable to display the information with a certain level of contrast. Therefore, a new attribute needs to be introduced into the presentation description

Augmentation facilitates the process of introducing additional attributes into the set of existing presentation attributes relating to certain media or modalities.

Regarding behaviour, augmentation enables the enrichment of the set of interaction primitives. In this example, it is assumed that people with motor impairments should have access to the information by using a single switch for interaction. Then, a modified interaction description needs to be created, augmented by a new interaction primitive (PUSH-SCOPE), that allows timed scanning through the available menu options:

Expansion, over a particular interaction platform, is defined as the process through which new information entities, with well-defined semantics, presentation, and behaviour, are introduced, which were not originally supported by the platform. An important requirement of expansion is that all newly introduced objects are made available, in terms of the manipulation facilities offered, in exactly the same manner as original objects - in effect rendering "add-on" objects indistinguishable from original objects, both from the developer's and the user's point of view. The rationale for expansion arises from the fact that it is sometimes necessary to support domain-specific, or application-specific functionality that needs to be presented and made accessible as a separate self-contained interactive entity.

Expansion applies to all the components (i.e., content, presentation and behaviour) of the interactive software model (see also Figure 2).

Expansion, regarding the semantic (content) layer of interactive software, refers to the process of introducing new objects to be used of Web documents' contents. Expansion, therefore, necessitates the presence of a framework that enables the introduction of new elements at the semantic level, and, at the same time, supports the specification of their presentation and behavioural attributes. It is important that such a framework equates newly introduced elements with the original ones, in terms of how developers and users perceive them. Furthermore, newly introduced elements should become "first-class citizens" of the interaction platform, so that abstraction and augmentation can be applied to them in the same way they are applied to pre-existing elements.

Expansion may be necessary when a new interaction metaphor needs to be embodied in the interaction platform. In this case, the target domain elements may have to be mapped to new source domain elements, to better convey their semantics and behaviour. Additionally, expansion may be necessitated in the case that new devices are introduced, which allow for additional presentational attributes, which are not considered by the interaction platform, or if new modalities are to be addressed. Typically, these new attributes will need to be defined and covered by new presentation objects.

We assume that, due to technological progress, the screen, used so far to display the information within the example, will be replaced by a device, that displays three-dimensional visual information. As a consequence, it is necessary to introduce a new metaphor with certain presentation and behaviour alternatives. In the example a new abstract interaction object (e.g., <POINTER>) needs to be defined, which consequently requires the semantic description of documents to be expandable. Expansion provides the mechanisms to introduce new abstract interaction objects into the content description and a mapping scheme to link these objects with the appropriate presentation and behaviour descriptions.

Furthermore, a new presentational description for 3-D objects is necessary i.e., a new type of objects with an own set of presentation attributes needs to be added.

Finally, regarding the behaviour, three-dimensional objects need to be addressed by additional interaction techniques (e.g., selection by cueing or grasping), which have to be defined separatedly. Expansion therefore provides the necessary methods to define and introduce these techniques.

Platform integration entails the capability to import any interaction platform that may be required for the development of accessible information content, so that all interaction elements of the imported platform can be directly accounted by the original building techniques supported by an authoring tool. Additionally, user agents should be able to target alternative interaction platforms to the one(s) they were initially developed for, when provided with appropriate descriptions of these platforms. Platform integration is necessitated in cases where the interaction elements originally supported by a particular interaction platform do not suffice to provide support for a particular type of interaction (e.g., non-visual). In such cases, it is important to be able to utilise elements from alternative sources (e.g., external object libraries), offering the facilities required.

Integration applies to all the components (i.e., content, presentation and behaviour) of the interactive software model (see also Figure 2).

Platform integration is of high relevance to the construction of accessible Web documents, for a number of reasons. Firstly, it introduces the possibility of employing and reusing accessibility concepts and solutions that have long existed in interactive environments other than the Web. Secondly, platform integration enables developers to incrementally introduce interaction platforms, accessible by different categories of target users, without reinvesting resources in the employment of alternative Web authoring tools. Thirdly, the very capability of integrating alternative accessible interaction platforms is expected to inform and educate developers concerning the accessibility issues their users face, and potential solutions to the resulting problems. Fourthly, end users can take advantage of a multitude of interaction platforms that better serve their temporal or permanent abilities and skills, as well as the different contexts of use in which they may find themselves, without having to resort to different user agents to do so. In whole, the integration of several platforms can contribute to the design of Web documents that are accessible for a maximally diverse target user population, within a variety of environments of use.

The choices that users are able to make within the Web document we have used as an example will be provided in additional modalities, so as to support for example blind users. Then, the former SELECTOR object needs to be represented in a tactile or audio instantiation as documented in Figure 8. To achieve this, solutions like audio screens or tactile maps, developed in other areas than the Web to solve the accessibility problem for blind users, could be used by integrating these specific interaction platforms into the user agents or authoring tools. Without the necessity to re-develop or "translate" solutions for a specific Web interaction platform, integration offers the opportunity to reuse these solutions simply by selecting appropriate interaction platforms from the variety of existing approaches. The capability to import, e.g., tactile or audio interaction modalities and media into the set of existing content, presentation, and behaviour primitives has to be provided by a well documented integration mechanism.

4. Dissemination

In the former sections of this report, we have described process-oriented guidelines and some software technology requirements, which have the potential of improving upon the practice of accessible design. We will now briefly discuss how the compiled recommendations may contribute to various on-going standardisation activities, thus outlining a potential action plan and a course of action. Our focus will be either on standardisation communities focusing on software ergonomics in general, or accessibility in particular.

One popular process-oriented standard in software is ISO 13407 on Human Centred Design. Our tentative objective is to briefly review the design activities introduced in the Draft ISO 13407 on Human Centred Design [ISO, 1997b] and discuss the implications of the present work on the model presented therein. Our objective is to link explicitly the principles of design for all with Human Centred Design and to identify areas in which design for all extends and improves human-centred design practices.

Human Centred Design assumes four activities, which can be briefly summarised as understanding and specifying the context of use, specifying user and organisational requirements, producing design solutions and evaluating designs against requirements [ISO, 1997b]. The interdependence between the four activities is depicted in Figure 9.

Though there is no doubt as to whether, or not, designing for accessibility requires a user-centred protocol such as the above, there are several remarks that need to be made with regards to the conduct of design. First of all, enumeration requires that the design outcome is not constrained to a single artefact, but rather to design spaces, containing alternative options intended for different user groups, or contexts of use. To facilitate this, the study of requirements should be broad enough to convey the global task execution contexts. As a result, during the first two activities, designers should elicit requirements for all target user groups, using methods that are best suited for each case. There may be cases in which users do not possess a clear understanding of requirements, while in other cases, users may not be able to provide the required input. In both cases, prototyping may be part of the context and requirement elicitation inquiries, to provide specifications that are subsequently translated into high fidelity prototypes.

Secondly, abstraction and rationalisation require that design spaces are organised in such a way that they embody the required contextual information to differentiate plausible alternatives and specify when a particular option should be preferred from another. This body of knowledge, which is referred to as rationale, should clearly indicate why a design option is relevant, how it relates to specific objectives and the circumstances, or conditions under which it should be instantiated. To this end, the objectives of evaluation should not only be to test designs against requirements, but also to assess alternatives against criteria and to provide the empirical evidence that is needed for rationalisation.

From the above, it follows that, not only are the proposed guidelines compatible with the phases of Human Centred design, but they also enrich and extend the scope of design activities to also address the rationale behind design outcomes. It is also evident that, due to the above, the protocols for assessing adherence and compliance with ISO 13407 require revisions in several directions, before they can be used to assess accessibility. In particular, they should provide additional information on the construction of the design space, as well as the way in which selection is made within the respective design space. Such extensions, however, can easily be accommodated in the existing documentation intended to assess conformance.

In 1997 the ISO TC 159 / SC 4 / WG 5 launched a new work item on accessible software, deciding to produce a multi-part standard which would provide various insights into how accessibility can be supported in computer-based software products. At the time, it had also been decided that the Draft ANSI/HFES 200, Section 5 on Accessibility, once in final form, would constitute one part of that multi-part standard. Nevertheless, the committee pointed out very clearly that it would welcome new well-developed proposals on ergonomic design principles and accessibility criteria, requirements and guidelines, as additional parts to the standard. It should also be noted that part of the rationale for Work Package 4 of the WAI-DE was to facilitate this evolution by developing concrete proposals in the form of technical reports to be submitted to the above ISO committee.

The software technology requirements outlined in this document are distinctively different, in both content and scope, from the recommendations reported in the Draft ANSI/HFES 200, Section 5 on Accessibility. Thus, it is strongly believed that they could provide valuable input to the ISO accessibility standard, in the form of a new complementary part. The requirement for such a proposal to be considered is that it should be general enough and broadly relevant to software ergonomics. This is the primary reason which has influenced both the presentation and the elaboration of the principles presented in this document. In other words, our focal concern has been to provide general-purpose information on how accessible design may be attained and to exemplify as much as possible for the case of the Web and the technologies supported by W3C.

At the end of this effort, it is believed that the proposed process-oriented guidelines and the corresponding software technology requirements constitute a sufficiently elaborate code for practising accessible design in the computer-based interactive software development. At the same time, it is realised that additional efforts are still needed to precisely define the pathway through which these materials could reach the relevant standardisation communities. To this end, we outline a tentative action plan (see section 4.4), which, however, is not intended to be exhaustive or unitary.

Another standardisation community where accessibility bares relevance is the software quality community. However, the available quality standards adopt very different motivating principles and are intended for different communities. In particular, quality standards, until very recently, conveyed very different meanings to what quality is and how it can be attained. Thus, there have been at least three approaches to quality, focusing respectively on product quality, process quality and, more recently, quality in use (see Figure 10).

A representative standard adopting the software product quality view is ISO/IEC 9126, which breaks down quality into a number of characteristics and sub-characteristics (see Figure 11). The ISO/IEC 9126 characteristics and sub-characteristics provide a useful checklist of issues related to quality. The actual characteristics and sub-characteristics that are relevant in any particular situation, depend on the purpose of the evaluation, and should be identified by a quality-requirements study. This, however, is a "product" oriented view of quality [Garvin, 1984]: "an inherent characteristic of the product determined by the presence or absence of measurable product attributes".

In this view, the quality of a software product can be specified and built-in as specific attributes of the code. The ISO/IEC 9126 definitions acknowledge that the objective of these attributes is to meet user needs in the form of functionality, reliability, usability, efficiency, maintainability and portability. But ISO 8402 makes it clear that a product-oriented view of quality should not be confused with measures of the "degree of excellence" resulting from the presence of absence of required attributes [ISO, 1994]. Moreover, the ISO 9000 series of standards are largely focused on quality as a manufacturing process, not addressing aspects of the final products, such as usability and user-perceived quality [ISO, 1987]. Yet the objective of quality from the user's perspective is to achieve a degree of excellence in a particular context of use. Despite the apparent user orientation of ISO/IEC 9126, the definitions in terms of attributes imply that software quality should be specified and measured on the basis of attributes of the source code.

Having discussed the potential target communities that can be influenced as a result of the current work, in this section we elaborate on a tentative action plan. To this end, we identify a portfolio of plausible alternative courses of action and discuss their relative pros and cons. Two main issues are important when deciding on the action plan. These are the type of recommendations to be made and their relevance to the life cycle of different standards. With regards to the type of recommendation, there are several options, which are depicted in Figure 12.

On the other hand, the current status of standards' life cycle (see Figure 13) may determine whether or not, or what type of input may be possible.

For example, there may be standards that have reached a point where no major modifications can be made and, therefore, cannot accommodate the present recommendations. Moreover, there may be standards which are under revision and could potentially include minor recommendations. From the above analysis, it follows that there are mainly two alternatives for introducing accessibility into international standardisation.

The first is to identify the relevance of accessibility across different thematic topics (e.g. usability, quality, software engineering, multimedia) and recommend specific clauses to be included in the respective standards. This option requires that accessibility is related explicitly to software ergonomics, quality models, software engineering processes, etc., and is sufficiently detailed to provide the required input. There are two main constraints which render this option unfeasible or more difficult. Firstly, the different standards to which accessibility bares a potential relevance, may have reached a final stage which does not allow any revisions to be made. This is for example the case with several of the parts of the ISO 9241 standard [ISO, 1997a]. Secondly, and more importantly, the relevance of accessibility to these communities is not uniform. Thus, for the product quality communities, accessibility would be yet another quality attribute, which would extend the model outlined above. However, the standard does not convey any particular code of practice through which such a quality could be attained. It can, therefore, be concluded that it is far more difficult to address all these communities using the vocabulary they are typically accustomed to and expect that accessibility will have an impact on the market.

The second and recommended option, which bypasses all pragmatic or artificial impediments of the previous course of action, is to take advantage of the new work item within ISO TC 159 / SC 4 / WG 5 and prepare a concrete set of recommendations for new parts. The shortcoming of this option is that whatever is recommended must fall within the software ergonomics perspective. On the other hand, the advantage is that accessibility can be treated in a uniform manner with regards to what it entails and how it can be attained for computer-based interactive products and services. For this option to materialise, the proposers should follow a formal protocol according to which an official submission is made to the above committee. This submission will be discussed in one of its subsequent meetings to decide on the recommendation. As far as the current document is concerned, the intention of the responsible organisation is to undertake the actions described in the template below.

In the context of Work Package 4 of the WAI-DE 4105 project, a review of the international state of the art in standardisation activities related to accessibility has been conducted, which made apparent that all current approaches to standardisation although useful, do not adequately address the issue of universal accessibility in the field of Human Computer Interaction in general, and the Web in particular. This has implications for many categories of potential users of the newly introduced interactive applications and services, and especially for disabled and elderly people, as they are not being accounted for by the de facto standards. At the same time, neither European Directives, nor ISO standards include any explicit clauses towards accessible interfaces. On the other hand, current efforts to develop accessibility guidelines and recommendations related to accessibility are characterised by their rather narrow scope, which results from their association to a specific platform or technology (e.g. HTML accessibility guidelines).

For this reason, an attempt was made in the context of the project, to provide recommendations that extend the focus and scope of current standardisation activities in relation to accessibility, based on the conducted investigation of the international state of the art with regards to current, on-going and anticipated future standardisation activities on Web accessibility, as well as on previous experience of the authors in the context of their participation in related projects of the European Community (TIDE-HEART Study, TIDE-ACCESS TP1001 Project). This work has adopted the general principles of design for all and universal accessibility as applied in Human Computer Interaction, as a basis for the development of accessibility guidelines and recommendations targeted to the various stages of the interactive software development life-cycle.

Specifically, this report has presented: (a) three design guidelines that characterise how designers should proceed when confronted with the challenge of designing interactive applications accessible by the broadest possible end user population, including people with disabilities; and (b) four software technology requirements that need to be taken into account when developing a new interactive platform or a development tool.

Furthermore, different alternative dissemination channels regarding potential influence in standardisation activities have been examined and evaluated, resulting in the selection of three dissemination channels which identified as potential candidates for Web accessibility standards, namely: (a) standards on user-centred design; (b) standards on accessible design; and, (c) quality standards. Finally, a specific action plan has been developed proposing two alternative dissemination strategies: (i) propose a new recommendation to existing standards, which in the opinion of the authors poses certain constraints, and (ii) propose a new part to on-going work, as for example the newly introduced work item on accessibility within ISO TC 159 / SC 4 / WG 5, which is likely to bypass the above constraints but any recommendation must fall within the software ergonomics perspective. The recommendation is accompanied by a time schedule for further actions.