Web Accessibility and Usability: The Human Factor

Derek Featherstone



A Scenario

Used with permission. Copyright © OK/Cancel

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.

The Human Factor

The Human Factor continued...

We don’t want to figure out what all of those buttons do, or why they are set up the way they are. We just want to get on with our lives or do our jobs well. When we make use of technology, we want to focus on achieving our goals, not on deciphering the technology.

…it’s very easy for them [the Wizards]to forget how the rest of the world thinks. The result is often technological systems that are technically sound and easy for other designers to use, but that bury ordinary people in a quagmire of complexity.

Kim Vicente, The Human Factor

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.

A View of Accessibility

  1. Philosophy
  2. Implementation
  3. Awareness

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 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.

"Typical" Accessibility Issues

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.

Who is responsible?

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

Legislation & Policies

Ontario: Bill 118

The Ontarians with Disabilities Act became law in 2001. It has received much criticism on number of fronts. Bill 118: Accessibility for Ontarians with Disabilities Act aims to replace the ODA in order to address some of the ODA shortcomings

In theory, Bill 118 will:

  1. provide for enforcement
  2. provide timelines for compliance
  3. extend accessibility requirements to the private sector

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.

Current Limitations


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.


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


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.


Further Information

Feel free to contact me:

We also have an e-mail list where we announce publication of our new articles or relevant news items from around the world that are accessiblity related.