WWW8: Accessibility of web pages

Abstract: Tim Berners Lee - often referred to as the "father of the Web" - once said: "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect".
To underline this, the W3C has started the "Web Accessibility Initiative" (WAI) in 1997. But regardless of these activities, it seems to me, many designers of web pages do not care too much about accessibility. This work tries to find out what influences accessibility of web pages. Research was performed on how the code generated by an authoring tool and the HTML -tags and attributes present in a document influence accessibility. In addition, the impact of the capabilities of the hardware and software deployed on the client side as well as potential disabilities of the person who actually tries to use the information was analyzed. This was done in our accessibility lab, where web pages were looked at with many different browsers on various hardware platforms.
Based on the findings, a method was developed to measure accessibility of web pages and a list of recommendations to create documents that are accessible by virtually everyone was compiled.

At least many of the web sites that I use to visit, heavily depend on visual elements. And when we discuss what is a "good design of a web page", most people argue that today, everyone has a browser that supports graphics, scripting and all the features of the current HTML specifications. An author of a web site at our university once said: "I can live with the fact that 5% of the clients cannot access my web pages". I strongly disagree with that point of view, at least for governmental and educational web sites.
In addition, not all of the recent clients do actually support every feature. There will be an increasing number of "light clients", such as Windows CE based systems, watches, phones and pagers with built-in browsers, which may not be able to support client based scripting or large images. Not to forget that there are a lot of countries which do not have a high speed network and that access to the Web over a cellular phone still supports only 9600 baud, at least in our country.
Authors should not treat a web page just as a piece of paper. They should not only think in pixels and RGB-values, but they should try to create documents that are useful for everyone, regardless of the hardware and software of the client and the physical capabilities of the person visiting the web site.

Table of contents:

  1. A definition of the term "accessibility"
  2. What web sites should care about accessibility ?
  3. Why may accessibility be important to your web site ?
  4. Impact of authoring tools on accessibility
  5. What difference makes the hardware of the client ?
  6. How do different browsers handle HTML ?
  7. Measuring accessibility
  8. Analysis
  9. Conclusion and Recommendations

1. A definition of the term "accessibility":

Here, accessibility is defined as how easy a document on the web can be "used" by a client. The higher the requirements are, the less accessible a document is. Requirements include capabilities of the hardware and the software deployed as well as the physical capabilities of the person trying to use the information provided in a document. A document may include text, sound, graphics etc in any combination. This paper will concentrate on technical issues, non-technical issues such as language, intellectual capabilities of the person required to actually understand the contents etc are important as well, but beyond the scope of this work.

To the table of contents

2. What web sites should care about accessibility ?

At the first glance, the obvious answer might be "any web site". But at a second thought, some classification should be possible which allows to assign some level of desirable accessibility to groups of web sites. In my opinion, people can basically do what they want on their personal web pages. If they are difficult to access, they get less hits and the pages may become popular only within a small group of visitors or even not at all. Also people with a particular interest may accept a lower degree of accessibility. For example, people accessing a web site dedicated to music may accept that a sound card is required to fully enjoy the information provided.
On the other hand, we have web sites operated by governments or general public organizations, which I believe must be accessible by everyone. The same should be true for educational web sites, such as web sites of universities etc. Commercial web sites should be easy to access simply because they usually want to sell products or services to as many people as possible. The more difficult it is to access a web page, the smaller the chances are to actually do business.

So we may come up with a classification of desirable accessibility for web pages like this:

Type of web site Desirable accessibility
Governmental Highest possible
General public organizations Highest possible
Universities and other educational organizations Highest possible
Commercial High
Interest groups Good, may depend on the type of interest
Personal Up to the author

To the table of contents

3. Why may accessibility be important to your web site  ?

The key factors for a successful web site are:


In order to run a successful web site, people must be able to find it. It is beyond the scope of this presentation to discuss the steps required to achieve this, but important factors include a good, easy to remember address, intensive use of META-tags, search engine registration, link exchange etc.

Valuable information

This is my most favorite quote: "it's the content that counts, not the appearance !". Many people may not agree with that (especially graphic artists), but a pretty presentation without valuable content is useless. Of course, a nice presentation, a good structure and easy navigation are important as well.


Accessibility is important in two respects:
  1. If you wish to do business successfully, it must be easy to access the information. If plug-ins or special hardware or software are required to use the information, most people will leave the web site immediately.

  2. In order to show that you care about people who have slow access to the Internet, not the latest and greatest version of the popular browsers or may even dare not to use your favorite browser at all and that you also care about people with disabilities, authors should provide various means to present the same information.
    As an example: if you use an image map for navigation purposes, also provide text based navigation means.

To the table of contents

4. Impact of authoring tools on accessibility:

Authoring tools have a great impact on the accessibility of web pages. Unfortunately, most authors are not aware of the quality of the HTML code generated by their tool. Most companies only tell you in their advertisements how easy it is to create your first web page with their WYSIWYG authoring tool, but they do not tell you how less they care about standards such as the specifications of HTML (see the W3C web site for the current standard definitions). Many of the well known HTML editors or "something to HTML converters" produce illegal code. Errors include: Since various browsers handle illegal HTML code very different, the very same web page may appear perfect on one client and as an empty page or only in fragments on others.
It is well worth to check the HTML code generated by your favorite authoring tool. You can check it manually by actually looking at the source code, view the same page with different browsers or feed it into one of the available HTML validator, such as the W3C HTML Validation Service available on the W3C web site.

(Personal note: There is one authoring tool that I know of which claims to produce the "industries best HTML code" and I think it really does. The company is located very close to where this conference takes place and I use it to create all my web pages, including this.)

To the table of contents

5. What difference makes the hardware of the client ?

The following properties of the hardware have an impact on accessibility:

To the table of contents

6. How do different browsers handle HTML  ?

By definition, browsers should ignore everything they do not understand or they don't know how to handle. But especially the more recent versions of the well known browsers try to display as much information as possible. This is not necessarily bad, however it may invite authors - and programmers of authoring tools - not to care too much about correct HTML. Still browsers do handle correct and incorrect HTML code differently.
Example: How do browser handle a table with a missing end tag ?

In addition, if the browser does support scripts or not has a high impact on accessibility. Many web sites depend on Java scripts or applets, but some browsers are not able to execute such scripts, including IE on Windows CE and most non-graphical browsers, such as Lynx or WebSpeak. Also, some people may have configured their browser to disallow the execution of any scripts locally for security reasons.

With the increasing amount of "light browsers", such as Windows CE based clients e.g. built into a car stereo unit, it may become more important to provide non-script web sites. It will be very frustrating if a person in a car with a light browser want's to find the address of a particular company on their web page but can't get the information just because the whole site depends on Java scripts.

From an accessibility point of view, server side scripting, such as Active Server Pages (ASP) are a good alternative to client side scripting. However, on very busy web sites, this may lead to performance problems.

To the table of contents

7. Measuring accessibility:

It was the goal of this work to develop a method to measure accessibility of web pages. We started out with an accessibility lab which included the following wide range of hardware and software:
Operating System Browser
Windows 9x/NT Amaya Version 1.3b
MacOS Microsoft Internet Explorer, current version*
Unix Microsoft Internet Explorer, current version*
Windows 9x/NT Microsoft Internet Explorer, current version*
MacOS Netscape Communicator, current version*
Unix Netscape Communicator, current version*
Windows 9x/NT Netscape Communicator, current version*
Windows 9x/NT Amaya V1.2a
MacOS Microsoft Internet Explorer, previous version**
Unix Microsoft Internet Explorer, previous version**
Windows 9x/NT Microsoft Internet Explorer, previous version**
MacOS Netscape Communicator, previous version**
Unix Netscape Communicator, previous version**
Windows 9x/NT Netscape Communicator, previous version**
Windows CE Microsoft Pocket Internet Explorer
OpenVMS Lynx V2.8
Windows 9x/NT pwWebSpeak V2.0

current version*: Version V4.x or V5.x
previous version**: Version V3.x or less

But soon, it became obvious that in terms of accessibility, the current and even the previous versions of the well known browsers behave very similar. Only "light browsers", such as Pocket Internet Explorer on Windows CE or non-graphical browsers would make a real difference. Therefore, the accessibility lab was reduced to include only the hardware/software combinations listed below.
To measure accessibility, we looked at a web pages with different clients and assigned accessibility points depending on how much of the web pages actually could be used with each browser. In addition, a factor was assign to each browser depending on its capabilities. The less features a browser supports, the higher the factor is.

7.1 Accessibility lab:

Operating System Browser Factor
Windows 9x/NT / MAC OS Microsoft Internet Explorer V4.01* 1
Windows 9x/NT / MAC OS Netscape Communicator V4.5* 1
OpenVMS Spyglass enhanced Mosaic V2.1 2
Windows CE V2.0 Microsoft Pocket Internet Explorer 3
OpenVMS Lynx V2.8 4
Windows 9x/NT pwWebSpeak V2.0 5

*: Could be V3.x or higher

7.2 Accessibility schema I:

To measure accessibility, we accessed a particular web page with all the clients mentioned above and checked if the content could be used completely, only partially or not at all. The following zero to three points ranking schema was defined:

Result Ranking
The content is completely accessible 100%
Only part of the content is accessible, but the web page is still useful 67%
Only part of the content is accessible, important information was missing 33%
The content is not accessible at all 0%

7.3 Accessibility schema II:

Beside the hardware and software, there are other factors that influence accessibility, such as the capabilities of the human being trying to use the information. The following properties of a web page have a direct impact on accessibility for people with disabilities:

Again, a factor was assigned to these properties:

Property Value Factor
Fixed color schema No 1.0
Yes 0.9
Text as images No 1.0
Yes 0.8
Minimum required screen width if 640 pixels or less 1.0
more than 640 pixels 0.00463 * screen width + 13.073¹

¹) These values lead to a decrease of the accessibility by 10% if a minimal screen width of 1024 pixels is required.

To compute the final accessibility value, multiply the resulting number of points from schema I with the factors of schema II.

Depending on the accessibility value, we can describe the accessibility of a web page as follows:

Value Accessibility
100% excellent
75 .. <100 good
50 .. <75 ok
25 .. <50 fair
>0 .. <25 poor
0 inaccessible

A form was developed to compute the accessibility value based on the properties of a web page found in the accessibility lab, but to compare multiple web pages, it might be more convenient to use a spread sheet application.

7.4 Examples of accessibility measuring:

This table lists the homepages which had been used to check accessibility according to the measuring schemes explained above. Pages with best accessibility ranking are listed first.
Ranking Titel URL Value Text
1 Sport www.sports.com 100% excellent
1 Swiss Government www.admin.ch 100% excellent
1 Uni Zürich www.unizh.ch 100% excellent
1 White House www.whitehouse.gov 100% excellent
1 Yahoo www.yahoo.com 100% excellent
2 AltaVista www.altavista.com 90% good
2 M.I.T web.mit.edu 90% good
2 NASA www.nasa.gov 90% good
2 Netscape www.netscape.com 90% good
2 W3C www.w3c.org 90% good
2 WWW8 www8.org 90% good
3 Amazon www.amazon.com 72% ok
3 CNN www.cnn.com 72% ok
3 ETH Zürich www.ethz.ch 72% ok
3 Microsoft www.microsoft.com 72% ok
3 Swissair www.swissair.com 72% ok
4 UBS www.ubs.com 68% ok
5 EPFL www.epfl.ch 51% ok
6 SBB www.sbb.ch 45% fair
6 Virtual Tourist www.vtourist.com 45% fair
7 MIGROS www.migros.com 23% poor
8 ZKB www.zkb.com 9% poor

For details, see the complete list of results.

To the table of contents

8. Analysis:

The analysis of the accessibility ranking above unveils to main problems in terms of accessibility:
  1. Scripts
  2. Images without alternate tags
  3. Text as images
  4. Fixed color schemes

The problem with scripts:

Web sites which depend completely on client-side scripts are hard to access with non-graphical or "light" browsers. If the execution of client-side scripts is required for navigation, it is nearly impossible to move around with non-graphical browsers. There is not much of a problem if scripts are only required to handle features such as "mouse-over".
In addition, many scripts check if the client is Netscape V3 or higher or Internet Explorer V4 or higher. If not, they assume the browser can neither handle scripts nor frames. If the user tries to access such a page with a different browser - such as Amaya - the page cannot be viewed, even if the browser can handle frames and scripts. To me, this is as if you have to drive a car from a certain manufacturer to be allowed to drive on the highway ...

The problem with images:

Important note: HTML V4.0 requires the ALT attribute for an IMG tag !
Pages with images without ALT attributes are very difficult to access with non-graphical browsers. Or to put it the other way round: If the ALT attribute is used reasonably, it can help users of character-based or speech browsers a lot. Reasonable means use a text that is meaning full, such as the name of the company for the company logo etc. Information such as the size of the image are not very helpful at all.

The problems with text as images:

  1. Images do not scale:
    Regardless of the size of the screen and the size of the fonts chosen for the "real text", the size of the image always stays the same. If the headings are images, this may lead to a situation were the actual text appears larger than the headings.

  2. Images are good for graphical browsers only:
    Even though the majority of the web surfers use graphical browsers, there are people out there who cannot enjoy pictures for different reasons. Some have only character based browsers (such as lynx). Others configure their browser to not display pictures (e.g. to speed up the data transfer and to save communication costs). And there is an increasing number of people with sight disabilities who wish to enjoy the web, but have to use an acoustic output device or a braille reader. Such devices cannot handle pictures (in some cases the use of the ALT attribute can help to solve this problem).

  3. Images will not be indexed by search engines:
    Search engines, such as AltaVista, index text. If an author uses images for headings, these words won't be indexed. This is particularly bad, because words in headings have priority over words somewhere in the text and would cause a document to appear on top of the list of the documents returned by search engines.

  4. Images slow down the transfer of a document:
    Pictures are usually large compared to text and slow down the transfer of a document. Web surfers are generally impatient and refuse to wait too long. Too many pictures will drive away potential customers from a web site.

  5. images are more difficult to maintain:
    An artist may create a very neat looking page for you. However, if she or he uses lot's of images to display text, it may be very cumbersome to maintain this page. Each time you have to change a title, you need a graphic software to create a new or modify an existing picture. This is not necessarily straight forward. And don't think this page will never change !

The Problem with fixed color schemes:

Some people have difficulties to see some particular colors or color combinations. In addition, colors appear different from monitor to monitor. Therefore a user may configure her or his browser to use a particular color setting. Most browsers allow to set colors for the background, regular text, visited and unvisited links etc. If a document overwrites some of these settings, part of the page may become invisible, e.g. if we end up with blue text on a blue background. If the settings for all colors are overwritten, the user may be unable to see these colors.

To the table of contents

9. Conclusion and Recommendations:

Based on the work in our accessibility lab and the analysis explained in the previous chapter, we came to the following conclusion and recommendations:

Use the ALT attribute in every IMG tag:
Even though this seems to be an obvious recommendation, many authors still do not specify an alternate text for images. With HTML V4.0, the ALT attribute is no longer an option, it is required !
Without the ALT attribute, web pages which depend on images are very likely to become inaccessible for non-graphical browsers. But even images which are there for decoration only (e.g. a horizontal ruler), should have an ALT attribute, so that visitors with non-graphical browsers know, that they do not miss important information.

Use the ABBR tag:
Abbreviations are especially hard for speech browsers. They may know some abbreviations - such as NY for New York - but the may not know other abbreviations and try to speak them phonetically. Depending on the characters used, this may lead to unrecognizable sounds such as "chf" ("CHF" stands for "Swiss Francs"). Other abbreviations may be miss-interpreted, such as "US" or "DEC". pwWebSpeak interprets "dec" as "December", but there used to be a company called "DEC" (Digital Equipment Corporation). Therefore the phrase "while I worked for DEC" is spoken as "while I worked for December". By using the ABBR-tag, we can tell the browsers that DEC stands for "Digital Equipment Corporation".
See example.

About tables:
Tables need special care if they should be easily accessible even with non-graphical browsers. HTML defines tables row by row, therefore non-graphical browsers render them from left to right. Some tables are structured vertically, they only make sense if read top down. For non-graphical browsers such as WebSpeak, tables should be designed horizontally and cells should have a title attribute.
See example

Further suggestions are under investigation ...

I believe, accessibility can also benefit from the efforts in the area of internationalization. On a global scale, foreign languages and even more foreign character sets generally decrease accessibility (Any language other than English is considered a foreign language and any character set other than 7-bit ANSI is considered a foreign character set).

To the table of contents

accessibility.html / 9-mar-1999 / reto ambühler and Jakob Lindenmeyer, ETH Zürich, Switzerland