PostNuke

Flexible Content Management System

News

Web Accessibility - An introduction

Contributed by on Oct 08, 2003 - 02:59 PM

Accessibility - In General


According to the German federal law on equality of treatment of handicapped
persons (BGG §4) ", constructions, means of transportation, technical
commodities, systems of information processing, accustic and
visual sources of information and communicative systems are accessible when they
are accessible and usable for handicapped persons unaidedly, in the usual way
and without special difficulty."


Basically, accessible web pages aren't only accessible for the average user
at his desktop pc with the latest browsers. Web-accessibility is not only considerate
of the various utilities that handicapped persons use to perceive a web page,
but also of users with older browser versions or with special access hardware.


Some figures to give an idea of the size of this group (statistics from Germany):



  • 10% of the male population is color-blind. Web pages with low contrasts
    (eg. black fonts on dark-blue background) is for them practically unreadable.
    "Press the green button to verify" is meaningless to them.

  • 5% of the population is blind or visually handicapped. They use special utilities
    and hardware like Braille-displays or screenreaders.

  • 11% of the population is older than 65.

  • 5% of internet users don't use Windows, but MacOS, Linux, PDAs or cellphones.

  • Numerous sites, especially large ones, still have up to 20% users visiting them through 4th generation Netscape
    browsers.


If you don't only aim at gamer kiddies with 19" displays, you should start
thinking about whom you exclude with your killer design. A blind person for example,
who cannot use a company`s internet pages, will choose another vendor. But what
can a blind person do when his registration office's internet site is not accessible?


 


The Legal Side


Since May 1st, 2002, the ordinance for accessible information technology
(BITV) became effective. All federal institutions are obliged to make their internet
sites accessible - in the sense of the word used in this article. Governments are called to work out
similar state laws which oblige state and municipal institutions to follow accessibility guidelines.


BGG and BITV are based on the EU action plan "eEurope 2002", initiated
in 1999 and finalised in 2000 by the European Council. eEurope aims at 3 main goals:



  • A cheaper, faster and more secure internet

  • Advancement of internet use

  • Investment into persons and abilities


The latter comprises the participation in information technology of as big
parts of the population as possible. Summarised under the term "eAccessibility",
access to eCommerce, eGovernment and so on is to be made possible. This was to be
implemented with the adoption of the Web
Accessability Initative
's guidelines.


 


Guidelines for Practical Use


Already in 1999 the World Wide Web Consortium (W3C) released the Web
Content Accessibility Guidelines 1.0
and made it quasi-standard for accessible
internet design. Since then many of the rules have proved too restrictive,
irrelevant, incomprehensible or simply not representative of the state of technology
anymore. Some of them even turned out to be not internationally applicable.
For these reasons a version 2.0 is in the making. Since v. 2.0 is still in development, this
text will only relate to WCAG 1.


The Web Content Accessibility Guidelines 1 are split up into 3 priorities:


Priority 1: A Web content developer must
satisfy this checkpoint


Priority 2: A Web content developer should
satisfy this checkpoint


Priority 3: A Web content developer may satisfy
this checkpoint


If you violate a regulation of priority 1, many people will be excluded. A violation
of priority 3 regulations excludes only few. There are 14 main regulations, with
the priorities attached to all of their subcategories:



1. Provide equivalent alternatives to auditory and visual content.

2. Do not rely on color alone.

3. Use markup and style sheets, and do so properly.

4. Clarify natural language usage.

5. Create tables that transform gracefully.

6. Ensure that pages featuring new technologies transform gracefully.

7. Ensure user control of time-sensitive content changes.

8. Ensure direct accessibility of embedded user interfaces.

9. Design for device-independence.

10. Use interim solutions.

11. Use W3C technologies and guidelines.

12. Provide context and orientation information.

13. Provide clear navigation mechanisms.

14. Ensure that documents are clear and simple.



There is also a W3C-list of suggested Techniques
for Web Content Accessibility Guidelines 1.0
.


 


Testing Accessability


Several tools exist for testing the accessibility of your website:


http://www.w3.org/WAI/WCAG1AAA-Conformance


http://bobby.cast.org/


http://www.cynthiasays.com/


As a result you receive 3 levels of conformance:


Conformance Level "A": All Priority 1 checkpoints
are satisfied

Conformance Level "Double-A": All Priority 1 and
2 checkpoints are satisfied

Conformance Level "Triple-A": All Priority 1, 2,
and 3 checkpoints are satisfied


Internet sites of German federal instititions have to fullfil Double-A conformance.
Recommended is Triple-A.


 


Not only for handicapped persons


A main problem with accessibilty is that a web site must cater to the needs of two different interest groups: On the one
hand, handicapped persons that already have to use the latest browser version
in cooperation with their hardware and utilities, and on the other hand, users
with old browsers.

This problem is however a perfect focus area for the idea behind CMS-es: The separation
of content and layout. It becomes possible to detect the user browser client, and in a manageable way offer
a classical HTML 3.0 page or a modern HTML 4.01 page, with the same content.


Practically speaking, modern web design means above all to do without tables for layout
use. Tables have always been a crutch when it comes to creating layout, and more so today than ever.
Modern layout is created via CSS. A nice example of how accessible
design can be created can be found at http://www.inknoise.com/experimental/layoutomatic.php.
This also shows that accessible web sites do not have to be plain text.


Tables should only be used the way they were originally intended: For example
as an address table with columns and rows, column heads and so on. Used this way, also
the tools of blind persons can make sense of them.


 


Accessibility and Postnuke


Making a Postnuke site accessible is practically impossible: While themes can
easily be created with CSS, you will fail at the modules, which excessively
use hardcoded tables. Not until the introduction of the Xanthia Templating Engine
in Postnuke 0.8 will it be possible to make your site accessible for everyone.
Then you can start developing accessible templates for all API-compliant modules,
something which is currently possible only with third-party modules that use smarty, like
PostCalendar or pnCommerce.


Until then the possibilities are limited when it comes to making at least some of your content
accessible: The AvantGo module - originally designed to make the News accessible
for PDAs - can also be used for accessibility. There seems to be an extended
version of the Avantgo named Extravantgo, but during my researches the download
page was inaccessible ;-)


German version of this article: post-nuke.net


4094