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.
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.
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
The key factors for a successful web site are:
- Findability
- Valuable information
- Accessibility
Findability
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
Accessibility is important in two respects:
- 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.
- 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.
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.
- Incorrect enclosing of tags, e.g.
<FONT SIZE="+1"> <STRONG> some text </FONT> </STRONG> - Missing required end tags
- Illegal META tags
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.)
The following properties of the hardware have an impact on accessibility:
- Resolution of the screen: The lower the resolution, the smaller is the visible part of a document. Some layouts depend on a minimal window width. Fixed width attributes of tables or frames may lead to inaccessible parts of a document on screens with low resolution.
- Number of colors: Some combinations of colors may be easy to read on some screens but hard on others. The lower the number of supported colors, the less distinguishable similar colors may become. In addition, some people may have difficulties to see certain colors or color combinations.
- Sound card: Some web sites provide not only text and graphics, but also sound. Of course, without a sound hard, the audio part of such documents is inaccessible.
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 ?
- Amaya V1.2a on Windows 95/NT: The rest of the document after the table becomes part of the table. All is visible, but the layout is incorrect.
- Amaya V1.3b on Windows 95/NT: The rest of the document after the table is invisible.
- Internet Explorer V4.0 and V5.0 on Windows 95/NT: The table is shown at the end of the document. All is visible, but the text appears out of order and the layout is incorrect.
- Netscape V3.0 .. 4.5 on Unix and Windows 95/NT: The table is simply ignored. Not all is visible, but the visible part is shown in correct order and layout.
- Pocket Internet Explorer on Windows CE V2.0: The rest of the document after the table becomes part of the last table row. All is visible, but the layout is incorrect.
- Lynx V2.8 on OpenVMS: The document is rendered as if the end tag was present at the end of the table.
- pwWebSpeak V2.0 on Windows 95/NT: The document is rendered as if the end tag was present at the end of the table.
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.
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 lessBut 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:
- Fixed color schemes: Because some people cannot see colors at all, have difficulties to see some particular colors or particular color combinations (e.g. red text on blue background), fixed color schemes reduce accessibility.
- Text as images: This has two negative impacts on accessibility:
- Because images have a fixed size, they do not scale if the user changes the font size
- If the user has special color settings, images do not adapt to these settings
- Minimum required screen width: Of course, this property has nothing to do with human capabilities. But a minimum screen width of more than 640 pixels may lead to inaccessible parts of a document on small screens of notebooks, handheld PCs and other small devices. We have therefore defined a factor that decreases accessibility when a screen size of more than 640 pixels is required to access all information.
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.
The analysis of the accessibility ranking above unveils to main problems in terms of accessibility:
- Scripts
- Images without alternate tags
- Text as images
- 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:
- 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.
- 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).
- 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.
- 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.
- 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.
Based on the work in our accessibility lab and the analysis explained in the previous chapter, we came to the following conclusion and recommendations:
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).