Skip navigation.

Accessibility & Inclusion
Your Online Presence > Accessible Websites, Delivering Services via the Web, Strategy & Development

Web 2.0 & Accessibility for Disabled Users

By Kath Moonan, AbilityNet

Web 2.0 has become one of the buzzwords within the internet community. In this article we examine what Web 2.0 is and what implications it might have for disabled people who use the Web, particularly the use of Ajax for interactive web pages.

What is Web 2.0?

The term Web 2.0 refers to a second generation of services available on the World Wide Web that lets people collaborate and share information online. Web 2.0 gives users an experience closer to desktop applications such as Word, Outlook and Excel.

Web technologies have evolved over timed and can be categorised as follows:

  • Web 1.0 static web pages with information on
  • Web 1.5 Content Management System (CMS) driven websites that allow users to manipulate information
  • Web 2.0 fully responsive web applications that mimic desktop programs – and also allow users to store and share information across the network

Examples

Examples of Web 2.0 applications that are relevant to the voluntary sector include:

  • Wikis – websites which allow users to add and edit data – Wikipedia.org is the most well known.
  • RSS (Really Simple Syndication) – a way of sharing information across websites for example, news feeds.
  • Blogs – online diaries
  • Social Networks – such as MySpace and LinkedIn
  • Project Management – time and resource management tools such as Basecamp

Issues for disabled people

There are a number of accessibility issues with Web 2.0 applications that can cause problems for disabled web users. This is primarily because many of the first generation Web 2.0 tools have been built without much thought for web accessibility. For example a key problem area is Ajax which can causes issues for screen reader users.

The kinds of problems disabled people might face include:

  • Inaccessible login boxes or security tests with no alternatives such as audio.
  • Inaccessible WYSIWYG editors that are not compatible with assistive technologies or only work with a mouse or pointing device instead of just the keyboard which makes it impossible for some users to create or edit text
  • Inaccessible interfaces which are dependent on drag and drop (interaction with a mouse or pointing device) with no alternative keyboard option.
  • Screen reader users are not alerted when content has changed dynamically without the page refreshing (specifically Ajax)
  • Inaccessible content users have created, such as:
    • Content is created without semantic code – which gives non visual information about the content, which is especially useful for screen reader users
    • Images are included without alt text
    • Styles and designs are selected which are difficult or impossible to read
    • Rich media is included without captions or alternatives
  • Inaccessible controls on audio or video players that are not compatible with assistive technologies or are reliant on using a mouse or pointing device
  • Users not being alerted to accessibility issues when inputting content

An accessible web 2.0 application

If you are considering using a web 2.0 application for your staff, volunteers or users, the accessibility of the product should be examined very carefully.

As most web applications allow content authoring they come under ATAG (Authoring Tool Accessibility Guidelines) as well as WCAG (Web Content Accessibility Guidelines) guidelines.

ATAG key checkpoints include:

  • Support accessible authoring practices
  • Generate standard mark-up
  • Support the creation of accessible content
  • Provide ways of checking and correcting inaccessible content
  • Integrate accessibility solutions into the overall “look and feel”
  • Promote accessibility in help and documentation
  • Ensure that the authoring tool is accessible to authors with disabilities

Use these guidelines to assess the accessibility of the applications you look at before buying or implementing them.

Technical Issues with Ajax

Ajax is shorthand for Asynchronous JavaScript and XML, it is a web development technique for creating interactive web applications. The purpose is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user requests a change.

Known Accessibility Problems

  • JavaScript turned off. If a user has turned JavaScript off, then calls to get information from the server will not be made. If no alternative has been provided, the user could be left unable to continue using the web page.
  • Alerting the user that a page has updated. If an Ajax call was successfully made, it will typically return some data from the server and update particular elements on the page (by replacing or altering html tags), leaving the rest of the page intact. For those with sight, this change may well be apparent - although this is not always the case, as Ajax calls tend to be very quick and are easily missed - it certainly won't be obvious to those using a screen reader. Some screen readers such as JAWS 7 and IBM Home Page Reader will support JavaScript and even be able to read the updated html elements but they won't inform a user that part of the page has updated.

What can be done to solve these problems?

It is hoped that both browser and screen reader manufacturers will work towards solutions for these issues by detecting when a page has been updated via an Ajax call. In the meantime there are a number of techniques that developers can use, but it must be said that at present there is no clear and simple solution, so at the moment use Web 2.0 techniques sparingly.

Ajax Accessibility Good Practice

Follow the "HIJAX" principles. This is based on the idea of progressive enhancement in much the same way as CSS in that the Ajax functions should form an additional and optional layer on top of the HTML mark-up :

  • Build a traditional website that uses hyper links and forms to pass information to the server. The server returns whole new pages with each request.
  • Add JavaScript to intercept those links and form submissions and pass the information via XMLHttpRequest instead. You can then select which parts of the page need to be updated instead of updating the whole page. More information can be found at : http://adactio.com/journal/959
  • Create unobtrusive JavaScript. This is a technique where all JavaScript is stored in a separate file and only used by Browsers that support the script. The idea being that the page should (as in HIJAX above) be able to function without the *.js file. This even includes removing event handlers such as OnClick, OnBlur etc to a function in the *.js file that will go through and add these to elements if JavaScript is available.
  • Inform the user at the top of the form that it requires JavaScript or detect JavaScript automatically and warn the user when it isn't available. If the form has many fields you will spare your users a lot of frustration. Everyone hates filling out a form just to find out that they can't submit it.
  • Inform the user that the page is updated dynamically. This is especially important for screen reader users and will help them decide when to trigger a re-read of the page. It may be possible to use the focus() method in JavaScript but only certain elements (usually on the form) support it and not all Screen readers do.
  • Use Alerts where appropriate. Make it possible to receive an alert when information is updated. This may not be possible depending on the complexity of your form but will help a screen reader user a lot. Alert boxes are read by the screen reader and are usually displayed together with a sound. The checkbox should be displayed so it is clear that it is not part of the original form.
  • Use the Role attribute. Although not supported by all screen readers, this is a W3C recommendation that describes the role(s) the current element plays in the context of the document. For example <div role="main"> defines the main content of a document and <ul role="navigation"> defines the page navigation links. Roles are especially useful when the html does not support all the semantics that you need. When a role is used the semantics and behaviour of the element are overridden by the role behaviour.

Examples of bad Ajax Accessibility

  • Site that is reliant on Ajax to function and provide no alternative.
  • Those that use inline scripting for example, code written directly into an onChange event.
  • Those that rely on mouse actions and have no keyboard alternative.

So what’s important?

Follow the WCAG.  It’s all there.  See Joe Clarke’s talk on Ajax for a nice wrap up of the specific guidelines associated with scripting.

Sources

Web 2.0 and Ajax

Wikipedia definition of Web 2.0

Wikiepedia definition of Ajax

Authoring tool Content Accessibility Guidelines

Juicy Studios Making Ajax Work with Screen Readers

ATAG assessment of WordPress

Is Ajax Accessible?  At all?  - Joe Clarke

Ajax and Screen readers: When Can it Work?

Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap)


About the author

Kath Moonan, AbilityNet
AbilityNet is a national charity helping disabled adults and children use computers and the internet by adapting and adjusting their technology.

Glossary

Ajax, ALT text, ATAG, Browser, CMS, CSS, HTML, Internet, JavaScript, Network, RSS, W3C, WAI, WCAG, Web Page, Website, Wiki, WYSIWYG, XML

Related articles

Published: 22nd January 2007 Reviewed: 18th August 2009

Copyright © 2007 Kath Moonan, AbilityNet

User comments and discussion

If you have useful information to add to this article please Add a comment. Comments will appear after they have been moderated.

Discuss this topic in the Knowledgebase forums. This is a useful place to share knowledge, experiences, and ask questions.

Please sign in or register to be able to post a comment or discussion.