DIFFUSE: Dissemination of InFormal and Formal Useful Specifications and Experiences to research, technology development & demonstration communities

What's New

Reference
Business Guides
Standards List
Standards Fora List
RTD Project List

News
Electronic Commerce
Information Management
Information Society RTD
Standards Conferences
Diffuse Conferences

User Support
Index
Search
Help Desk

Background
About IST

About Diffuse
Diffuse FAQ
RTD Initiatives
IPR Statement
Disclaimer

Guide to Web Accessibility and Design for All

Project funded under the European Commission's 5th Framework IST Programme

This guide explains the background and principles of accessibility and Design for All (DfA) activities related to the World Wide Web. There is special emphasis on current trends and on the problems of putting principles into action. The guide also compares European and other approaches.

The guide explores the following subjects:

From accessible buildings to accessible Web sites

Accessibility has long been an important goal in the design of the built environment. For example, it should be possible to enter a building and move inside it with a wheelchair, or without eyesight, or with limited cognitive abilities. The trend is to emphasize the need to design buildings so that they are suitable to all, instead of separate arrangements, as the following quotation explains:

In the past, the problem of accessibility was considered a direct result of the individual's deviation from "the norm". The person was the "exception", hence the "problem". Following an itemized approach, the most common response to accessibility problems has been to add special facilities to a building, such as ramps or wider doors. This response, however, reinforces the idea that certain individuals are "exceptions to the rule" and stigmatizes them by obliging them to use, for example, separate entrances, often at the rear of the building.

Source: New Resolution on Universal Design Education (press release, announcing Resolution ResAP(2001)1 by the Committee of Ministers of the Council of Europe).

Web pages often have problems comparable to staircases and narrow doors. For example, if some essential interaction on a Web page absolutely requires a pointing device like a mouse, this is a severe obstacle to people who cannot use such a device, or cannot use it with sufficient accuracy. Different software and site design arrangements can be used to solve the problem so that alternative methods, such as keyboard-only access, are possible.

Web accessibility can be seen as part of e-accessibility, i.e. accessibility of information and services in electronic form. For example, E-mail messages have accessibility issues too, especially when they are long or contain attachments. A particular reason to promote Web accessibility is that people with disabilities especially benefit from the use of the Web, which helps them to overcome physical limitations. The Web also provides for natural solutions: simple Web design tends to produce accessible pages, since the selection of presentation is left to the Web client (browser) and the user. Similar techniques could be used e.g. in CD-rom publishing, too, but this is still rare.

Common problems in Web accessibility

Web accessibility can be illustrated by some simple examples: Consider a Web site where the main page contains essentially just images that are links to sub-pages. This is a fairly common arrangement. Quite often the images contain just text in image format, to achieve a particular font and colour combination. But then the site is inaccessible to the blind, unless there are textual alternatives to the images specified on the page. Special software, such as a "screen reader", can present the page content to the user via speech synthesis, using the textual alternatives. It is often trivial to add the alternatives, but the need for that must be understood by the page maintainer.

As another example, the textual content of a Web page might be written in unnecessary complicated language, often using technical terms, special phrases and rare words, thereby creating obstacles to all, and very serious obstacles to people with cognitive disability or limited language skills. This is very often the case in public administration pages. Similarly, the organization of the site content can be so confusing that it creates an obstacle to utilizing the content. A common problem is an "overfull" Web page, which has far too many different ingredients. This problem is often combined with the use of very small font, which is a serious obstacle to many elderly people.

Common accessibility problems include rigid layout that forces, or tries to force, the visual appearance of a page to a specific width, perhaps in exact columns, with specific margins, often requiring specific font size. Such pages cannot work well on small-size monitors, or for people with certain types of eyesight problems, and they often do not get printed well. The possibility of printing a page is important, because many people have severe problems in reading on screen but can use printed copies.

Accessibility relates to usability so that, basically, usability aims at making Web pages easy to use emphasizing normal, typical use, whereas accessibility considers different uses, which might even be characterized as atypical or abnormal. This means that there are potential conflicts, but in practice, usability and accessibility considerations largely lead to similar guidelines and solutions. However, for accessibility we often need to concentrate first on making pages accessible at all to people with disabilities. This involves the risk of being satisfied with any solution, even if it introduces inconvenient and troublesome use. These issues are discussed in  Beyond Accessibility: Treating Users with Disabilities as People by Jakob Nielsen, the usability expert.

Accessibility in the original idea of the Web

The early documents about the Web describe the idea of material that can be presented in a wide range of presentation mechanisms, including text-only terminals, PDAs, and Braille displays. Thus, accessibility was part of the very idea, rather than something to be superimposed as an extra requirement.

In practice, text-only browsers were common, and pages were created with this in mind, largely by experienced people. But the fundamental idea, at least as understood by experts, was to use markup and methods that specify the logical structures, so that different techniques can be used in various situations. For example, a logical heading could be underlined on a simple terminal; coloured on a text terminal with colours; spoken slowly and emphatically in speech generation; and formatted in a traditional way, using large font, on a graphic browser.

The common use of graphic browsers, effectively starting with the NCSA Mosaic browser in 1993, changed the picture and resulted in pages written for particular browsers, utilizing methods for visual layout. The original idea had been to keep the content and structure of a document as separate from its visual or other presentation. Technically, HTML markup was to be used for the structure and style sheets for presentation suggestions. This largely failed, partly because the use of style sheets was not possible in practice for many years, while presentation-based HTML was immediately available. Another reason was that it became everyone's and his grandma's hobby to create Web pages, often using tools and approaches based on desktop publishing paradigms.

Part of the challenge of making the Web accessible is to implement the original goal of separating structure from presentation, thereby making it possible to take the structure and content as input to any process of rendering, for different devices and situations. Progress in the implementation of cascading style sheets (CSS) has been rapid in the last few years, but there are still serious problems in this area, including CSS implementation bugs that make many authors hesitate.

The multitude of terms

"Accessibility", "universal access", "Design for All", "inclusive design", "barrier free design" and many other names are used for more or less the same approach and goal. In part, the multitude of terms reflects the fact that we deal with a multitude of problems, many of which have not been analyzed yet, and some problems that aren't even known yet. We could define accessibility as being accessible to people with different needs, including people with different types of disabilities. And different needs and disabilities greatly differ from each other and impose different requirements.

But the variation in terms partly reflects different emphasis and views. The variation of words used is itself an accessibility problem, as regards to information about accessibility. Moreover, the English expressions are translated into other languages in different ways. In Europe, the expression "Design for All" is becoming more and more common; it emphasizes the goal of making "mainstream" products suitable to all people, instead of separate versions for people with disabilities.

In particular, some terms refer to solutions where, in the Web context, the same content is sent to browsers that are expected to present it in different ways. This means producing adjustable (or "fluid") content, such as pages that can be displayed in different font size or presented via speech synthesis without difficulties. Other approaches emphasize the need of creating multiple presentations at the author and server side, e.g. producing alternative content in sign language, or enhancing textual content with images that support it, or writing alternative texts in simplified language. For example, the need for simplest possible language requires different approaches in different situations. It can partly be fulfilled by just writing a single version, but in some cases, especially for material that is of great impact to all citizens, it can be necessary to produce a separate "easy" version. The Easy-to-Read Guide explains things to be considered.

The difference between "adjustable content" and "alternative content production" partly depends on the state-of-the-art. For example, automatic translation from one language to another is currently possible mostly between major world languages in special cases, e.g. for restricted grammar and vocabulary. But in the future, it might become usable more widely and also for generating e.g. simplified language versions.

Another difference in views is that accessibility is often defined as being accessible without special arrangements, whereas another view emphasizes the need to pay special attention to various special tools in order to overcome limitations imposed by disabilities. Such tools, called assistive technologies, include speech synthesizers, magnifiers and special pointing tools different from a common mouse. This difference is partly verbal and caused by the lack of good analysis of the problem areas. The opinion against special arrangements is probably mainly aimed against arrangements that create "second-class" access, comparable to backdoor entrances for wheelchairs. In the Web realm, "text-only versions" of pages are very often, though not necessarily, "second-class access"; they might have less information than normal pages, and they might get updated less often. Consequently the user has difficulties in knowing whether he gets full access to all information via the text-only version.

The multitude of problems

A large part of the work with accessibility has concentrated on the problems of the blind. In this important area, principles and techniques have been developed, and also deployed to some extent. Moreover, many of the methods used to alleviate those problems improve accessibility in other ways too. Similar notes can be made about other vision impairments, which form a wide range of problems and become more and more important, as the age profile of the population changes.

But there is a large set of other issues as well. It could even be said that since it is relatively easy to understand some of the problems of the blind and to find solutions to them, in principle at least, work on accessibility has focused on them, while a large number of other problems have gained little or no attention.

A very common problem is a cognitive disability of some kind, often causing difficulties of understanding complex texts and complex structures. The severity of such problems varies greatly, from very serious cognitive disabilities to mildly sub-normal comprehension. In fact, a great many pages are hard to understand even to people with fairly normal cognitive and linguistic capability.

Other problems include difficulties in concentrating one's mind on a topic at hand, implying the need for information available in small portions with well-defined connections. This, as many other problems, may appear as permanent or as temporary e.g. due to stress. Various distractions on Web pages, such as decorative animations, are regarded as annoying by many people; to some people, they can be serious obstacles to concentrating on the content proper. Moreover, flickering effects may even trigger epileptic seizures.

Language problems are gaining importance partly due to immigration, partly due to wider Internet user community, which includes more and more children and people with limited education. People with hearing problems cannot make full use of auditory content, which is getting more common, and people born deaf have the additional problem that usually no written language is their native language. To mention yet another group of problems, in this far from complete list, people with mental disorders presumably have difficulties in using the Web, but we don't yet even know much about the problems, still less the possible solutions.

There is great variation in the severity of the problems. For example, there is a continuous spectrum from complete lack of eyesight to just a little less than perfect eyesight. In fact, perfection is often quite rare. Accessibility improvements are crucial to people with a severe form of a disability such as dyslexia, but typically they also help a much larger population with milder forms of the problem.

Accessibility is often described as relating to people with disabilities, perhaps mentioning elderly people as well. For some reason, the problems of young people are rarely discussed in this context, despite the fact that even very young people use the Web.

But in addition to issues relating to the different properties of people, there are issues of different situations in which people find themselves, either permanently or temporarily. For example, using a computer in a vehicle shares many of the problems that some people have permanently due to a disability in hand motorics. There is an illustrative presentation of such parallels in the document Universal Design and the Grid.

One of the strategies applied in accessibility advocacy is to present accessibility as a way of helping both the disabled in using the Web and "normal" people (whatever that means) in using the Web in ways that differ from the simple, typical use of a PC. Using handheld or other devices with small displays imposes requirements on the adaptability of Web pages to different presentations. Within the W3C, the Device Independence Activity has produced drafts that discuss the principles and challenges of dealing with device variation, including different workstations, personal digital assistants (PDAs), mobile phones, voice systems, printers, interactive television systems, and screen readers.

However, there are situations where different problems may impose conflicting requirements on accessibility. Up to now, there has been little open discussions about this. To take a simple example, people with comprehension problems may need simplified text, even at the cost of reducing information content, whereas "normal" people, not to mention people with fast comprehension, would find too simplified text rather inconvenient. Such problems could be addressed by creating alternative versions, but this tends to have great impact on the costs of content production and maintenance. Other conflicts arise from the fact that some techniques are related to specific properties in browsers and tools; a technique that avoids a problem in one browser may cause other, perhaps more serious problems on other browsers. For example, some recommendations tell authors to use "placeholding" ("dummy") characters in input boxes in forms, since some programs used by the blind have problems with empty input boxes. But such "placeholders" may confuse people and make it more difficult to enter user input.

WAI recommendations and EU and US policies

The World Wide Web Consortium (W3C) has widely been recognized as the forum for promoting the progress of Web technologies and producing recommendations. Within it, there is a range of accessibility related activities, jointly known as Web Accessibility Initiative (WAI), which have resulted in recommendations for Web authors, browser vendors, and other stakeholders. Usually the expression "WAI recommendations" refers to authoring guidelines, which are the recommendations with the largest potential audience; at present this means Web Content Accessibility Guidelines (WCAG) 1.0. But recommendations on authoring tools, such as the User Agent Accessibility Guidelines 1.0, can also have a great impact if taken seriously and implemented well by tool vendors.

WCAG 1.0 was approved in May 1999, and there are several translations into languages other than English. The document makes a large number of detailed recommendations, in addition to general principles. This has often been regarded as a drawback, too, because it partly couples the document with particular techniques currently used.

Within the European Union, the WAI recommendations are regarded as the common ground for promoting accessibility, as a de facto standard. The EU documents, such as those produced in the area eAccessibility activities of the eEurope programme and the resolution of the European Parliament on the accessibility of public web-sites build upon the WAI recommendations. In fact, the Parliament resolution describes WCAG 1.0 as "nowadays considered to be the global standard for the designing of accessible Web sites".

The WCAG 1.0 recommendation divides its rules into three "priority levels" and defines corresponding "conformance levels" (A, AA, AAA). There are varying opinions on whether this makes things more manageable or more complicated. In any case, it makes it possible to impose different requirements on Web site design using compact expressions in contracts, for example. In the previously mentioned resolution, the European Parliament "stresses the fact that for websites to be accessible it is essential that they are double-A compliant, that priority 2 of the WAI guidelines must be fully implemented".

As of late 2002, there is work in progress towards a resolution of the Council of the European Union, with the draft title "eAccessibility" - improving the access of people with disabilities to the Knowledge Based Society. It is intended to address issues such as common methodologies and and comparable data in evaluating accessibility, to suggest considering the provision of an "eAccessibility mark" for goods and services, to outline the principle of promoting accessibibility in the private sector via public procurement legislation, and to recommend that e-accessibility become a regular part of all education programmes of vocational schools.

In the United States, the situation is somewhat different. Much weight is given to "Section 508" rules. This refers to section 508 of the Rehabilitation Act as amended by the Congress in 1998 to require Federal agencies to make their electronic and information technology accessible to people with disabilities and as defined operationally by "Section 508 standards" by federal administrations. Basically "Section 508" rules are very similar to WAI recommendations and based on them. They mostly correspond to WCAG 1.0 priority 1 checkpoints. There is a detailed side-by-side comparison, which also explains some of the reasons for the differences, and a compact Section 508 and WCAG Sidebar.

On the W3C Web site, there is a document about policies relating to Web accessibility, including legal requirements, in different countries. Unavoidably, systematic comparisons are difficult due to the different approaches, but in general European countries have issued recommendations instead of requirements or laws. The US approach uses legislation and sanctions rather than guidelines and recommendations only. This raises two essential questions. There is pressure towards legislative or administrative measures for forcing accessibility upon public Web sites; how strong will it be? And will the WAI recommendations and the US regulations diverge so seriously, even though perhaps in formulations and minor issues only, so that there will be no international consensus?

Accessibility and standards

As described above, WAI recommendations are widely recognized as "de facto standards", and work on accessibility guidelines takes place mostly in the framework of the W3C. Accessibility requirements are presented as consortium recommendations and other policy documents, and partly in legislation too, rather than by standardization organizations such as ISO, CEN and their national members.

However, there is an important connection between accessibility and official standardization. Within CEN/ISSS, there is a workshop on Design-for-All technologies and Assistive Technologies in ITC. Its key activities include the preparation of guidelines for taking into account accessibility matters in the drafting of standards. Thus, it aims at making accessibility considerations an integral part of all standardization efforts. There are expectations that the workshop might also produce more specific guidelines on making user interfaces more accessible. The workshop has produced draft Guidelines to Standardisers of ICT products and services in the CEN ICT domain.

In September 2002, the conference Design for All in Standardisation discussed especially the implementation of the recommendations in the CEN/CENELEC Guide 6 regarding how to consider DfA requirements in standards development processes. It was widely acknowledged that the Guide is rather general in nature and needs to be accompanied with sector guides that can be more directly applied. This is necessarily a slow process and will mostly affect new technologies only.

Issues in implementing WAI guidelines

Although the accessibility policies are widely accepted by different authorities, the progress in actual accessibility is slow. Web page authors and their employers often lack the basic understanding of the importance of accessibility, despite various awareness raising campaigns. Moreover, many of the problems and possible solutions are technically difficult.

The WAI recommendations are often regarded as difficult to understand and fulfill. Although they are relatively brief, they impose a large number of requirements, and an average author probably has great difficulties in understanding both the "why" and the "how" of the principles. The guidelines are relatively abstract, and they refer to three WCAG techniques documents. There is also a checklist. The organization of the documentation uses hypertext (links between different parts) quite a lot, which is often convenient in reference use but confusing to the uninitiated.

For illustration, consider the Quick Tips document, which summarizes some key principles in ten rules (not to be confused with the fourteen guidelines, which form the "body" of WCAG 1.0):

  • Images & animations. Use the alt attribute to describe the function of each visual.
  • Image maps. Use the client-side map and text for hotspots.
  • Multimedia. Provide captioning and transcripts of audio clips, and text descriptions of video clips.
  • Hypertext links. Use text that makes sense when read out of context. For example, avoid "click here."
  • Page organization. Use headings, lists and consistent structure. Use CSS for layout and style where possible.
  • Graphs & charts. Summarize or use the longdesc attribute.
  • Scripts, applets, & plug-ins. Provide alternative content in case active features are inaccessible or unsupported.
  • Frames. Use the noframes element and meaningful titles.
  • Tables. Make line-by-line reading sensible. Summarize.
  • Check your work. Validate. Use tools, checklist, and guidelines at http://www.w3.org/TR/WCAG.

This gives Web authors an idea of what kinds of things they are expected to work with to improve accessibility. Naturally, it reflects those rules that are eligible for compact presentation. But even people with fairly long authoring career have difficulties in understanding some of the key concepts used in the summary, not to mention the principles themselves. In such situations people tend to concentrate on those technical aspects that they can handle, such as fulfilling some requirements without really understanding their purpose and content. For example, the first requirement in the quick tips can be fulfilled, as far as automatic checkers are considered, by writing any alt attribute for every image. This has even led to the use of completely useless, or worse than useless, alt texts.

Moreover, the rather technical nature of the quick tips, guidelines and other material tends to make authors focus on technicalities. Authors who care about accessibility spend probably much more time in implementing the principles summarized in the Quick Tips than in evaluating and improving the understandability of the texts on their Web pages. Yet, unnecessarily complicated language makes the content inaccessible to a very large number of people. There are some methods for evaluating the readability of texts on an automated basis, though mostly for the English language only. But they are not widely used by Web authors, and they can just give rough estimates that say how unreadable the text probably is. And there are many more aspects in accessibility that are difficult to specify and evaluate, yet much more important in practice than many of the technical nuances.

Authoring tools, i.e. Web page creation software, often produce pages that have accessibility problems, especially if they are based on "WYSIWYG" ("What You See Is What You Get") techniques, since such an approach makes it much more difficult to separate content and structure from presentation. But, largely due to the accessibility-related legislation in the US, authoring tools such as Frontpage, Dreamweaver, and Adobe Acrobat have been enhanced with accessibility features. As regards to Adobe Acrobat, which is a software product for creating documents in PDF format, views differ on the level of accessibility achieved. There is a large Web site describing Adobe accessibility features, but it has been noted that there are still different problems with PDF files even when available PDF accessibility enhancement techniques are applied. Several policy documents regard it as inappropriate to use PDF as the only format in which some content is available on the Web; yet this rule is violated increasingly often, even when publishing recommendations that endorse the rule! 

Evaluating accessibility

If managers who supervise Web authors are aware of accessibility issues, they would like to give instructions about the required level of compliance with guidelines and expect it to be possible to evaluate objectively and easily whether this has been achieved. But although there is a large number of software tools for analyzing and fixing accessibility problems, the tools are mostly of rather limited usefulness, and they are often experimental or otherwise unsupported.

For some of the WAI guidelines, automatic checking is possible, but usually in part only. Even if additional checking is made by people, the results are not completely objective. How could we decide objectively whether e.g. the guideline of using simplest possible language has been obeyed? In fact, it was omitted from Section 508 rules, because it was deemed too difficult to enforce. There are computational methods for estimating readability, though mostly for the English language only. Accessibility checking tools don't usually calculate readability indexes, and even if they did, that would not tell us whether simplest possible language has been used.

Thus, programs that evaluate accessibility, such as Bobby and A-Prompt, cover just some aspects. Although they may expressly point this out, the situation is confusing, and it happens that people take the reports as much more decisive than they can possibly be. A checker might even impose its own additional rules, which are not derivable from WAI guidelines. Expert opinions differ on the overall usefulness of evaluation tools, but in any case judgment is needed when reading reports from accessibility evaluation tools.

Towards a new generation of guidelines

The next version of the WAI guidelines for authors, WCAG 2.0, is intended to be oriented towards more general, technology-independent principles. For example, a working draft for WCAG 2.0 by the WCAG Working Group in August 2002 outlines five major guidelines (in contrast to fourteen in WCAG 1.0), namely:

  1. Perceivable. Ensure that all intended function and information can be presented in form(s) that can be perceived by any user -- except those aspects that cannot be expressed in words.
  2. Operable. Ensure that the interface elements in the content are operable by any user.
  3. Navigable. Facilitate content orientation and navigation.
  4. Understandable. Make it as easy as possible to understand the content and controls.
  5. Robust. Use Web technologies that maximize the ability of the content to work with current and future accessibility technologies and user agents.

This raises the question how the principles will be mapped to more operational rules for the specific technologies that are used. Despite being much more specific, the current WCAG 1.0 recommendations are often subject to various interpretations in discussion fora and in actual practice, and there is a risk of increasing divergence.

The credibility problems

In awareness raising and general promotion of accessibility, there are good reasons to emphasize its importance to people with disabilities and to elderly people, and good reasons not to do that. Without any references to user groups that would particularly benefit from accessibility, the message about accessibility becomes rather abstract and not very motivating. On the other hand, associating accessibility with disabilities creates the risk of ignoring it as a "minority issue". Especially in the commercial world, the answer could even be that the minorities do not belong to the market segment that the company is interested in.

Another credibility problem stems from the fact that in Europe, the approach is generally to give recommendations rather than laws or commands to promote accessibility. Although this approach may be in many ways preferable, it inevitably creates the possibility of ignoring the guidelines as "recommendations only". This is particularly relevant if there are other principles and restrictions in Web design that must be obeyed. Thus, for example, organizations that internally give binding instructions on Web design should review them so that accessibility guidelines have adequate status.

There is also resistance caused by the opinion that making pages accessible makes them dull, boring, and unimaginative visually, up (or down) to thinking that they'll be "black text on grey background" (in all presentations). In addition to resistance based on misunderstanding, there are still serious problems in combining accessibility and good visual design. In theory, authors are supposed to make pages accessible and use style sheets to suggest visual appearance. In practice, there are hard problems, largely due to a huge number of errors (bugs) in browsers' support to style sheets. Moreover, there are relatively few examples of sites that combine accessibility and visually attractive design.

Web sites that are intended to promote accessibility seldom manage to illustrate, in their own visual appearance, how accessibility and good visual design can be combined. To make things worse, such sites themselves rather often suffer from serious accessibility problems! It is not very impressive to publish a recommendation that seriously violates its own principles. (Actually, according to Bobby, even the W3C WAI page is not AAA compliant.)

The phenomenon that many accessibility-promoting pages aren't themselves accessible is often caused by the site design of the organization that hosts the accessibility activity. If the site is large, the site design cannot be changed easily, especially since the site design is often connected with page creation tools, management and other factors. For example, the document Web Content Accessibility Guidelines for EU Public Sites says: "Note, however, that currently this page is not compliant -- like many pages on EUROPA, its navigation system features a number of accessibility problems. EUROPA is a massive site, featuring well over a million pages, so the adoption of the guidelines marks the beginning of a long compliance process, not the end."

This reflects the general problem that essential improvements to accessibility often require well-designed long-term site redesign projects that can deal with the inevitable problems in the transition. This implies a great need for preventing problems that so often result from site redesign. In addition to confusion among users, site redesign often breaks old links and other references to the site. This problem is addressed in the W3C's classical document Cool URIs don't change.

Current activities

In the eAccessibility area of the eEurope program, the targets for years 2001 and 2002 included the creation of a network of centres of excellence. The network was named the European Design for All eAccessibility Network, EDeAN, and it is expected to have an important role in promoting and supporting accessibility work in Europe, bringing together the numerous and often small organizations and groups that have excellent expertise in accessibility.

In the eEurope 2005 action plan, accessibility remains one of the basic goals. There is special emphasis on interactive public services, and this creates new challenges. In particular, the communication on eEurope 2005 says: "By end 2004, Member States should have ensured that basic public services are interactive, where relevant, accessible for all, and exploit both the potential of broadband networks and of multi-platform access."

At the worldwide level, there are several academic, governmental, commercial and volunteer organizations that work for accessibility. In addition to the W3C WAI activities, there is e.g. the WebAIM forum, which has produced a large data base of Web accessibility resources.

File last updated:
December 2002
The Diffuse Project is funded under the European Commission's Information Society Technologies programme. Diffuse publications are maintained by TIEKE (the Finnish Information Society Development Centre), IC Focus and The SGML Centre.