As technology progresses, we change the way we work and our technology and tools we use to better suit our situation. Note the contrast in terms of the items in the three frames: the upright phone, better lighting, the ergonomically designed keyboard, desk and chair. Also note the common element to all frames: in each, there is is a person that is trying to accomplish something with technology.

Accessibility, Usability and HCI deal with making well-informed decisions when designing a "solution". If we aren't paying attention to research, and conducting our own with people, then we are in many ways designing in a vacuum.

This isn't unique to accessibility -- while we suggest to all developers that we work with that they should test their own work for accessibility, and that they should ask each other for help, we still maintain that in all cases, sites and applications need to be tested with real people.

In my view, there are three conceptual components to Web Accessibility: a Philosophical component, an Implementation component and an Awareness component.

Philosophy of Web Accessibility

Part of this philosophy is admitting that we don't know as much about how people use the web as we think we do -- what we "know" is a pretty narrow slice of the web and how it is used. The second is that we need to accept - and perhaps embrace - the fact that we have a lot less control than we might like.

Implementation of Techniques

This encompasses best practices in HTML, CSS, JavaScript, specific accessibility enhancements/features of HTML, and providing information in an accessible format.

Awareness

Awareness serves as a bridge between the two other components of accessibility. Without a good understanding of the philosophy behind accessible development, it is too easy to implement "accessible web development" techniques that fall short of providing any real value, and in some cases may actually hinder accessibilty and usability.

Alternative Formats

The largest and most obvious impact here is for people using screen reader technology. It also applies to situations where images are off or multimedia capability is not available.

Markup Abuse and Visual Appearance

These two issues go hand in hand. HTML has specific structural elements: paragraphs, headings, lists, tables and forms. Screen readers and other adaptive technology rely on this structure to be there in order to work properly to allow their users full access to the semantic information that is created by those structural elements.

Some typical abuses include:

• tables used to line up little arrow images as bullets,
• text that has been increased in size, made bold, and a different colour instead of using a heading
• text indented using blockquote
• forms that use a different style of text to create sections

In all of these cases, we should use the appropriate HTML elements.

Clarity and Links

Links need to make sense out of context. This principle exists at two levels:

1. when formally using a list of links to navigate (either with adaptive technology or otherwise)
2. when informally using a list of links when scanning a page for "something to click"

Sizes: Too small and fixed

There are a few areas where this is important: text size, links/buttons and form controls.

Text size needs to be adjustable. Links (especially buttons) need to behave like buttons - the whole visible area that appears as the button should be clickable. Form controls should employ proper labels for the benefit of screen readers, voice recognition software as well as every day users.

Everyone has their part to play in ensuring that web sites are accessible. Developers focus at the code level, managers at the higher philosophical level.

Often left out of the equation are the people that have special needs. We mustn't forget that they need to become efficient and effective users of their technology. I believe people using adpative technology and other people that use our sites need our help: see Web User Education Guidelines

At this point, there are no guarantees as to what will happen with Bill 118. It may not become law, and we don't know how extensively it will be applied to the web in terms of enforcement or the private sector. This is definitely something to watch.

Research

While there is some excellent co-ordinated research in the field of accessibility, I'd suggest that there isn't enough. Significant knowledge about accessibility exists "out there" in weblogs or on other web sites that isn't formally documented, and people generally don't know that the resources exist. A more formal approach would be very beneficial in the accessibility field - it would help with spreading knowledge and techniques for implementation.

Education

Pretty much every field of endeavour can benefit from education, and web accessibilty is no different. We need more and better education initiatives focussed on developers, management and other stakeholders, as well as the people that use our sites.

Despite the fact that there is an onus on users to understand and effectively use their technology (whether just a browser or assistive technology), I still firmly believe that we need to help users with their education. A text sizing widget on one site only helps the user on that site. In general, using features such as these would benefit from supporting explanation that shows users that they can accomplish the same thing on all sites by using their browser settings. For more thoughts on web user education, see: Web User Education Guidelines

Preferences

This is a limiting factor that has an impact on everyone, not just those that are the primary target of web accessibility work. As an example: the use of Macromedia Flash on a web site can be made more accessible. However, a common assumption that is made by web sites is that if someone has the Flash plugin installed, that they want to receive Flash content all the time. We need to have ways of "getting around" that Flash - whether in the page itself, or via global browser preferences.

In my utopia - we'd have the ability to specify our preferred format for multimedia and automatically receive that when it is avaiable as a format. Or, it would be possible to not show any multimedia by default, but always get a static image version with text transcripts where applicable.