Web Accessibility

Some quick quotes, then some commentary...

"The percentage of people with disabilities in many populations is between 10% and 20%."
- http://www.w3.org/1999/05/WCAG-REC-fact#demographics

"...the number of people using the Web is steadily increasing, and for people with disabilities access to this technology is sometimes even more critical than for the general population..."
- http://www.w3.org/1999/05/WCAG-REC-fact#demographics

"21.1% of people with “vision problems” have Internet access (1,542,410 people)
27.2% of people with “hearing problems” (1,893,392)
22.5% of people with “difficulty using hands” (1,411,200)
42.2% of people with a learning disability (1,242,790)"
- http://joeclark.org/access/webaccess/JVoluntAdmin.html

"Target is being sued because the retail giant's website cannot be accessed by blind internet users."
- http://www.out-law.com/page-6634

In the United Kingdom it is REQUIRED BY LAW to build accessible web sites. Here in the United States Section 508 requires federal agencies to make electronic data accessible to those with disabilities. And although we don't have specific laws pertaining to web accessibility in the public sector, there are ongoing cases where traditional (non electronic) disabilitiy laws are being tested against web sites.

The legal aspect is only one part of the picture. What about the 6+ million U.S. web users who are potentially customers of your web site? I think that we would all like to have more customers than we do now.

Accessibility for your site also extends far beyond those with dissabilities. Accessibility is about making your site accessible to ALL users, regardless of disability, regardless of user client, regardless of connection speed. Is your site accessible to a user with Netscape 4.0 on a slow disl-up connection? If not, then your site isn't very accessible.

Often you hear that "you can't design for all browsers", but I disagree. By using web standards like XHTML and especially CSS, it is possible to cater to ALL users, and it shouldn't cost you more to do so. Note that when I say that the site will be accessible, I don't mean that the site will be still be as visually appealing, but it will be useable.

Here is a good example of an accessible site. Firefox allows you to turn off both images and styling, so it is an ideal browser for testing accessibility. If you go to http://boagworld.com and turn off both CSS and images you will see that the site is still very much accessible.

Next, go to your web site and try the same test. How did you do?

Why should you write tests first?

(this is a response I posted to the question below regarding test-driven development)

Saulius said: "All this sounds nicely, but what about those situations when you need something done yesterday?"

This is one of those things that is difficult to explain if you haven't done it. I get this question a lot, and it is hard to convince someone to test first.

I think that perhaps the only way to answer the question is to maybe ask one of you.

You do test your code, don't you? Eventually?

With test-driven development you are just writing the tests first instead of last (evn if testing means running the app in the browser). The side-effect of testing first, which has been proven over and over, is that your code becomes cleaner, is easier to maintain, and has less defects. This last side effect is where you save all of your time.

The trick of course is that you need to learn HOW to test your code. This is the time consuming part, but it only needs to be done once. You need to learn how to use the testing tools for the language you work in. Once you have done this, the actual writing of tests takes very little time.

Favorite Tech Podcasts

A coworker was talking about a tech podcast he is listening to, and asked if I knew of any other podcasts that I would recommend. The following is my short list, in no particular order.

Boag World
http://www.boagworld.com

Two Brits going on about web development and maintenance. Hosted by Paul Boag, and his side-kick Marcus. The discussion is entertaining and informative. On occasion coworkers from his employer, Headscape, will join in the discussion.

This Week in Tech
http://thisweekintech.com

Hosted by Leo Laporte, of Screen Savers fame, and his cronies. The posse includes Patrick Norton of Digital Life TV, Kevin Rose of Digg.com, John C. Dvorak of PC Magazine, and others. These high-profile attract high-profile guests, like Steve Wozniak and Kevin Mitnick. A very entertaining bunch discussing the technology news for the week.

The Java Posse
http://javaposse.com

Hosted by Dick Wall of NewEnergy Associates, Carl Quinn of Google, Tor Norbye of Sun, and Joe Nuxoll of Apple. If you want to know what is happening in Java today, this is the best place to start. Great guests and great discussion.

Inside the Net
http://twit.tv/podcastinfo

Hosted by Amber MacArthur and Leo Laporte. They interview the people behind popular new sites and services. Interviews include the minds behind Firefox, PodBop, Pandora, Newsvine, and many others.

Web 2.0 Show
http://web20show.com

A podcast about the people behind Web 2.0 technologies. Interviewees include Ryan Carson (Carson Systems), Dan Cederholm (designer), Jason Fried (37 Signals), Jason Calacanis (Weblogs, Inc.), Kevin Rose (Digg.com), and others.

Honorable Mention

Software Engineering Radio - Hard-core software engineering.

Zdot - A real developer talking about real problems and solutions.

Coding A Tight Ship

Good programmers get that way by making mistakes, and seeing the mistakes of others.  I saw a mistake made by a colleague not too long ago which caused a problem that was very difficult to track down, and I learned from it.  The mistake was changing shared objects that should not have been changed.  Specifically, the objects were cached objects used all over the system, so changing the objects caused the cached versions to be changed as well.  My solution to this problem was to make shared objects immutable, or read only.  This wasn't exactly as straight-forward as I would have thought.

The first problem, I had entire lists that were cached.  This list was drawn from the database, and used over and over as a complete list, so it made sense to cache the list as a whole.  I chose to use java.util.List as the interface for the lists I was returning, but quickly realized that there is no immutable List in Java, or at least none that I found (know of any?).  So I decided to roll my own.

I started by creating a class called ImmutableList which extends java.util.ArrayList, and has a constructor which takes a List that it is to secure.  I am using Java 5 with support for Generics, where "E" is the object type to be stored in the List (for those still using Java 1.4 you can for the most part replace "E" with "Object").

public ImmutableList (List<E> list)
{
 super(list);
}

Next I went through and wrote methods to override methods that did stuff to the list.  I have all of these methods throwing a run-time exception that I created.

public boolean add (E o)
{
 throw new ImmutableRuntimeException();
}

public boolean remove (Object o)
{
 throw new ImmutableRuntimeException();
}

...etc...

But there is a problem, the List interface has methods that return a java.util.Iterator object or a java.util.ListIterator object.  Both of these iteration object s have the ability to alter the underlying list, so this too needed to be locked down.  I made these private inner classes so that they could only be created by the ImmutableList.  Every method that allowed changes to the List will throw a run-time exception.  Below is what the immutable version of the Iterator looks like.

 private class ImmutableIterator implements Iterator<E>
{
 private Iterator<E> iter;

 public ImmutableIterator (Iterator<E> iter)
 {
 this.iter = iter;
 }
 
 public boolean hasNext ()
 {
 return iter.hasNext();
 }

 public E next ()
 {
 return iter.next();
 }

 public void remove ()
 {
 throw new ImmutableRuntimeException();
 }
}
 

This locks down the List, but don't forget to also lock down the objects inside of the List.  When you get done, it should be impossible to write to the object or any object that it holds.  Don't leave it to convention to enforce policy, enforce policy with the language.  If you do this, and the system starts to misbehave, you have one place to look.  Of course, the more you do this, the less likely a bug will be introduced into the system.  We are human, we make mistakes, so why not make it easier for us by enforcing some rules.

Happy coding.