Many people will have heard about web accessibility. Not everyone is even sure what it is, many people confuse accessibility with useability. Many other developers either ignore accessibility as either a waste of time or too hard to implement. They fail to see the need for providing content to users who will struggle to work with it.

The reason why web accessibility is important is simple. The web is an important resource for millions of people at all levels, be it educational, community building, governmental, commercial or just plain fun. No one should be denied access to these resources due to any impairment they may have.

Another misconception about web accessibility is that it only applies to blind users. Obviously blind users will have a great deal of difficulty when accessing the web but there are large numbers of other web users who experience problems. These can include a person with photosensitive epilepsy having a seizure triggered by animations on a page, a user with Attention Deficient Hyperactivity Disorder being overwhelmed by the amount of content on a page or a deaf user not hearing audio feedback in a highly interactive piece of content. There are excellent simulations of some of these problems at webaim simulations

Partly due to pressures from disabled rights activists and also the W3C-WAI themselves many countries have introduced legislation to require web sites to meet certain technical standards for accessibility. The USA has Section 508 of the Rehabilitation Act of 1973. The UK does not specifically have legislation but the Disability Rights Commission refers to websites as one of the "services to the public" that should be covered by the Disability Discrimition Act.

These legal frameworks all introduce slightly different technical standards. Most of them are similar to or based on the World Wide Web Consortium - Web Accessibility Initative (W3C-WAI).

The W3C-WAI was set up to address the problems. It consists of a group of experts in the field who analyze problems and make recommendations for solutions. It covers many more areas than the actual coding and design of sites such as web-browsers such as Firefox, web authoring tools such as Dreamweaver and screen readers and other assistive technologies such as the JAWS screen reader. None of its guidelines are legally binding but its technical expertise is often used as a starting point for legislators.

The W3C-WAI have a very useful quick checklist for accessibility. This provides a good starting point for any web developer and serves as a useful index to the often complex rules themselves.

Only a few of these items apply to Ingenta as we deliberately avoid some areas such as frames that cause a great deal of problems with accessibility. The main problems for Ingenta are

• images
  
• links
  
• page organization
  
• tables
  
• javascript

For all of these Ingenta's strategy is to minimize the use of potential problem causing elements and maximize their accessibility when they are used. A good example of this is the right hand navigation bar's use of javascript. Here javascript is used to hide or display sections of content to make the page more usable by reducing the amount of information overload. (This can be an accessibility issue too as mentioned previously). For many users with screen readers or other non-conventional browsers javascript simply does not work. In order to make the navigation bar accessible with no javascript all the content is available on the page at all times. The javascript hides visible content instead of revealing hidden content. In order to see this in action try visiting an article on IngentaConnect and turning off javascript in your browser.

In order to check if your site is accessible it is necessary to validate it. The most commonly used validation service is bobby. This takes individual pages and checks them against the W3C-WAI guidelines. It rates each page from AAA (the highest standard) to ungraded. The main content of IngentaConnect aims to be AA rated though some individual pages may slip to A. (I plan to improve this with time.) The reports Bobby generates can be confusing. For example any .gif image on the page will be flagged as potentially causing flashing effect harmful to epileptics regardless of if the image is animated or not. Therefore it is important to carefully interpret the results.

As with any element of a software engineering project there has to be a degree of compromise. The time required to implement accessibility content may be squeezed due to other requirements. Some accessibility features can be hard to implement in a consistent way leading to them being abandoned.

However from a moral, legal and commercial standpoint we cannot ignore the needs of any of our users. This makes accessibility a vital part of development at Ingenta.