This deliverable provides a consolidated view of the work carried out in the context of the Work Package 4 of the TIDE-WAI DE 4105 project, concerning the development of standardisation recommendations for the accessibility of Web-based applications and services. The reported work was based on a thorough investigation and assessment (carried out in the context of the project and reported in Deliverable 4.1) of the international state of the art with regards to current and on-going activities on the development of guidelines, recommendations and standards for Web accessibility. This investigation has identified a number of gaps and failures to support accessibility for different user groups and various interaction platforms. Moreover, this work was assisted from previous experience of the authors related to the development of requirements, guidelines and recommendations for supporting universal accessibility in HCI, in the context of their participation in the TIDE-ACCESS TP1001 project.

Following the aforementioned assessment, a number of standardisation recommendations are being proposed, comprising:

1. a preliminary collection of design-oriented guidelines, which aim to shed light into how user-centred design processes can be conducted, so as to account for the needs and requirements of the broadest possible user population; and,
2. specific software technology requirements which should be met by interaction platforms and development tools for interactive applications, so as to provide the required support for accessibility by different users in differing contexts of use.

The proposed design guidelines and software technology requirements are not intended to cover a particular technology, but to formulate a conceptual framework whereby accessibility becomes an integral component of the development life-cycle of interactive applications. However, specific references to Web technologies are explicitly made, to provide guidance in the application of these guidelines and requirements to currently available and emerging Web-related technologies, interaction platforms and tools.

Summary *

Table of Contents *

1. Introduction *

2. Data Collection and Analysis *

3. Consolidation & Recommendations *

4. Discussion and Future work *

References *

In the context of Work Package 4 of the TIDE-WAI DE 4105 project, a standardisation activity has been defined, aiming: (a) to identify and assess the international state of the art with regards to current, on-going and anticipated future standardisation activities related to Web accessibility; (b) to identify the requirements for Web accessibility and develop recommendations for meeting these requirements; and, (c) to disseminate the results to the relevant national, European and International standardisation bodies. A four-phase approach has been adopted by the project towards achieving the above objectives, comprising data collection, data analysis, consolidation & recommendations, and dissemination phases.

The data collection and data analysis phases (reported in Deliverable 4.1) provided a valuable insight towards what is currently missing from on-going activities related to accessibility guidelines, recommendations and standardisation work, as well as to how existing and future results can be propagated towards the relevant communities. Moreover, the analysis of the collected data enabled the derivation of several conclusions regarding the present coverage of the work on guidelines and recommendations, the current standardisation activities in the area of Web accessibility, and the existing policies and laws at national and European levels.

This deliverable presents a summarising account of the activities carried out up today in the context of the last two phases of the project, namely the consolidation & recommendations and dissemination phases, and focuses on the development of standardisation recommendations that cover issues not addressed by the existing sets of accessibility guidelines and recommendations. More specifically, the deliverable reports on:

• The development of process-oriented guidelines and software technology requirements aiming, respectively, to: extend human-centred design practices to better account for accessibility; and, to guide the evolution of existing, or the introduction of new Web technologies, so that they are inherently accessible by the broadest possible range od end users, under a multitude of usage contexts.
• The on-going efforts related to the dissemination of the resulting recommendations in appropriate standardisation bodies; alternative target organisations, committees and actual standards have been considered, and a tentative recommendation and action plan is currently being developed.

It should be clarified that the present work is not at the same level as existing guidelines on Web accessibility. The latter are of immense practical value, as they offer Web developers immediate and concrete guidance as to how to render the Web content they produce accessible by people with different types of special requirements. Recently, the scope of such guidelines has been extended to include the authoring tools with which such content is developed, as well as the user agents that enable users to attain, and interact with, the content. The current work introduces a somewhat different perspective to the accessibility of Web technologies, with the aim to: (a) take a further step towards addressing the fullest possible range of user requirements, across the broad range of existing and forthcoming / future technologies; and (b) to overcome the difficulty that current accessibility guidelines and recommendations face in reaching standardisation bodies.

To achieve the above stated objectives, the project work builds on the principles of design for all, as applied to HCI, and universal accessibility [Stephanidis et al, 1998] to cater for the different (and some time diverse) requirements of all potential users (including the disabled and elderly, the novice in technology, the mobile user, etc.), and the various contexts of use (home, workplace, on the move, etc.)

In particular, the development of standardisation recommendations in the present context aims to: (i) provide process-oriented guidance, through guidelines, on accessibility and universal design in HCI in general, and the development of Web-based applications and services in particular; and, (ii) translate the resulting guidelines into requirements that need to be met by the interaction platforms and the development tools, in order for them to provide the required support for building interactive applications and services accessible by the broadest possible end user population, including people with disabilities. The scope of the process-oriented design guidelines and the corresponding software technology requirements is deliberately broad in an attempt to provide a conceptual framework, independent of a particular technology / interaction platform, whereby universal accessibility is integrated in the development life-cycle of interactive applications and services. Specifically, the software technology requirements approach accessibility on the Web as an issue pertaining to interactive software with particular characteristics (e.g., presence of structural and presentational languages), so as to anticipate future developments and provide generic guidance that will be applicable beyond the current generation of relevant technologies.

Following the review of the current situation regarding standardisation work on Web accessibility and the consolidation of the collected data, alternative paths were examined and evaluated with the aim to define a specific dissemination strategy to be followed in the project. Three dissemination channels were initially identified as potential candidates for Web accessibility standards, namely: (a) standards on user-centred design; (b) standards on accessible design; and, (c) quality standards. In the next months, a final action plan is going to be developed taking into account the following criteria:

• the scope and coverage of particular standard organisations;
• the existing committees and the current standardisation activities that would be willing to accept new items in the specific field;
• the processes followed in proposing new standardisation activities and the time required for the development of a standard.

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. Moreover, the presented work has identified existing gaps in the process of developing accessibility standards, as well as new requirements imposed by the emergence of new Web technologies and Web-based applications and services; additionally, specific requirements for further standardisation work have been formulated.

In particular, as far as accessibility guidelines are concerned, the investigation and the subsequent analysis revealed that, although there are significant efforts in developing guidelines and recommendations for accessible Web documents, the areas covered are limited considering the scope and rapid developments in Web technologies. The main conclusions of the conducted investigation were:

• Existing (or under development) guidelines and recommendations mainly focus on the structure and presentation of Web documents (this includes individual guidelines, university or society guidelines, collective guidelines - e.g. W3C).
• Some recent efforts have addressed the development of guidelines for the accessibility of tools (user agents, authoring tools).
• Accessibility guidelines and available recommendations mainly address the requirements of blind users and the rendering of visual information in non-visual forms (mainly auditory), while other categories of disabled users and general accessibility requirements of able-bodied individuals are not explicitly addressed.
• Despite their availability, guidelines belonging to the above categories are rarely followed by Web developers, content creators and service providers.
• There is incompatibility between the features (both accessibility-oriented and general ones) supported by the leading Web browsers available in the market (e.g. Microsoft Internet Explorer versus Netscape Communicator).

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).

From the outcomes of the data collection and data analysis phases, it is evident that the vast majority of the available accessibility guidelines are formulated either as general design principles, or low-level and platform-specific recommendations. They are typically based on past experiences and best practice, while experimental evidence is typically rare [Casali, 1995]. Additionally, they cover specific user groups, such as blind and motor-impaired users, and provide guidance on how user interface software can be adapted to become accessible [Bergman and Johnson, 1995]. More specifically, in the case of the Web, accessibility guidelines (see http://www.w3c.org/WAI/) mainly concern requirements for the development of accessible Web Content, User Agents, and Authoring Tools. By implication, such guidelines do not fully address structural languages (e.g. XML), scripting languages and properties that are typically related to the overall interaction platform. On the other hand, the proliferation of interaction platforms and their continuous growth (e.g., HTML, VRML, XML, DHTML), necessitate an account of key requirements that should be preserved, if these developments and future ones are to comply with the broad accessibility objectives. Moreover, such guidelines offer limited guidance on the process of integrating accessibility into design and development activities.

The currently available 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), and the acknowledged bias towards the accessibility requirements of blind users. 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 later, 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 interactive 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” of 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 development tool 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, abstractions 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 interaction platform 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.

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.

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.

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.

This report describes process-oriented guidelines and software technology requirements, which have the potential to improve the practice of accessible design. The initial guidelines and requirements have gone through an iterative development process and consolidation through presentations and discussions in related conferences and workshops, such as the ERCIM Workshops on "User Interfaces for All" and the International Scientific forum towards an "Information Society for All", resulting to a concise set of 3 process-oriented guidelines and 4 software technology requirements which address accessibility both from a design and an implementation perspective. Moreover, an investigation of potential exploitation paths has been initiated with the aim to define a specific dissemination strategy towards relevant standardisation and regulation committees. Preliminary results of this examination led to the selection of three main standards categories where this work could be propagated: (a) user centred design standards, (b) standards focusing on accessibility, and (c) quality standards. Currently, we are in the process of examining how the compiled recommendations may contribute to the selected on-going standardisation activities, thus arriving at a specific action plan to be followed in the context of the project.