Wednesday, September 19, 2007

4. Web 2.0 and Accessibility

Many geeks and pundits are increasingly worried about the pace and scale of “Ajaxification” of everything on the Web. Lawson (2006) claims that “people are so busy adding extra Ajax loveliness that the separate stripped-down html-only versions they offer are unthinkingly accepted as a legitimate sop to people with disabilities.” He adds that there is nothing wrong with Google’s maps, gmail etc, and have never thought that accessibility means bringing everything down to the lowest level of quality or taste. Truly creative and considerate coding will ensure polished “rich user experience”. But in the rush to “Ajaxify” the bulk of developers are not appropriately thinking of accessibility consequences.

Another pundit Keith (2006) suggests that Ajax should be used in the same way that any other kind of DOM scripting is used: as an improvement to, rather than an obligation of, the user experience. He adds “I would like to see the idea of Hijaxing (making sure an application works without JavaScript) applied to pages elements like feedback forms and shopping carts.”

Godding (2006) is not happy with the “thoughtless implementation of technologies, in this case AJAX”. He adds that creative, novel and wide-ranging coding would guarantee that those users who don’t have JavaScript capability are not deprived of information or the capability to take part in this new society with improved user experience. He warns of overlooking of “social conscience in the mad rush to produce something that is Web 2.0 and cool!”

4.1. Ajax and Web Accessibility

In order for Ajax applications to work on web browsers JavaScript and XMLHttpRequest object have to be enabled. Although most popular web browsers are capable of handling JavaScript, it is turned off by default. Mozilla Firefox and Internet Explorer for example, warn the user of prohibited content. There are some other problems regarding accessibility. Consider Google Maps ( for instance, it failed the accessibility when it was tested using Watchfire WebXact Validator ( on the following:

  • No title for frame element to describe the purpose and content of the frame.
  • No extended description for the main map which conveys important information.
  • While colour is used to convey information, the information is not represented another way.
  • While table is used to hold data there was no header for the table rows or columns.
  • If Style Sheet is turned off on a browser, or the page is viewed on browser that does not support Style Sheet the content should be displayed in logical order.
  • If JavaScript is turned off or the page is viewed by browsing devices that not support JavaScript there is nothing useful left on the page. The main function of Google Maps is to find an address or a building on the map. It is not possible to make the page usable with scripts not running or turned off.
  • Programmatic objects, such as applets, plug-ins and scripts may cause the screen to flicker. Screen flickering or flashing in the 4 to 59 flashes per second (Hertz) range can trigger seizures in people with photosensitive epilepsy. Quick changes from dark to light, like strobe lights, can also trigger seizures. See (WebXACT, 2006)
  • As there is no keyboard equivalent to double-clicking ("ondblclick") or mouse movement ("onmousemove") in HTML 4.0 there is no alternative to mouse coordinates.
  • Missing labels for form controls.
  • Lack of sufficient contrast of foreground and background colours. This may not provide sufficient contrast when viewed using monochrome displays or by people who have difficulty seeing certain colours.

The same page was tested using Hermish ( While it passed priority one with 2 cautions it failed on the following:

  • Hermish detected the use of H tags. If your H tags are being used only for decoration then please use an alterative method of text display. Use H tags only to specification not for page decoration. H1 should be followed by H2, followed by H3 etc.
  • Hermish detected the use of DL tags. Be sure to check the correct markup when using lists.
  • Auto re-fresh detected. Please do not use the automatic refresh or re-direction of web pages.
  • When storing data in table columns you should consider providing an alternative, non-column linear format.
  • Are you using HTML mark up within table cells? If so please find an alternative method.
  • Have you checked that association between form elements and labels are positioned correctly?
  • Specify the prime language of the document. Use the Lang element.
  • Are you using a built-in search facility? If you have then provide more than one method.
  • 9 of your text boxes (form elements) do not display default values. When using text boxes and other form element provide a default entry.

Another accessibility validator Miislita ( failed Google map on priority one, two and three.

After Google Maps was validated and failed all three tests, the fundamental question remains for Google developers to answer, if disabled people could actually use Google Maps the same way as normal people. Zeldman (2006) argues that the history of Internet has been to solve today's problems at tomorrow's expenditure. He adds that design today and solve the problem tomorrow is not productive or necessary any more. Google Maps is great and fantastic to use as long as you are not disabled and own a state of the art PC. We also know that Google Maps is still under development and in beta version. Perhaps, this is a good practice for Google to address the accessibility issue now than leave it for later.

Amazon’s diamonds search is an amazing application that offers incredible usability for many web users. ( Once this page was validated using an online validator Wave (, the result was 194 accessibility errors and 24 accessibility alerts. The application is entirely unfeasible for screen reader and keyboard-only users to use, and it is very complicated for any screen magnifier user to use.

4.2. User Generated Content and Accessibility

User Generated Content is normally generated by using JavaScript, DHTML or CSS. Many assistive technologies for the blinds, partially sighted and those who have problem using mouse will not understand and hold these objects. Content generated by client side technologies and web browsers will not be accessible to the users of these assistive technologies.

A. YouTube

YouTube ( contains 100 million videos. Another 70000 videos are added to its database everyday by its users. YouTube’s terms and condition does not even mention the word accessibility once. 25 videos were observed for this research none provides subtitle for video content or transcript of its video contents. No alternative text version of its audio content is provided either.

B. Blogger

Although there are no specific rules or regulation, a blog could be anything from a personal memoir to a hub of links or a news outlet. Your blog is what exactly you want it to be. There are millions of blogs all over the Web. Blogger ( for instance is portal where you can create you own blog choosing one of the predefined templates. In other word you have the choice over the contents of your blog but there is limited choice you have over the style or appearance of those contents. Blogger is entirely dependent on user generated content and there are 100 of thousands of subscribers.

Blogger allocate its members to become its content providers. Most of these users have no idea about web accessibility or they do not care about it. This will cause the majority of disabled people to be deprived of the contents of Blogger. Another issue with Blogger is that creating a user accounts for a blind person is impossible as it include entering characters seen on the picture.

C. Flickr

Flickr ( is an online photo management and sharing application where people can store, search, sort and share photos. Flickr houses millions of photos and thousands more are added to its collections every day. It relies solely on users for its contents. None of Flickr’s video is subtitled, nor extended description used to explain pictures for blinds. There is no alternative transcript of its audio contents available for deaf people. On top of that signing up requires entering characters seen on the picture.

D. MySpace

MySpace ( is another popular portal for people to meet, chat, share photos, blog, and a lot more. Thousands of people are subscribed to its services and they generate content for its pages. Opposite to Blogger MySpace lets its users to style customize their pages as they like. Since most of MySpace members are unskilled web designers this can source accessibility issues. Heavy and unorganized usage of Style Sheet could also cause the unexpected behavior of browsers.

At the moment there is no universal policy to make User Generated Content Accessible on these sites. There are millions of people adding contents on these sites on daily bases. It is utterly impossible for websites such as Blogger, Flicker, YouTube and MySpace to police, control or supervise the accessibility of the content of their sites as they are created by users and there are hundreds of thousands of them.

4.3. What the Future Hold?

One of the main objectives of Web 2.0 is to turn the Web in to a platform. Web 2.0 associated websites are developing more and more interactive and rich applications similar to desktop software. These rich Web applications use AJAX, DHTML, XML JavaScript, and other combinations of existing technologies. Heavy use of these Web technologies increases the risk of leaving disabled people behind.

That is why W3C reacted and introduced the working draft of Web Content Accessibility Guideline 2 (WCAG 2.0) in June 2006. The deference between WCAG 1 and 2 as stated by W3C (2006) “applies more broadly to different Web technologies and is designed to apply as technologies develop in the future. The WCAG 2.0 requirements are more testable. In WCAG 1.0, brief descriptions are included in the main WCAG 1.0 document under each guideline. With WCAG 2.0, extensive guidance is provided for each guideline and success criteria in Understanding WCAG 2.0. The WCAG 2.0 techniques are also more comprehensive and include tests.” W3C in another move on 26 September 2006 introduced Accessible Rich Internet Applications (WAI-ARIA).

Moss (2006) predicts that there are three major factors that will outline web accessibility in the future: AJAX, User Generated Content and WCAG 2.0.

  • “Accessibility will become less and less guideline-driven.” With the arrival of new technologies such as AJAX, and the unclear nature of the new W3C guidelines (WCAG 2.0), accessibility is becoming less and less guideline driven. So accessibility experts will have to explain these guidelines to developers and designers.
  • “Alternative accessible versions will become the norm”. Although for business and ethical reasons a detached text only version of websites has never been loved. At the same time assistive technologies are not capable of understanding rich Internet applications a separate text only version has to be provided.
  • “User-generated content is likely to offer poor accessibility.”
    User Generated Content is here and it increases on daily bases. Taking into account its speed and its size it is utterly impossible to monitor it for accessibility issues.

Web 2.0 presents fantastic opportunities to experience rich and usable internet applications. For the first time in human history anyone can become a journalist, a movie maker, a contributor to important and crucial issues of the world or a celebrity over night. More and more of people are getting connected to each other in order to express themselves and present their points of view. But at the same time it poses a challenge to the world to find ways to include millions of disabled people to experience/participate and enjoy this information technology’s revolution.

1 comment:

Aaron said...

Why not provide more information about ARIA? You mention it briefly and then immediately move on. It's extremely relevant!