Quelltext der Seite Accessibility in Web Applications

Accessibility in Web Applications

== Introduction ==

=== Preface ===

This article deals with accessibility in web applications; how to design your website to provide your webpage for everyone, especially for people with disabilities. 
Practical examples will help you understanding the 
[http://www.w3.org/ W3C]
recommendations. All guidelines of the W3C won't be mentioned; only these ones which are very important. Experience shows that if these guidelines are realized accessibility will improve automatically.
Furthermore actual 
[http://en.wikipedia.org/wiki/Web_2.0 Web2.0]
technology and their accessibility problems and some propusals are introduced. 
After that this article gives an introduction in verification methods and [http://en.wikipedia.org/wiki/Screen_reader screen readers.]
At the end various web links and literature are listed to provide more specific information.

=== Code Examples ===

Code examples are given in 
[http://en.wikipedia.org/wiki/Html HTML.]
Screenshots aren't used because they would not be accessible. 
Furthermore visual results aren't used, too because the examples are quite simple and the visual results do not play any role at this point.

== History ==

It began in the U.S. with a compliance review in 1996. This review should find out whether students with disabilities have the same learning conditions as their colleagues without disabilities.
This review concentrated on the design of the university websites whether persons with visual impairments can get the necessary information.
 An outcome of this review was a paper with nine points. One of these points was a system-wide (universities) guideline for designing these homepages under the condition that these homepages will be accessible for people with and without disabilities under the same conditions.
In 1998 a system-wide guideline came out an the problem of accessibility were solved at these universities.
In 1999 the W3C specified an international version of these guidelines to improve web accessibility in common.
The European Union voted in law in 2002 that every homepage in their domain should be accessible till 2008. 

== Accessibility -- Definition ==

Accessibility is a non-functional criteria of software quality and part of 
[http://en.wikipedia.org/wiki/Usability usability]
and especially deals with homepages but it can be understand in any kind of software. This term includes all methods and solutions which improve the
[http://en.wikipedia.org/wiki/GUI GUI]
design of a software in a way that helps people with or without disabilities find provided information quickly and under equal conditions.
It mustn't exist platform and device dependencies.

== The WAI Guidelines ==

[http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/ Web Accessibility Initiative]
(WAI) is a set of rules which shall help to create accessible websites.
There are several points which will be introduced and summarized in the next chapters.

=== Labeling ===

Every HTML element can be associated with a text label. When 
screen readers parse the (generated) document they are searching for such labels.
If a label is found its text will converted to 
[http://en.wikipedia.org/wiki/Speech_synthesis speech]
and/or 
[http://en.wikipedia.org/wiki/Braille braille]
 and the user gets the information. After that process the user should know which functionality this element has or what this element represents. 

==== Graphics and Links ====

A website without graphics and links would be impossible especially nowadays. Therefore labeling these elements correctly plays an important role when a page should be accessible.
The following rules help you to realize that:

* The label should be short and precious.
* Attention: The [http://www.w3.org/TR/html4/struct/global.html#h-7.4.3 title] attribute has no effect on screen readers.
* Don't use symbols only. 

==== Examples ====

The following examples help you to understand the realization of the rules above.
These examples are divided in two categories: Graphics and links. Each category has a positive and a negative example.

# Graphics: <nowiki><img src="img01.gif" alt="tree"></nowiki> but NOT as follows: <nowiki><img src="img01.gif" alt="image"></nowiki>
# Links: <nowiki><a href="nextpage.php">Next-></a><nowiki> but NOT as follows: <nowiki><a href="nextPage.php">-></a></nowiki>

=== Tables ===

Before starting to describe the rules some words to the screen reader parsing and realization method.
Please note that this is a theory because there are no good parsing and converting algorithms available in public.

If a screen reader finds a table determined by the 
[http://www.w3schools.com/tags/tag_table.asp table]
tag it firstly counts the rows and columns and let the user know the information by speech and/or braille. If there exists a "summary" tag the screen reader reads the words included in this tag plus a word like summary to inform the user.
 Secondly the screen reader looks for [http://www.w3schools.com/tags/tag_td.asp td]
or [http://www.w3schools.com/tags/tag_th.asp th]
tags. These tags help to distinguish between differen columns. Most of the commonly used screen readers provide special navigation quick keys in tables. You can jump to the next row or column by pressing a pre-defined key. If there are several "th" tags and the user navigates through the table it doesn't only read the contents of the current column but it adds the header of this column (standing in the "th" tag) and then reads the contents of the current column. The user now know exactly where he/she is.
 Tables are very frequently used HTML elements. But sometimes there are used unnecessarily e.g. for layout reasons.
If you want to manipulate the layout please use [http://www.w3.org/Style/CSS/ CSS]
to place HTML elements in any order.
Besides that use the following rules for designing tables:
* Use the [http://www.w3schools.com/tags/tag_table.asp summary] tag to give users with screen readers a chance to get the content of the table fast and easily.
* Use also the [http://www.w3schools.com/tags/tag_th.asp th] tag to simplify navigation in tables.
* Try to insert a table only when it's really necessary.
* If you want to place form fields in a table place their labels on the left side and themselves on the right one. The reason for that is the way how screen readers show HTML documents. You will get more information about that in chapter [[#Structuring Web Pages|Structuring Web Pages]]

==== Tables -- Examples ====

The following examples illustrate two accessible tables.
The first one is a simple example how data can provided as a table and 
the second one shows a formular in a table.
Some size values made in the examples have no special reason. 

Example 1:
    <nowiki><p>This is a small demonstration of an accessible table.</p>
      <table border="1" summary="a list of countries and their capitals"> 
        <colgroup>
          <col width="50">
          <col width="200">
        </colgroup>
        <tr>
          <th>country</th>
          <th>capital</th>
        </tr>
        <tr>
          <td>Germany</td>
          <td>Berlin</td>
        </tr>  
      </table></nowiki>

Example 2:
    <nowiki><p>This is a small demonstration of an accessible table with a
    formular</p>
    <table border="1" summary="a little formular">
      <colgroup>
        <col width="50">
        <col width="200">
      </colgroup>
	  <tr>
        <th>description</th>
        <th>value to enter</th>
      </tr>
      <form action="test" method="post">
      <tr>
        <td>E-Mail address:</td>
        <td>
           <input type="text" name="mail">
        </td>
      </tr>
      <tr>
        <td>Your homepage</td>
		<td>
           <input type="text" name="hp">
	    </td>
      </tr>
      <tr>
         <td></td>
		 <td>
            <button type="submit"                   name="send data"></button>
    	 </td>
	  </tr>
      </form>
    </table></nowiki>

 In the second example you could leave out the "th" tags because the formular elements have an own label (leftern side of the table) and the table headers could only describe general things.
 
 
=== Structuring Web Pages ===

One rule of the WAI says that homepages should be structured well and clearly. This is not as self-understanding as one can think.
To understand the reason of that you have to understand how screen readers formats and transforms a web document. 
 When a screen reader runs there are two output possibilities:
# Speech and
# Braille.

For braille output you need a special device; it's called a 
[http://en.wikipedia.org/wiki/Refreshable_Braille_display braille display.]
It just contains a simple line with a limited amount of cells. Each cell represents one mark.
Although these output methods are completely different they have one similarity. It is the miss of the overview over a complete, currently loaded site. The user only knows what the screen reader speaks at that moment or shows on the braille display.
 To understand that better consider a screen with a currently loaded webpage on it. Take a piece of paper on the screen in a way that you can see only one line of your screen. If you want to get more information you have to move this paper up or down. Eventually you need a second piece of paper to get the same effect. When you move these pieces of paper you will realize that you can only see one line at the moment. To increase navigation speed screen readers provide a set of keystrokes to navigate through websites. When a user knows the structure of a website he/she can jump e.g. to a header quickly.
 Therefore you should accurately plan your webpage design because redesigning an existing page could be more difficult than completely designing a new one.
To get more concrete an example for a design, a screen reader output example and more tips are shown below after the examples.

==== Structuring -- an Example for Designing ====

You can structure your homepage with headers and subheaders as follows:

 <nowiki>
 <body>
   <h1>Navigation</h1>
     The navigation links (can be formatted as a list)

   <h1>topic or subtopic area</h1>
     topic or subtopic specific links (can be formatted as a list)
     These links logically depends from the current navigation position in e.g. a web portal.

   <h2>Content area</h2>
     The text depending from the topics or subtopics is found at this position.
     If this text has logical parts itself can be structured with subheaders (in this case h3 etc.)

   <h1>About this page</h1>
     Here are the links concerning information about the author, the company, site policies etc (can be formatted as a list).
 </body>
</nowiki>

The hint about the list will be explained in the next chapter.
 The introduced structuring method is quite good and partialy used by well-known websites like [http://en.wikipedia.org Wikipedia.]

==== Structuring -- a Screen Reader Output Example ====

The following output is a table from the page
[http://www.wetteronline.de/Hessen/Giessen.htm]
a real screen reader output (users with screen readers get the information at this way).
The table is in German.
<nowiki>
 Vorhersage für die Region Gießen   
Tabelle mit 4 Spalten und 6 Reihen

Text 
Di, 18.12. 
Mi, 19.12. 
Do, 20.12. 
Tiefst-Temperatur 
-4°C 
-4°C 
-5°C 
Höchst-Temperatur 
2°C 
2°C 
3°C 
Vormittag 
unterschiedlich bewölkt  
meist sonnig  
sonnig  
Nachmittag 
unterschiedlich bewölkt  
meist sonnig  
sonnig  
Abend 
leicht bewölkt  
leicht bewölkt  
klar  
Tabellen ende
</nowiki>

The words like "klar" are graphics in reality. The screen reader read the labels from them. 
The word "Text" at the beginning of the table was a link to a text version.

=== Separating Belongings ===

In a web portal there are hundreds or even thousands of links. Of course, they won't be shown permanently but depending on the current module which is active. Besides this fact the developer has to think about how to categorize these links into groups. This method has the following advantages:
* Each link group can associated with another functionality or action handler.
* There is no coupling between these functionalities by default.
* Every link group could be configured separately (e.g. with CSS)
* Less complexity: The developer thinks in link groups, not in just links.

If you have found out your categories and subcategories you can e.g. insert them into the example homepage structure shown above.
Let's figure out a basic method to categorize with following steps:
* Try to categorize the links (e.g. navigation, content, external links/tools).
* Separate these categories strictly.
* Apply this categorization to all pages/subpages.
 You should use [http://www.w3.org/TR/html401/struct/lists.html lists] to represent the different categories.  

=== Hotkeys ===

This topic isn't mentioned in the guidelines explicitly. But it is one aspect of accessibility which can improve navigation speed on a website rapidly. 
Consider the following szenario:
 The user reads a webpage with a screen reader. If it finds the
[http://www.w3.org/TR/html4/interact/forms.html accesskey]
attribute within (e.g. a link) it speaks and/or displays the link label + the hotkey. Then, if the user frequently visits this homepage he/she knows this access key and can immediately press this one. An access key has the form:
<alternateKey>+<key> where
* alternateKey is the key you have to hold down. In [http://en.wikipedia.org/wiki/Windows MS Windows] systems it is the alt key; in [http://en.wikipedia.org/wiki/Mac_OS_X Macintosh] systems it is the CMD key.
* key is any other key on the keyboard.

The dependency on the site structure has been decreased. 
But it doesn't mean that you should use as many access keys as you have links. The amount of them is very limited.
Browser menus will activated by pressing the alt key. If you then press "f" you come to the file menu in the most English browsers or to the favorite menu in Microsoft's Internet Explorer (German version).
 You see there will be many problems and your keys eventually won't work when you take letters to assign keys to links.
The best solution for this problem is to take only numbers you can combine with the alt key.
So you have ten possibilities from alt+0 up to alt+9.

=== Provide Alternate Data ===

A simple example of this rule was already shown in
[[#Graphics and Links|Graphics and Links.]]
If there is a graphic a readable and understandable label must be exist.
That was the "weak" form of this rule. 
 The next step of this rule to interpret is when you have a movie included in your webpage you should also offer a text alternative.
This means that you should describe what's happening in this movie at this alternate text.
Placing this text near a video link or flash movie is a good practice and the probability is much higher that the user will find it.
 Extremely visualized websites need a complete text version of this website. It can be that you have to re-create only some parts of your webpage because e.g. some modules use
[http://en.wikipedia.org/wiki/Ajax_%28programming%29 AJAX.]

=== Colors and Cascading Stylesheets ===

The choice of background and foreground colors plays an important role when people with different visual disabilities visit the website.
The contrast of these both colors have to be big enough that these people can distinguish the font from the screen.
Don't use the combination green and red because 
# The contrast is not big enough and
# Some visual disabilities don't allow to see any of these colors.
Please note that the 
[http://www.w3.org/TR/REC-CSS2/media.html media types]
has no effect on screen readers.
 Furthermore a good practice is to separate the formatting commands from the structure of the homepage.

=== Device and Platform Independency ===

One point of the guidelines is to create your website in a way that there are no dependencies on browsers, operating systems and devices.
In this case the media types will help you selecting diferent styles for different devices.
For developers there are also several tools to simulate different browsers, platforms and devices.

== Some Words about Web2.0 ==

In this chapter accessibility problems are discussed which are not mentioned anyway at the guidelines.
The problem of the guidelines is that they are relative old and hasn't been updated yet.
So they is no requirement specification for creating Web2.0 platforms.
 However there is the [http://www.w3.org/WAI/intro/aria ARIA]
group, a part of the W3C which deals with current accessibility problems. But it will take time till there are generalized solutions. 
The following chapters should help you to solve some common accessibility problems.

=== Captchas ===

[http://www.captcha.net Captchas]
are small images included at special points at the website (e.g. registration). 
They are used to verify that no application can use the web application itself (e.g. collecting user data or automatic registration processes).
You have to enter an alphanumeric password that is shown on this image. If you entered a wrong password an error message will appear with a newly generated image.
[http://en.wikipedia.org/wiki/Optical_character_recognition Optical Charakter Recognition]
 (OCR) doesn't help because the image is also hard to read for humans and an application could use some OCR plugins to access the pages.
For someone who can't see the picture it is not possible to complete a registration process or just do something else without help from other persons.
To solve this problem you can choose one of the following solutions:
* Provide an audiostream: Place a link near this image. IF the user clicks this link a synthetic voice will read out the needed password. Look at [https://accountservices.passport.net/reg.srf?roid=2&ru=https://accountservices.passport.net/ppnetworkhome.srf%3Fvv%3D500%26lc%3D1031&cru=https://accountservices.passport.net/ppnetworkhome.srf%3fvv%3d500%26lc%3d1031&sl=1&lc=1031 MSN] or [https://www.google.com/accounts/NewAccount?service=mail&continue=http%3A%2F%2Fmail.google.com%2Fmail%2Fe-11-10a4af77af13309045d40307fca0cee9-cc3abc184b6527ff5d8391d40522d0bc5c043f80&type=2&gd=1 Google Mail] registration to see/listen an example. This method is the securest one but at the beginning it could be hard to implement.
* Calculations: Provide randomly generated easy-to-solve calculation questions where the user has to enter the result in an input field. An example could be: 1 plus 4. A homepage where this method is used is found [http://www.barrierekompass.de/testformular.php here.] This method is very leight-weight and easy to implement. But it could be more insecure than the first algorithm.

=== AJAX ===

[http://en.wikipedia.org/wiki/Ajax_%28programming%29 AJAX] is used more and more frequently in the last years. 
The problem of AJAX is that just a specific area from a webpage will updated and the screen reader doesn't know when to re-read e.g. a value because it doesn't know when an area will be updated.
If the update cycle is very little (e.g. 30 seconds) it is quite difficult for the user to follow. 
There is no general solution for this problem. A person with a visual disability should check the website whether its usable.
An alternate version of this site or just a module has to be created if this site or a part of it shouldn't be accessible.

== Verification ==

After you made your website accessible you want to verify whether that was successfully.
Several verification and validation methods are introduced in this chapter.
There are following methods:
# verification by individuals and
# verification by software

=== Individuals ===

You can let test your website from individuals who have disabilities. The best to do is if it's possible to find people who have different disabilities. 
 The only problem which can appear is that you don't know anyone of these people. 
But the main advantage of this method is that these peopel know their assistive technologies very good and they can give you some special tips.

=== Software ===

You can also validate your website via software. There are 
# validators
# screen readers

==== Validators ====

The principle is the same as e.g. an 
[http://validator.w3.org/ XHTML validator.]
You e.g. go to a [http://checker.atrc.utoronto.ca/index.html validation service] and enter the url of your webpage. After the validation process a website with the results will appear. At that point you can see whether your site is accessible or not. 
 Offline accessibility validators are also available but the online versions are used in common.
 There is also a Firefox extension the [https://addons.mozilla.org/de/firefox/addon/60 Web Developer Tools.]
You probably use it when you are working with [http://estudy.mni.fh-giessen.de/ eStudy.]
To validate your website with this extension do the following:
# In firefox, go the tools menu->Addons->Web Developer Extension->Settings. 
# Check all checkboxes belonging with accessibility and save these settings.
# Go to your website.
# Then click on Tools->Web Developer Extension->Validate->Validate WAI.
 Some comments to that method:
* You can check the currently loaded website only. Products and services which check a comlete site are commercial mostly.
* It can happen that your website is not accessible although the validator has returned a good result or no problems. These accessibility issues are reported from people and mostly are structuring problems.

==== Screen Readers ====

Screen readers are one part of special software which helps the user with disabilities handle a computer.
You can use them to get more specific results. You have to install it mostly. Then you can browse your website. 
The problems you could have:
* If you have no experience in screen readers it is difficult to work with it at first.
* The results you will get are not measurable or displayable so it could be dificult to find out problems or improvements.
You should work with one of these screen readers:
* [http://freedomsci.com Job Access with Speech for Windows (JAWS)]
* [http://www.nvda-project.org Non-Visual Desktop Access for Windows (NVDA)]

The JAWS product is available as demonstration version only. But you can use it for fourty minutes and have then reboot your machine.
You can find setup tips and instructions in the 
[[JAWS Installationsguide]]
in German.

NVDA is an opensource alternative. Unfortunately it is not as good as JAWS but for testing it is good enough.
You don't have to install it. Do the following to get and run this screen reader:
# Go to [http://nvda-project.org nvda]
# Download the .zip package.
# Unzip it wherever you want.
# Change into the folder which contains the unzipped files.
# Double-click on "nvda.exe".
# That's it. To remove the product just exit the program and delete the folder.

Annotation: There are also screen reader solutions in 
[http://en.wikipedia.org/wiki/Linux Linux]
but there are not as good as in the internet than the 
[http://en.wikipedia.org/wiki/Windows Windows]
solutions.

== Conclusion ==

You have seen that accessibility is a non-functional criteria for creating web platforms. Although there are many different rules and guidelines how to design a website in that way it could become quite difficult to say that this homepage is accessible. A dialogue between these users and the webpage programmer is the best way to solve this problem and both of these groups ensure that a page will accessible in the future.


== Resources ==

=== Literature (German) ===
* Angie Radtke, Dr. Michael Charlier: Barrierefreies Webdesign; Addison-Wesley, 2006, ISBN: [http://www.addison-wesley.de/main/main.asp?page=home%2Fbookdetails&productid=117001&SID=%7B49F45AB2%2D3DE6%2D4A72%2DB7CE%2D5CF94B5FB40B%7D 978-3-8273-2379-8]

=== Web Links ===

==== eStudy Wiki Articles (German) ====

* [[eStudy und Accessibility]]
* [[Jaws Installationsguide]]


==== General Links ====

* [http://www.laspositascollege.edu/accessibility/history.php Accessibility history]
* [http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/ W3C recommendation (English)]
* [http://www.w3c.de/Trans/WAI/webinhalt.html W3C recommendation (German)]
* [http://www.selfhtml.org SelfHTML]
 
==== Validation Services ====
* [http://www.barrierekompass.de/testformular.php Barrierekompass]: Online validator, comercial, German
* [http://checker.atrc.utoronto.ca/index.html ATRC Web Accessibility Checker]: online validator, open source, in English and Italian
* [http://www.accesskeys.org/tools/color-contrast.html AccessColor]: Online validator for color contrast, freeware, English
* [http://validator.w3.org/ W3C markup validation service]: online, free HTML/XHTML validator

==== Software ====
* [https://addons.mozilla.org/de/firefox/addon/60 Web Developer Tools] : Firefox extension
* [http://www.freedomsci.de Jaws for windows (German)]: screen reader (MS Windows)
* [http://nvda-project.org/ NVDA Homepage]: screen reader (MS Windows)
* [http://gmazzocato.altervista.org/colorwheel/wheel.php Accessibility Color Wheel]: Simulates several kinds of visual impairments, Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License, in English and Italian (platform independent)