DE 4105 - WAI





Authors: Daniel Dardailler, Judy Brewer




Telematics Applications Programme






Date: August 99 -- Version number: 1.0
This file: (readers are encouraged to access this document online, since many supporting documents mentioned here are only available as hyperlink)


Table of contents


Part I: Executive Summary

Part II: Final Report

  1. Setting the Scene

  2. Approach

  3. Results and Achievements

  4. Conclusions and future plans

  5. Contact details

  6. Appendices

















DE 4105 WAI
Web Accessibility Initiative



Setting the Scene


The World Wide Web has become a vital resource for information and interaction. Close to 20% of the population experiences some form of disability; many of these conditions can present barriers to accessing information technology. It is essential to ensure the accessibility of the Web in order to provide access to educational, employment, commerce and civic opportunity.
The Web Accessibility Initiative (WAI) is hosted by the World Wide Web Consortium (W3C - http:/, an international vendor-neutral consortium which develops technologies to promote the interoperability and evolution of the Web. W3C provides a setting where WAI can bring together industry, disability organizations, accessibility researchers and government to explore accessibility requirements and develop accessibility solutions. For the past 18 months, WAI-DE has provided an opportunity to promote coordination with European organizations focusing on Web accessibility, and to develop materials and activities to support outreach to European organizations.



Global problems require global approaches. In the case of Web accessibility, WAI-DE has aligned itself with the W3C's Web Accessibility Initiative, and focused on ensuring a strong European component to the guidelines, tools, and educational work going on at WAI. WAI-DE has developed a variety of European-specific materials for outreach, and continues to expand its partnerships with industry, disability organizations, research centers, and governments in Europe around issues of Web accessibility. WAI addresses accessibility of the Web at the design table, in broadly-based consensus forums, operating under W3C process.


Results and Achievements

The WAI DE 4105 four work-packages (education, tools, standards, user forum, plus one for project management) have all delivered as expected: more than 25 presentation were made in European public conferences; Outreach materials such as Quick Tips cards, leaflets, video, demonstration sites, and translations in several European languages were made; Tools were specified and written; Standard studies made and a very active User Forum launched and actively maintained.


Conclusions and Plans for the Future

We consider the project to a success wrt outreach and tools development goals, however there's still more work to be done. Some of this work involves increasing awareness of the needs for accessibility for users of Web technologies, some involves the development of advanced tools. We are therefore proposing to continue this WAI European project in the fifth framework (IST) and focus the advanced education and tools aspects of Web accessibility in Europe.


Contact Details

Project Name:
WAI - Web Accessibility Initiative

Research Area:
Web Accessibility for People with Disabilities

01.01.98 - 31.06.99

Overall cost: 672000 ECU
European Commission contribution: 672000 ECU
Project Proposal:

Web, Web Accessibility, Education and Outreach, Assistive Technology and Tools.

Key Project Participants:


Project Coordinator:
Daniel Dardailler
Tel: +33 4 92 38 79 83
Fax: +33 4 92 38 78 22
Project URL:


1. Setting the Scene

Millions of people use the Web daily for services related to their professional and personal interests. The Web provides information on every topic; it provides a vehicle for civic participation, commercial transactions, and education. It gives people access to world news, employment opportunities, and each other. Yet for many people with disabilities, it is currently difficult or impossible to access the Web.

The Web Accessibility Initiative (WAI) is hosted by the World Wide Web Consortium (W3C), an international vendor-neutral consortium which develops technologies to promote the interoperability and evolution of the Web. The W3C coordinates the development of core Web protocols and data formats: HTML, XML, CSS, SMIL, etc. W3C provides a setting where WAI can bring together industry, disability organizations, accessibility researchers and government representatives to explore accessibility requirements and develop accessibility solutions.

The Web Accessibility Initiative (WAI) at the World Wide Web Consortium (W3C) focuses on making the Web accessible to existing and potential Web users who have disabilities. W3C's credibility further assists in ensuring the successful promotion of WAI guidelines, tools, and educational materials to a variety of audiences, including browser and authoring tool manufacturers and site developers.

For the past 18 months, WAI-DE has provided an opportunity to promote coordination with European organizations focusing on Web accessibility, and to develop materials and activities to support outreach to European organizations.

As the Web rapidly displaces existing media, there is an increasing social expectation for its accessibility, and also a growing trend to require accessibility. This, combined with the realization of the benefits that a Design for All approach can bring to the Web at large (for instance, to mobile phone users with limited display screens), led the W3C to take on a leadership role and launch the Web Accessibility Initiative (WAI) program in 1997.

Current Situation

The accessibility of the Web is worsening, due to increasing use of multimedia and advanced Web technologies, while awareness of the need for Web accessibility is only gradually increasing. Web accessibility barriers exist for many kinds of disabilities:

Over the past two years, WAI has developed guidelines and technical reference documents which have achieved international recognition. Awareness of WAI guidelines is spreading in both the public and private sectors. Emerging policy requirements for Web accessibility in various countries, combined with education and outreach efforts of WAI and collaborating organizations, should spur this awareness onward.

In addition to policy requirements for Web accessibility, many organizations have expressed interest in the carry-over benefits of accessibility for other users. Even those without disabilities benefit from many changes motivated by the needs of people with disabilities. When driving a car, for example, a driver may wish to browse the Web for information using a voice-based interface similar to that used by someone who is blind. This is sometimes referred to as "Design for All," or the curb-cut effect, where an accessibility-driven design such as a mini-ramp in a sidewalk curb allows easier passage for wheelchair users but is also favored by people pushing baby strollers, riding bikes, pulling luggage on wheels, etc. In particular, the mobile phone industry has expressed interest in the contributions of Web accessibility to greater usability for all.

WAI's workplan has capitalized on the unique host environment of the W3C to provide access to the earliest design stages of Web technologies. WAI has successfully used the formal W3C process for review and approval of specifications to ensure consensus-based accessibility guidelines; and both WAI and WAI-DE continue to benefit from the W3C setting in developing high-quality support and reference materials to assist in promoting these guidelines.


2. Approach


WAI's approach to improving accessibility of the Web is based on the realization that many things have to be done to reach the goal of Web accessibility, and that while a limited European action like this can only address some aspects of the problem, it can greatly benefit from association with a broader initiative.

W3C has an activity in the area of Web Accessibility, called WAI. We use "WAI-DE 4105" in this report to indicate the Telematics project. WAI primarily focuses on technology groups working on the accessibility of the core Web formats such as HTML, XML, and CSS; and also on a set of guidelines accompanying the technologies, that address accessibility of Web content, and of browsers and authoring tools. WAI is organized to pursue accessibility of the Web through five areas of work:

  1. Technology review and development: centered on protocols and data formats, especially HTML, CSS, XML, SMIL, DOM.
  2. Guidelines for use of the technology: targeted to user agent and authoring tool developers, and to Web content developers.
  3. Education and outreach: raising awareness of the content creation community around the concept of Design for All;
  4. Tools for evaluation and repair of Web pages.
  5. Coordination with research and advanced development.

From among these work areas, the WAI-DE 4105 project concentrated on education and outreach in Europe, specification and prototyping of tools, standardization, and the hosting of an umbrella User Forum Interest Group.

Approaches for each of these work-packages are detailed below.

In order to meet the requirement of "globality" of Web Accessibility, W3C combined its own membership funds plus those of various industries and governments with funding from the European Commission. In so doing, it helped ensure that W3C staff developing Web protocols will participate with this European action to ensure that the evolution of the Web removes, rather than reinforces, barriers to the Web.

It is important to note that this grant is hosted by the World Wide Web Consortium (W3C), an international non-for-profit, vendor-neutral organization which fosters the evolution of the major Web protocol and format specifications, and whose goal is to lead the Web to its full potential (a long description of W3C is provided in the contact section). Being located at the heart of Web technology design allows WAI to address accessibility issues very early in the development cycle, and also to sensitize technologists world-wide to Design for All principles.

The WAI-DE 4105 Telematics proposal complements W3C WAI technical work by addressing content providers -- the people that create and distribute the information -- and end-users, through its user forum and tool workpackage. WAI-DE 4105 focuses on the European Web content providers and market. This approach enables different "stakeholders" in accessibility to work together at the design table. Over a hundred organizations from around the world participate in some part of WAI work, including: industry, disability organizations, access research centers, and governments. An increasing number of these organizations are European, due to WAI-DE 4105's activity.

As global as the Internet and the Web are, there is still a clear need for "local" actions when content providers are the target. A similar fund-raising activity for education and dissemination is being pursued by W3C for the Americas and the Pacific rim. We think all these actions are required for the Web as a whole to become more accessible.

Integration of WAI-DE 4105 with W3C WAI

It is important that the integration between W3C WAI and WAI-DE 4105 has been tight in order to maximise the leveraging of W3C actions in the DE project. WAI has therefore extended and improved the overall W3C WAI deliverables and charters, and cross-linked them with the WAI-DE deliverables.

W3C has a very formal framework for organizing its activities, under a structure of Working and Interest Groups which must first have defined charters, that first must define their charters. This is know as the W3C Process. Most WAI DE work-packages have been brought under this structure.

To ensure that this integration is well managed, the W3C WAI International Program Office itself has a Steering Committee, composed of members chosen by the U.S. National Science Foundation; the European Commission (specified by the DE Program Director); disability organizations; and private sponsors most of which are W3C Members.

This approach has led us to a very synergistic project, involving cooperation from disability organizations, researchers and engineers world-wide, not just limited to Europe.

Education & Outreach workplan

In order to reach improve Web accessibility, it is important to target a variety of audiences. Content providers are one of WAI's primary targets since they determine much of the content on Web sites.

However, content providers are also influenced by other players: authoring tool vendors, Web site designers, Web-design educators, the press, and the user base. In order to reach all these communities, WAI must direct its efforts through a variety of activities -- presentations in major Web industry conferences; direct contact and awareness action with major European Web site providers; addition of accessibility "modules" in Web design curricula; direct contact with major authoring tool providers; submission of articles to the press, etc.

Another educational aspect also needs to be explored: the education of the disability community itself regarding their rights with respect to accessing information like everyone else. This is particularly true and important in the context of the Intranet, where some countries are already subject to existing legislation regarding access (see the US Americans with Disabilities Act or the UK Disability Discrimination Act). WAI has compiled a reference list of polices related to Web accessibility, which has become a key resource for the disability community.

While education and outreach are crucial aspects of WAI's work overall, these are not something that has traditionally fallen within W3C's role. Clearly, part of the raising of awareness should take place as part of the training that is packaged with any Web authoring tool. But part of this work also goes beyond individual tools, and is part of the traditional role of government: helping sensitize key players, including content providers, to the needs of an important minority population.

Approach on Tools

To complement work on improving Web technologies and producing guidelines, WAI has been developing tools to evaluate Web Content accessibility and repair inaccessible pages, and coordinating with organizations that develop such tools.

WAI-DE decided to depart from its original tools goal to develop a PICS accessibility implementation, and decided to expand the scope of this workpackage beyond the study and prototyping of PICS in the context of accessibility but to work on the more general problem of implementing tools that provide evaluation, transformation and repair of Web sites. One reason was that PICS was becoming a dated technology without convincing uptake by industry; another was the pressing need for other types of tools.

Since a lot of people and organizations are working on such tools within and outside W3C, and in order to converge on the measurement criteria for Web accessibility, we first needed to put some effort into coordination in the area of accessibility validation and tool prototypes. There is also a need to develop novel tools that end-users have expressed a need for.

WAI-DE's approach here has been to create and closely integrate with a new W3C WAI activity focused on tools and supplement it with specific resources as needed.

This was organized around a W3C working group called WAI-ER (for Evaluation and Repair), with a charter to examine:

  1. What features are needed for an evaluation tool?  This includes the question of  "rating", e.g. what if any weighting factors should be given to problems the evaluation tools detect?
  2. What features are needed for a repair tool?
  3. What features are needed for "filtering tools" used by end users to help make sites accessible to them.
  4. How should features be packaged?
  5. How should tools be made most usable?
  6. Once tools are completed (e.g. in beta) what improvement may be made?

We found our early work on PICS Rating System to be usable in this context (see result section) but we have now allocated more time in the framework of this ER group on collecting and analyzing input from users who benefit from these tools, including users with disabilities, Web authors and administrators, content owners, and tool vendors.


In order to determine precisely what could be the scope of any future standardisation activities regarding accessibility of Web-based interactive applications and services, an investigation has been undertaken by our partner FORTH covering the broad international state of the art.

This activity aimed at: (a) identifyng and assessing the international state of the art with regards to current, on-going and anticipated future standardisation activities related to Web accessibility; (b) identifying the requirements for Web accessibility and develop recommendations for meeting these requirements; and, (c) disseminating 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:

The data collection and data analysis phases provided valuable insight into what is currently missing from on-going activities related to accessibility guidelines, recommendations and standardisation work, as well as into 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 task also addressed identification of unified interaction requirements in Web-based applications and services, facilitation of accessible and high quality interfaces for user with different requirements, and abilities and preferences, including disabled and elderly, following the concept of design for all.

It should be clarified that the standardization workpackage study is not at the same level as existing W3C WAI 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. The work in WP04 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.


3. Results and Achievements

The WAI DE 4105 four work-packages (education, tools, standards, user forum, plus one for Project Management) have all delivered as expected: more than 25 presentation were made in European public conferences; Outreach materials such as Quick Tips cards, leaflets, video, demonstration sites, and translations in several European languages were made; Tools were specified and written; Standard studies made and a very active User Forum launched and actively maintained.

WP02: Education and outreach

The goal of this dissemination/awareness workpackage was to promote the realization of accessible Web content throughout Europe.

It does so by developing strategies and materials to increase awareness in the Web community of the need for Web accessibility, and to educate the Web community regarding solutions to Web accessibility. The end-result shown here is primarily a list of public presentations where WAI specific materials are distributed or shown.

Because of the initial ramping up process to create a formal W3C working groups on Education, this workpackage did not really start its activity until the end of March 1998, so as a result, the beginning and end dates (same duration) were shifted three months ahead (with approval from the Commission office).

During this period, a number of events/talks/presentations promoting WAI were made in Europe by WAI-DE paid staff (this constitutes Deliverable D2.1 of the project proposal):

In addition, various European press and radio interviews and press releases were made during the period and we also submitted and included of a complete chapter (20 pages) on WAI in the "User Interfaces for All" book to be published in 1999 by Lawrence Erlbaum Associates.

Due to its participation in the project, EBU's 44 member organisations have been widely informed about WAI and the Guidelines. In particular, a simplified version of the WAI FAQ page was reproduced in issue No 23 of the EBU Newsletter. Some organisations which are in the process of starting their own sites have come back to us for more detailed information.

As some the presentation locations show, WAI-DE has been leveraging the new W3C Office presence (Germany, UK, Italy, Sweden, the Netherlands, etc) to do outreach in Europe about Web accessibility. These offices are W3C points of contact in various countries were the impact of W3C industry outreach coming from MIT, INRIA or Keio is less important.

Materials developed by WAI-DE

The first three items constitute deliverable D2.2 of the project proposal (Accessibility modules and materials).

RNIB WAI Film: A 16 minute video entitled "Websites that Work" on how people with disabilities access the Web was developed by our RNIB partner and launched at the "Global Cafe" in London in front of about 150 persons. The screening was aimed at Commissioners of Websites (e.g., from banking associations). This launch received good media interest and from disability organizations. An awards ceremony was conducted at the same time.

The draft script of the film was provided in the December 1998 WAI-DE report and excerpts of the film will be shown at the final review in September 1999 in Brussels.

We have already shown this movie in several settings and are planning continue in other parts of Europe. Several thousands copies of the video are planned to be produced and we are also looking at converting it into two Web formats: SMIL and Quicktime. We're currently planning a number of other promotional activities around the film.

See also the section below on the ERCIM CDRom.

ERCIM CD: At the occasion of the 10th anniversary of ERCIM in 1999 (European Research Consortium for Informatics and Mathematics), the ERCIM asked each member organizations (all 14 Computer Science National Labs in Europe) to participate in a CDRom highlighting two important activities per institute.

For INRIA (host of W3C in Europe), WAI was chosen and a multimedia presentation was designed and incorporated into the anniversary CD. This presentation incorporates short clips of the WAI Film within a nice page setup suited for the CD layout. An additional filming session occurred to complete the series of clips presenting WAI.

The CDRom will be briefly demonstrated at final review time. It is available online at, but please note that it may not suitable for online use given the size of the video clips to download.

Demonstration site: In order to demonstrate the effect of accessible design on Web sites, an online demonstration was designed and implemented by WAI-DE participants.

The demo features a common frame-based Web site layout. This was initially a real Web site fetched off the Web in its inaccessible state, but text was changed to respect privacy. A simulation of browsing using an assistive technology browser (text-only) such as Lynx is then performed and then the demo goes in a tutorial mode on how to repair the site. The same site is then presented in its accessible form with and without Lynx.

This example is of great value as a simple tutorial and our past presentations using it have shown that the audience is very receptive of the problems of accessibility one they've observed the issues themselves.

The current version of this demo is online at:

The next three items constitutes the deliverable D2.3 of the project proposal (education guideline material).

BrailletNet leaflet: the WAI-DE French partner produced a leaflet on Web accessibility. This falls between guidelines (long) and Quick Tips (very short) in detail and complexity.

A French, English and Spanish version are available on hard copy paper (glossy) ready to be distributed. The launch of this promotional material received national press attention in France.

Although this first version focused on visual impairment, a second version putting the emphasis on cross-disability is already under development. This is an important step forward for an organization such as BrailleNet to include not only just blindness issues, and this commitment is a direct result of coordination with WAI.

Samples of the leaflet will be attached to the final report hard-copies.

Web Content Accessibility Guidelines (WCAG) translations: In May 1999, the W3C released Web Content Accessibility Guidelines 1.0 (WCAG) which is foundation document for Web Accessibility. The normative document is in English only, however several translations in European languages have been initiated by the WAI-DE project.

A mailing list set up at W3C is used to manage the translation work and the review of translated work. As of July 1999, we have the following translations completed: French version, German Translation, Norwegian translation, Swedish translation.

Additional translations in Danish, Dutch, Portuguese and Spanish are under development and close to being finished.

See Appendix G for a copy of the WCAG checklist.

Alternative browsers: this is a collection of pointers to information, and where possible, to demonstration versions of alternative browsing methods, different from traditional mouse-and-screen-based browsers. We include the latest version of this resource at time report was sent as Appendix F.

Quick Tips business cards translation: the W3C WAI EO activity has produced a 2-side business card summarizing the WAI Web Content Guidelines. These are meant to be distributed at conferences and events world-wide. This work was only partially funded by WAI-DE: the design of the card was done mostly my WAI-DE paid participants but the mass production (75000 copies) was paid for by other WAI funding (in the US).

The primary version is in English so we also started a translation process into several European languages. The French version is already available.

Copies of the real card are provided with the final report on paper.

Supporting documents (with help from WAI-DE)

Unlike the above list, which can be completely counted as part of scheduled WAI-DE deliverables, the following resources were not primarily WAI-DE funded but some percentage of Commission funds was spent to develop each of them. This was through participation in W3C's WAI EO working group by paid WAI-DE participants.

Events calendar: we maintain a global events page listing world-wide outreach events, used by participants in the project to coordinate their presence in these events, including events in Europe.

Policy references resource: this is a Policy References resource consisting of a review of current legislation applicable in the field of online and telecommunication accessibility international, which our European partners have actively participated in developing. This helped us realized that Europe is lagging behind in terms of disability policy. As a result of coordination meetings, actions have been taken notably in Italy, Denmark, France, and Portugal. For instance, in the case of Portugal, a recent major achievement was for the Portuguese Parliament to approve the Petition for the Accessibility of the Portuguese Internet as recommendation to the Government. This happened 30th of June 1999 and the Web Accessibility Initiate was mentioned in this parliament report.

Other deliverables, such as the WAI slide set for seminars or the WAI logos for compliance with the guidelines, were also produced with help from personnel paid by WAI-DE, acting as participants in the W3C WAI working groups.

WP03: Tools

The original Project Proposal defined 4 deliverables in this workpackage:

As explained in the approach section and in interim reports, we departed from this original plan after realizing that developing a PICS rating system and running a PICS label bureau server was not very useful in itself and that we needed to work on broader aspects of evaluation criteria and repair tools as well.

Our set of deliverables now comprises:

We provide in Appendix C the layout of the reporting tool pages and template messages sent to Webmasters.

WP04: Standards

As indicated in the approach section, this workpackage, handled by our FORTH partner, followed a four-phase plan towards achieving its objectives, comprising data collection, data analysis, consolidation & recommendations, and dissemination phases.

The data collection and data analysis phases (presented in earlier report) 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. The final deliverable 4.3 (Appendix D) presents a summary account of the activities carried out 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, this final deliverable reports on:

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 identified as potential candidates for Web accessibility standards, namely: (a) standards on user-centred design; (b) standards on accessible design; and, (c) quality standards. The final action plan proposes two alternative dissemination strategies, taking into account the following criteria:

The first of the aforementioned strategies, which would involve the addition of new recommendations to existing standards, was found to be difficult or, in some cases, unfeasible. The second, recommended strategy, involves the introduction of new parts in on-going standardisation activities.

Please refer to the Appendix on deliverable 4.3 for details on this work.

WP05: User Forum

This section constitutes deliverables 5.1, 5.2 and 5.3 of the project proposal.

W3C's WAI maintains a User Forum as an online mailing list which meets face-to-face three or four times per year and that is also used by the WAI-DE project workpackages to gather user needs and requirements.

The forum is active under the alias

which is also the formal name of the W3C WAI overall Interest Group.

More than 330 persons are registered in this online forum, with an average traffic of more than 200 messages per month.

It is the best way to stay informed of overall WAI activities, and to participate in general WAI discussions.

A public archive of the most recent messages sent to this list is available at: In parallel to this generic end-user activity, a direct campaigning action involving European end-users was conducted by WAI-DE.

The next section reports on some of the campaign action findings.

Review campaign and promotion

Between October 1998 and February 1999, EBU (European Blind Users) and BrailleNet users conducted an experiment with direct reviewing and reporting of Web site accessibility problems, mostly in France.

A study on the accessibility of 111 Web sites has been conducted. The results of this study will be in a paper presented at the AAATE Conference which will take place in Düsseldorf, Germany, next November.

This study can be summarised as follow:

The Web sites belonged to several categories : newspapers, radio and television channels, national and international institutions, public services, culture, education, Web sites related to impairment, leisure and so on.

The accessibility of those 111 Web sites was evaluated according to the WAI recommendations. An evaluation with the help of the tool Bobby was not possible because each page should have been tested separately, and some accessibility problems cannot be evaluated automatically.

Two different browsers were used for the evaluation: Internet Explorer 3 with a Braille display and a screen reader, and BrailleSurf, the specific browser developed by INSERM, with a Braille display and a speech synthesiser.

In summary, over the 111 sites, about 20% are completely accessible, 20% rather accessible, 40% are not very accessible, and 20% are not accessible at all. The accessibility of the Web sites did not depend on the category they belong to. It only depends on the way the Web site designer has developed his site.

The evaluation of these sites shows that on the one hand, many Web site designers favour visual design of the site to attract as many visitors as possible. On the other hand, other designers favour access to information and the site accessibility, for instance most of the sites at international institutions.

The reviewer encountered two categories of problems: technical and conceptual problems. Some problems must be solved by screen readers themselves, according to the evolution of Web technology. Since, for example, image maps are more frequently used and some screen readers cannot handled them, developers of access software should better improve their software, instead of forbidding Web site designers to use image maps for their sites.

However, other problems must be solved by the Web site author when he or she follows the WAI recommendations. The technical problems can be more or less easily solved, since it is often necessary to add an HTML element or attribute, or to change a text formulation to make the site accessible. On the other hand, the conceptual problems are more difficult to solve, as it is easier to make a site accessible before its creation, than to make the site accessible once it already exists.

The analysis of those 111 Web sites shows a constant need to inform Web site designers so that the WAI recommendations can be better taken into account. As a result, letters have been sent to Webmasters of interesting Web sites to inform them about the accessibility problems encountered on their Web sites. Some design improvements were suggested with pointers to the WAI Web site so that then can check the accessibility of their site and understand what to change to improve this accessibility. The table in Appendix E shows the results of the letter actions.

Summarizing the results of this review campaign, it appears that many of the owners of these sites are not yet aware of how accessibility may benefit their commercial interest. Nevertheless we had some good results with some of them, which led to a co-operation with Webmasters to improve the site accessibility.

The value of this kind of letter campaign lies not so much in the breadth of sites involved (only French sites) but in the analysis of the kind of responses received from Webmasters and in their willingness to communicate with us about the accessibility problems of their documents.


4. Conclusions and Plans for the Future


We consider the project to a success wrt outreach and tools development goals, however there's still more work to be done. Some of this work involves increasing awareness of the needs for accessibility for users of Web technologies. In addition, new Web technologies are still coming out on the market at a rapid pace that potentially creates new challenges for people with disabilities. We are therefore proposing to continue this WAI European project in the fifth framework (IST) and focus the advanced education and tools aspects of Web accessibility in Europe.

In particular, we believe a systematic review process needs to be organized under the auspices of WAI, involving country-specific evaluation teams, with international coordination, and the creation of a showcase gallery of accessible sites.

The needs for additional work on advanced tools comes from the recognition that some of the Web today is not yet accessible so we need to account for practical measures to provide access to those pages that cannot or will not improve.

Finally, we think that a close coordination between the Web technology developers and providers (the W3C and its membership), and the promotion and tool development activities outline in our proposal for future work, is required in order to achieve these objectives and help meet the needs of people with disabilities in Europe toward a user-friendly information society for all.

5. Contact details


Project Consortium:WAI (Web Accessibility Initiative) DE 4105

Contact address for the Project:

Daniel Dardailler
2004 Route des Lucioles
06 902 Sophia Antipolis

Tel: +33 4 92 38 79 83
Fax: +33 4 92 38 78 22



In addition to INRIA/W3C as the main contractor, ICS/FORTH is an associated contractor (responsible for the Standardization workpackage), and there are 4 sub-contractors: INSERM/BrailleNet, EBU and RNIB (for W3C/INRIA) and CNR (for FORTH). All the partners are non-for-profit organizations.

The project started in January 1998, ran for 18 months and had 5 Work Packages:

The Overall cost of the project was 672000 ECU and the European Commission contribution was 100% of these costs (support/accompanying action). The original project proposal is available online at the URL

The following sections provide a description of the partners and contractors in the project.

World Wide Web Consortium

The W3C was founded in October 1994 to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability.

It's an international industry consortium, jointly hosted by the Massachusetts Institute of Technology Laboratory for Computer Science [MIT/LCS] in the United States; the Institut National de Recherche en Informatique et en Automatique [INRIA] in Europe; and the Keio University Shonan Fujisawa Campus in Japan.

Services provided by the Consortium include: a repository of information about the World Wide Web for developers and users; reference code implementations to embody and promote standards; and various prototype and sample applications to demonstrate use of new technology.

The Consortium is led by Tim Berners-Lee, Director and creator of the World Wide Web, and Jean-François Abramatic, Chairman. W3C is funded by Member organizations (around 280 in August 1998), and is vendor neutral, working with the global community to produce specifications and reference software that is made freely available throughout the world.

W3C produces Recommendations, documents often called "W3C standards", that define and evolve the core languages and protocols of the Web: HTML (Hypertext Markup Language), HTTP (Hypertext Transfer Protocol), CSS (Cascading Style Sheet), etc.

W3C's main site is at

INSERM/BrailleNet (BN) Backgrounder

BrailleNet is a French consortium whose mission is to promote the Internet for social, professional, and school integration of visually impaired people. Its objectives are to improve Internet access for visually impaired people, to develop pilot Web site containing specific services, to explore tele-working and education thru Internet and disseminate result of work to end-users.

The BrailleNet consortium regroups INSERM (French National Institute on Medical Research), EUROBRAILLE (first maker of Braille terminals), AFEI (specialized in the formation of visually impaired people), CNEFEI (specialized in the formation of teachers), ANPEA (National Association of Parents of Visually Impaired Children), FAF (Federation of Blind and Visually Impaired in France).

BrailleNet Web site is

European Blind Union (EBU) Backgrounder

EBU is a non-governmental and non-profit making European organisation, founded in 1984. It is the principal organisation representing the interests of blind and partially sighted people in Europe with membership made up or organisations of and for visually impaired (VI) people in 43 European countries. EBU has formal consultative status as the co-ordinating NGO for the visual impairment sector on the European Disability Forum in Brussels.

EBU Web site is at:

Royal National Institute for the Blind (RNIB) Backgrounder

RNIB is the largest organisation in the UK looking after the needs of visually impaired people, with over 60 services. Current reappraisal of its work has led to services being increasingly considered in terms of supplying the needs of visually-impaired people at every stage of their lives and in various aspects. The organisation employs around 2500 people based throughout the UK, of whom 7% are visually-impaired. RNIB has already been involved as a partner in the CAPS (136/218) and Harmony (1226) projects.

RNIB Web site is

Foundation for Research and Technology - Hellas (ICS/FORTH) Backgrounder

Foundation for Research and Technology - Hellas (FORTH, Greece), is a centre for research and development monitored by the Ministry of Industry, Energy and Technology (General Secretariat of Research and Technology) of the Greek Government. The Institute of Computer Science, one of the seven institutes of FORTH, conducts applied research, develops applications and products, and provides services. Current R&D activities focus on information systems, software engineering, parallel architectures and distributed systems, computer vision and robotics, digital communications, network management, machine learning, decision support systems, formal methods in concurrent systems, computer architectures and VLSI design, computer aided design, medical information systems, human-computer interaction, and rehabilitation tele-informatics. ICS-FORTH has a long research and development tradition in the design and development of user interfaces that are accessible and usable by a wide range of people, including disabled and elderly people. It has recently proposed the concept, and provided the technical framework for the development of unified user interfaces, that are adaptable to the abilities, requirements and preferences of the end user groups.

ICS/FORTH Web site is at

National Research Council (CNR) Backgrounder

The National Research Council (CNR, Italy) is a government research organisation (staff of about 7000), which is involved in activities addressing most disciplinary sectors (physics, chemistry, medicine, agriculture, etc), in cooperation with universities and industry (one of its tasks being the transfer of innovations to production and services).

CNR Web site is at








6. Appendices

Appendix A: IPR

The Telematics DE head office has empowered the W3C as the single entity who distributes the results from the project, provided that no commercial use is made.

W3C's WAI therefore makes these documents available consistent with W3C copyright and documents use policy, which ensure that all the deliverables (Education material, Guidelines, Tools, etc) are for general Public access, delivered via the W3C WAI site.

The text of the agreement, signed by W3C, FORTH and TAP DE in February 1998, is:

The World Wide Web Consortium (W3C) through INRIA, as prime contractor for project DE4205-WAI, requests the permission of the Disabled & Elderly Sector of the TELEMATICS Applications Programme DGXIII to become the sole entity authorised to publicly distribute the results of the project. We certify that no commercial exploitation is intended and the results will be available free of charge on the W3C's WWW page. This request is made also on behalf of FORTH, partner in the DE4205-WAI project.

Appendix B: WAI-DE Steering Committee

WAI-DE had a Project Steering Committee that consisted of the two main contractor managers, together with least one representative of each associated contractor and a Quality Panel representative. It was responsible for the overall strategy. It also had specific responsibility for ensuring that recommendations of the Quality Panel are adhered to by the Workpackage managers doing the technical and awareness developments and dissemination.

Besides face-to-face meetings, WAI-DE Project Steering Committee meets electronically under the alias:

The following people were members of this committee:

This electronic mailing list and a Web site, hosted at W3C, are used as the day-to-day management vehicle.

W3C acts as the overall project management contact and is responsible to communicating the reports and deliverables to the Commission.

Reports and deliverables were made available to the Commission using electronic mail and Web downloading site.

The Steering Committee or a subset of it (just the W3C sub-contractors for instance) also met using phone conference facilities provided by INRIA W3C office.

Appendix C: Report tool pages

This Report tool is a step-by-step form filling session where end-users reviewing Web sites are guided for their reporting of accessibility issues. It is available online at and a copy is provided here for illustration (not the active version).

The first page asks the person to enter the address of a Web site or page to be reviewed:

W3C logo Web  Accessibility Initiative (WAI) logo

Web Accessibility Report Tool

Welcome to the WAI Accessibility Report Tool. The W3C Web Accessibility Initiative (WAI) has set up this step by step form to track and provide solutions for commonly encountered accessibility problems, such as pages that don't work when images, scripts, or style sheets are unusable, turned off, or not supported.

By taking the time to review pages for accessibility and filling out this form, you will help authors correct accessibility problems in their pages - your messages are sent directly to authors. At the same time you will help WAI understand patterns of inaccessible pages, useful for additions to the Web Content Accessibility Guidelines.

Step 1

Please enter the URL of the page you are reviewing:

Use the "Continue" button to advance to Step 2.

The second step checks for validity and duplicate report for that page and then the main page is presented as a third step:

W3C logoWeb  Accessibility Initiative (WAI) logo

Web Accessibility Report Tool

Step 3: Identify Problems On

Please enter (or correct) the email address of the page/site author:

Please enter your email address:

Please enter your name:

Please check each problem encountered. Each problem is followed by a link to the relevant checkpoint in the Web Content Accessibility Guidelines 1.0.

Missing or inappropriate alternative text for an Image or Animation (Checkpoint 1.1)
Missing text links for a server-side Image Map (Checkpoint 1.2)
Missing "title" or "name" attribute on FRAME (Checkpoint 12.1)
Complex FRAMESET without NOFRAMES (Checkpoint 6.5)
Complex TABLE unreadable when linearized (Checkpoint 5.3)
Unexpected auto-redirect to another page (Checkpoint 7.4)
Missing "alt" attribute for SCRIPT/APPLET (Checkpoint 6.3)
Missing structural elements (H1-H6, UL, OL, etc.) (Checkpoint 3.5)
Invalid HTML (Checkpoint 11.1)
Moving/blinking text (Checkpoint 7.2)
Misuse of structural markup for layout (e.g., UL or BLOCKQUOTE to indent text) (Checkpoint 3.6)
Uninformative hyperlink text (e.g., "Click Here") (Checkpoint 13.1)
Missing long description for graphics (Checkpoint 1.1)
Missing caption/transcript for Audio/Video (Checkpoint 1.3)
Missing means to skip multi-line ASCII art (Checkpoint 13.10)
Color contrast insufficient (Checkpoint 2.2)
Color alone used to convey meaning (Checkpoint 2.1)
Page inaccessible and no alternative page available (Checkpoint 11.4)
Other (please describe):

Browser used: other:

Subjective rating section: overall, how would you rate this page/site for:

Please use the "Continue" button to advance to Step 4.

The person is then asked for confirmation of the text of the message that is going to be sent to the presumed author of the page:

W3C logoWeb  Accessibility Initiative (WAI) logo

Web Accessibility Report Tool

Step 4 (Final step): Confirm Your Report

The WAI Report Tool has generated the following message based on your input. Please review and correct if necessary (by using your browser's back button to return to previous steps). When you're satisfied, send it by using the "Send Message" button at the bottom of the page.

If you want to make comments on this report tool, please send a message to

Subject: WAI Report on


This message comes to you from the World Wide Web Consortium's Web Accessibility Initiative (W3C WAI) report tool at

Date: Wed Aug 1 06:46:27 1999

Your Web site has been found to have to one or more accessibility problems. This is not an automatic evaluation. This message is the result of an individual's review of your page or site (refer to the cc: field). This person experienced difficulty accessing your page either due to a disability (visual, auditory, physical, or cognitive) or due to device limitations (poor connection bandwidth, no support for graphics or support turned off, a voice interface such as a webphone, etc.). Please consider their comments below.

with: Netscape Navigator 4.5

The reviewer found the following accessibility problems with your page or site. Each item is followed by a link to relevant information in the Web Content Accessibility Guidelines 1.0.

Additional subjective comments from the reporter:

Your name, the URL of your page, and the URLs of other pages reviewed using this tool have been entered in a W3C WAI database that we maintain (currently implemented as an archived mailing list visible at

Please take the time to review this report and take action on the problems reported. If you have questions, please notify us at, so that we can re-evaluate your page.

Note. These comments were made by someone who visited your Web site who may not be affiliated with W3C or the WAI. For this reason, WAI does not take responsibility for the accuracy of this report nor the comments made in the report. For more information about the W3C Web Accessibility Initiative please visit


using the W3C WAI Accessibility Initiative Report Tool

Appendix D: Deliverable 4.3 on standardization


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:


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:


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.


1.1 Data Collection Methods


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:

Standardisation Organisations and Web related Committees / Societies


International Organisation for Standardisation - ISO

  • ISO 13.180 Ergonomics (
  • ISO/IEC JTC 1 Information Technology (
  • ISO/IEC JTC1 SC34/SC18 WG8 (
  • ISO TC46 SC4 Computer applications in information and documentation (
  • ISO TC159 SC 4 (
  • ISO/IEC Directives (
  • Stages of the development of International Standards (
  • Standards: User Interface Standards in the ISO Ergonomics Technical Committee (

American National Standards Institute - ANSI

  • ANSI Standards Action (

European Committee for Standardisation - CEN

  • CEN/ISSS - Information Society Standardisation System (

IEEE Standards

  • IEEE Standards Association (
  • IEEE Standards Bearer (
  • Internet Best Practices (
  • Standards Working Group, Recommended Practice for Internet Practices - Web Page Engineering - Intranet/Extranet Applications IEEE CS Project P2001 (
  • IEEE Standards Products Catalogue: Software Engineering (

International Electrotechnical Commission - IEC

  • IEC TC 3 Documentation and graphical symbols (
  • IEC/TC3 - ISO/TC10 Special Joint Working Group 13 Future standardisation needs in the field of documentation (

International Telecommunication Union - ITU

  • ITU Standardisation Sector (
  • ITU-T Recommendations (

European Committee for Electrotechnical Standardisation - CENELEC

European Telecommunications Standardisation Institute - ETSI

  • ETSI Sub Technical Committee HF2 Human Factors for People with Special Needs - Telecommunication Facilities for People with Special Needs (

National Information Standards Organisation - NISO

  • NISO Developing International Standards (

Internet Society

  • Internet Society Standards (
  • The Internet Engineering Task Force - IETF (


World Wide Web Consortium - W3C

  • W3C Web Accessibility Initiative (

Web Content Accessibility Guidelines


User Agent Accessibility Guidelines


Authoring Tool Accessibility Guidelines


Australian World Wide Web Accessibility Standards for People with Disabilities

U.S. General Services, Administration, Office of Government wide Policy, Washington, D.C.


Committees related to the Information Infrastructure


Global Information Infrastructure Commission


The National Information Infrastructure (NII)

  • Information Superhighway (
  • Universal Design for the Information Highway (

Information Society Project Office

  • Information Society Initiatives in Standardisation (


Web Developers and Service Providers related Organisations


The HTML Writers Guild

  • The HWG Standards List (

The Web Standards Project


Web Design Group

  • Web Design Group-Standards for HTML Authoring for the World Wide Web (

Best Viewed With Any Browser Campaign



  • Accessibility guidelines


  • Guidelines for writing accessible applications using Java

  • Guidelines for accessible notes

Starling Access Services

Universities and other Research Institutes


Trace R&D centre, University of Wisconsin


University of Washington


University of Alberta

Standards of Immediate Interest



ISO TC159 Ergonomics

Related Standard

ISO 9241 Ergonomics of Work on Visual Display Terminals



Related Standard

ISO 14915 Multimedia User Interface Design



Related Standard

ISO CD 13407 Human-centred design process for interactive systems




Contribution to, and enhancement of, the last 2 standards with accessibility related work is possible since they are not yet accepted in their final form.

Contribution could also be provided in the new work item on Accessibility that has been recently accepted by the Working Group 5, Sub-Committee 4 of the TC 159.

New work items on Web accessibility from the perspective of ergonomics, human factors and user issues, could be proposed under this technical committee.



ISO/IEC JTC 1 Information Technology / SC 7 Software Engineering

Related Standard

ISO/IEC CD 9126 Software quality characteristics and metrics



Related Standard

ISO/IEC DIS 14598 Evaluation of software products




Contribution and enhancement of both standards to include Web accessibility issues from a software engineering point of view is possible since these standards are not yet accepted in their final form.



ETSI STC HF 2 Human Factors for People with Special Needs

Related Standard





New work item on accessible telecommunication infrastructure and Web-based services could be proposed.



CEN/ISSS Information Society Standardisation System

Related Standard





New work item on accessibility requirements of Web-based services in the emerging Information Society could be proposed.


Standards of Peripheral Interest



IEEE P2001 Web Page Engineering for Intranet/Extranet Environments (Well Engineered Web Page Guidelines)

Related Standard





New work item on accessible Web-based work environments could be proposed.



Special Joint Working Group IEC/TC3-ISO/TC10 (SJWG/13) Future standardisation needs in the field of documentation

Related Standard





New work item covering accessibility of the Web as a documentation medium could be proposed.



ISO TC46 Information and Documentation

Related Standard





New work item covering accessibility of the Web as a documentation medium could be proposed.



IEEE P1063 Software User Documentation

Related Standard





New work item covering accessibility of the Web as a documentation medium could be proposed.



ISO/IEC JTC 1 Information Technology / SC 34 Document Description and Processing Languages

Related Standard





New work item covering accessibility of the Web as a documentation medium could be proposed.

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:

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.



Adopted Principles


Standardisation recommendations


Relevance to the Web Technology

Address the requirements of all potential users

Address different contexts of use

Support different interaction platforms

Design for All

Universal Accessibility

Process-oriented guidelines

Software technology requirements

Markup Languages

Presentation Languages

Modelling Languages

User Agents

Authoring Tools

Figure 1 - The methodology followed in the development of accessibility related standardisation recommendations


3.2. Definition of terms

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 Windows95TM, 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.

Figure 2: Generic model for interactive software.

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.

3.3 Principles, guidelines and recommendations

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.

Figure 3: Conceptual structure of accessibility requirements

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

"user is to carry out a text editing task. The user has mild motor impairments which delimit control to gross temporal movements, exercised through contact with the fist. Fingertips cannot be reliably employed due to tremor on key-press, while movements can be performed in timed patterns and upon demand."

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.

Figure 4: Progressively identifying, selecting and interpreting principles and guidelines into concrete recommendations.

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.

3.4 Process-oriented guidelines

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:

Figure 5: Requirements for designing for the broadest possible end user population.

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:

Guideline 1:

Designers should seek to identify and enumerate plausible design alternatives, suitable for the target user groups and contexts of use


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.

Guideline 2:

Plausible design alternatives should be encapsulated into extensible design abstractions


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.

Guideline 3:

Designers should rationalise the design space by exemplifying the logic for mapping design abstractions onto concrete user interface artefacts


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.

3.5 Software technology requirements

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.


Figure 6: Relation of the platform-level software technology requirements for accessibility, with interactive software components.

Figure 7: Relation of the tool-level software technology requirements for accessibility, with interactive software components.






















Table 1: Relation of software technology requirements for accessibility, with interactive software components

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

Requirement 1:

An interaction platform should support the abstract specification of element semantics and behaviour, de-coupled from specific input / output modalities and media.

Description and Rationale

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

Relevance to the Web

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.

Example (part 1)

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:

<MENU TITLE = "Choice" OPTIONS = {"open", "help", "exit"} WIDTH = "200" FONT = "ARIAL" >

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

<SELECTOR NAME = "Standard Options" OPTIONS="3">

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:

<2D-SELECTOR PRES="2D-MENU" TITLE="Choice" OPTIONS={"open", "help", "exit"}>


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

Requirement 2:

An interaction platform should provide facilities for augmenting the originally supported interaction techniques and presentation facilities with new ones, suitable for specific users and contexts of use.

Description and Rationale

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

Relevance to the Web

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.

Example (part 2)

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:


Requirement 3:

An interaction platform should provide facilities for expanding the originally supported set of interaction elements with new ones, necessitated by domain-specific or application-specific functionality that needs to be presented as a separated self-contained interactive entity.

Description and Rationale

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

Relevance to the Web

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.

Example (part 3)

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.

Requirement 4:

Authoring tools and user agents should provide facilities to import and integrate new semantic, presentation, and interaction resources offered by different interaction platforms.

Description and Rationale

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

Relevance to the Web

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.

Example (part 4)

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.

Figure 8: Examples of alternative SELECTOR instantiations


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.

4.1 Contribution to user-centred design standards

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.

Figure 9: Interdependence of Human Centred Design activities

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.

4.2 Contribution to standards focusing on accessible design

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.

4.3. Relevance to quality standards

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

Figure 10: Approaches to software quality.

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.

Figure 11: ISO/IEC 9126 quality model.

4.4 Action plan

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.

Figure 12: Possible types of recommendation.

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.

Figure 13: Typical life-cycle of standards.

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.

Option 1: New recommendation to existing standards

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.

Option 2 (recommended): New parts in on-going work

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.

Standardisation community

ISO TC 159 / WC 4 / WG 5

Type of contribution

New recommendations / parts


  • 7/99: Submission to European Commission
  • 8/99: Informal submission to Vice Convener of ISO TC 159/SC4/WG5
  • By end of year: Requested revisions implemented
  • 2/2000: Formal submission to TC 159/SC4/WG5




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.


Appendix E: Letters to Webmasters

Site name

Site url


Bibliothèque Nationale de France

No answer but the site has become more accessible

Les trois Suisses

No answer, no improvement

Reporters sans frontières

No answer


We are aware of the problem but it is difficult to solve. Moreover those users belong to a small category of users and we cannot take everyone into account.

Le livre de jeunesse

They wanted to do their best to make the site accessible, and the site has become more accessible.

5th French Television Channel

Positive answer, but no results yet.

French Parliament

Positive answer. The site will be more accessible.

Mairie of Villeurbanne

No answer

The Newspaper Libération

They are aware of the problem but...

Autonomic exhibition

An answer but no changes

News agency AFP

The answer was not clear, no changes.

Poste office

No answer

Site of the Prime Minister

Positive answer, meeting with the person in charge of the site.

Chilian Newspaper

Positive answer. An evaluation of the accessibility of the site has been sent, waiting for results.

Newspaper Le Monde

Positive answer. Improvements on the site

Webcity, leisure newspaper for Paris

No positive answer, no interest

The Quid, encyclopedia

no answer

Railway company

no answer

Television Newspaper

No answer

Literary magazine

no answer

Newspaper l'est républicain

no answer

French German Office for the Youth

no answer


Appendix F: Alternative browsers listing


This is a collection of pointers to information, and where possible, to demonstration versions of alternative browsing methods. People with disabilities, whether temporary -- such as a slow connection, or eyes "disabled" by having to watch traffic -- or permanent -- such as hearing, visual, physical or cognitive impairment -- use a wide range of alternative approaches, different from traditional mouse-and-screen-based browsers.

People with visual impairment or reading difficulties rely on speech output, braille displays or screen magnification; and in many cases use the keyboard instead of the mouse. People who can't use a keyboard rely either on voice recognition for spoken commands, or on switch devices which can be controlled by head, mouth or eye movements. People whose eyes are busy with another task may need Web access using voice-driven systems. This page is intended to give you background and pointers to solutions for these scenarios.

The purpose of this collection is to reflect the whole range of approaches used for browsing. If you design Web pages, then this will allow you to try out a particular browsing method with specific sites as a way of checking how usable they are for a given browser, or combination of browser and screen-reader, voice-recognition, or other adaptive systems. If you are a user who may be interested in finding the most effective method for you, then you should also find useful information here.

The page is divided into five sections:

Section 1: Browsers specifically designed for people with disabilities

For each of the following browsers, a brief description is given indicating which of the above adaptive features is supported.

Section 2: Screen-readers

A screen-reader is used to allow navigation of the screen presented by the operating system, using speech or braille output, and should therefore enable use of any mainstream application. In the context of browsing this usually means that they are used in conjunction with Netscape, Microsoft Internet Explorer, or, less often, with one of the other non-disability-specific browsers such as LYNX and Opera, detailed in section 3. Listed below are the home pages of all the major developers of screen-readers for different versions of Windows, and including one for Macintosh. Many of these include support for MS-DOS, either as an integral part of the Windows version, or in conjunction with a stand-alone DOS screen-reader. They all provide demonstration versions.

Section 3: Browsers with adaptive technology

These browsers are all designed for general use, but are of interest because they may give enhanced accessibility in combination with particular adaptive systems, and some have enhanced screen magnification or navigation options.

Screen magnification is also used in conjunction with standard software, and for more background and links on this topic, please see:
The Screen Magnification Home Page

Section 4: Voice-browsers

These are systems which allow voice-driven navigation, some with both voice-in and voice-out, and some allowing telephone-based web access.

Section 5: Other access methods

We will be expanding this section to include links to reference lists of other access technologies such as screen magnifiers and voice recognition programs which can be used in conjunction with Web browsers.


Appendix G: WCAG 1.0 Checklist

List of Checkpoints for Web Content Accessibility Guidelines 1.0

This document is an appendix to the W3C "Web Content Accessibility Guidelines 1.0". It provides a list of all checkpoints from the Web Content Accessibility Guidelines 1.0, organized by concept, as a checklist for Web content developers. Please refer to the Guidelines document for introductory information, information about related documents, a glossary of terms, and more.

This list may be used to review a page or site for accessibility. For each checkpoint, indicate whether the checkpoint has been satisfied, has not been satisfied, or is not applicable.

This document has been produced as part of the Web Accessibility Initiative. The goal of the WAI Web Content Guidelines Working Group is discussed in the Working Group charter.

Status of this document

This document is an appendix to a document that has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. This is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and universality of the Web.

A list of current W3C Recommendations and other technical documents can be found at

This document has been produced as part of the Web Accessibility Initiative. The goal of the Web Content Guidelines Working Group is discussed in the Working Group charter.

Please send comments about this document to


Each checkpoint has a priority level assigned by the Working Group based on the checkpoint's impact on accessibility.

[Priority 1]
A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.
[Priority 2]
A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
[Priority 3]
A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.

Some checkpoints specify a priority level that may change under certain (indicated) conditions.

Priority 1 checkpoints

In General (Priority 1) YesNoN/A
1.1 Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.      
2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup.      
4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).      
6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.      
6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes.      
7.1 Until user agents allow users to control flickering, avoid causing the screen to flicker.      
14.1 Use the clearest and simplest language appropriate for a site's content.      
And if you use images and image maps (Priority 1) YesNoN/A
1.2 Provide redundant text links for each active region of a server-side image map.      
9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.      
And if you use tables (Priority 1) YesNoN/A
5.1 For data tables, identify row and column headers.      
5.2 For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.      
And if you use frames (Priority 1) YesNoN/A
12.1 Title each frame to facilitate frame identification and navigation.      
And if you use applets and scripts (Priority 1) YesNoN/A
6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.      
And if you use multimedia (Priority 1) YesNoN/A
1.3 Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation.      
1.4 For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.      
And if all else fails (Priority 1) YesNoN/A
11.4 If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.      

Priority 2 checkpoints

In General (Priority 2) YesNoN/A
2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text].      
3.1 When an appropriate markup language exists, use markup rather than images to convey information.      
3.2 Create documents that validate to published formal grammars.      
3.3 Use style sheets to control layout and presentation.      
3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values.      
3.5 Use header elements to convey document structure and use them according to specification.      
3.6 Mark up lists and list items properly.      
3.7 Mark up quotations. Do not use quotation markup for formatting effects such as indentation.      
6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page.      
7.2 Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off).      
7.4 Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.      
7.5 Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.      
10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.      
11.1 Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.      
11.2 Avoid deprecated features of W3C technologies.      
12.3 Divide large blocks of information into more manageable groups where natural and appropriate.      
13.1 Clearly identify the target of each link.      
13.2 Provide metadata to add semantic information to pages and sites.      
13.3 Provide information about the general layout of a site (e.g., a site map or table of contents).      
13.4 Use navigation mechanisms in a consistent manner.      
And if you use tables (Priority 2) YesNoN/A
5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).      
5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting.      
And if you use frames (Priority 2) YesNoN/A
12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.      
And if you use forms (Priority 2) YesNoN/A
10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned.      
12.4 Associate labels explicitly with their controls.      
And if you use applets and scripts (Priority 2) YesNoN/A
6.4 For scripts and applets, ensure that event handlers are input device-independent.      
7.3 Until user agents allow users to freeze moving content, avoid movement in pages.      
8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]      
9.2 Ensure that any element that has its own interface can be operated in a device-independent manner.      
9.3 For scripts, specify logical event handlers rather than device-dependent event handlers.      

Priority 3 checkpoints

In General (Priority 3) YesNoN/A
4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs.      
4.3 Identify the primary natural language of a document.      
9.4 Create a logical tab order through links, form controls, and objects.      
9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls.      
10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.      
11.3 Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)      
13.5 Provide navigation bars to highlight and give access to the navigation mechanism.      
13.6 Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.      
13.7 If search functions are provided, enable different types of searches for different skill levels and preferences.      
13.8 Place distinguishing information at the beginning of headings, paragraphs, lists, etc.      
13.9 Provide information about document collections (i.e., documents comprising multiple pages.).      
13.10 Provide a means to skip over multi-line ASCII art.      
14.2 Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.      
14.3 Create a style of presentation that is consistent across pages.      
And if you use images and image maps (Priority 3) YesNoN/A
1.5 Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map.      
And if you use tables (Priority 3) YesNoN/A
5.5 Provide summaries for tables.      
5.6 Provide abbreviations for header labels.      
10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns.      
And if you use forms (Priority 3) YesNoN/A
10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.      



The Project WAI-DE (Web Accessibility Initiative - Disabled and Elderly sector) has been supported by the European Commission under the auspices of the TELEMATICS APPLICATIONS Programme.

Telematics Applications Programme


Further information on the TELEMATICS APPLICATIONS Programme:

You can obtain more information on the projects of the TELEMATICS APPLICATIONS Programme from:

European Commission, DG XIII, C/1
TELEMATIC APPLICATIONS Programme Information desk
Rue de la Loi 200 - BU 29 - 04/05
B - 1049 Brussels
Fax: +32 2 295 23 54

Or on the TELEMATICS APPLICATIONS Programmes homepage: