Weblogs: Web Accessibility

The fallacy of too much accessibility

Wednesday, December 26, 2007

There is no such thing as too much (or overdoing) accessibility, and its ludicrous to suggest that too much accessibility actually reduces the accessibility of a site. The second statement is an obvious contradiction, making a site accessibile does not mean making it less accessible.

What we are seeing is a non-understanding of web accessibility, which is leading to results that don't improve the accessibility of the site.

The real meaning of accessibility

Accessibility is the capacity of making content perceivable, operable, understandable and robust to people with disabilities. As such, making accessibility repairs or improvements would - by definition - make content more accessible, because it takes into considerations the disabilities people suffer from, and how content can be non-perceivable, inoperable, non-understandable and fragile because of disability.

The key basis of understanding accessibility is understanding how people with disabilities use the web; essentially what type of content (or its rendering) they can't or have difficulty in perceiving, using or understanding, and in the worst-case can't tailor or adapt content to their needs.

Considering implications of accessibility improvements

There are times when an accessibility fix may benefit someone with one disability, but make things harder for someone else with another disability. As with all accesibility improvements, these cases need to be weighed up by critical thought and user testing.

One good example is colour contrast, where high contrast colour schemes benefit people with low-vision, but prove in many cases to be a frustrating barrier for people suffering from dyslexia; the more we benefit one, the less we benefit the other. There's a certain amount of trade-off and balance to consider here, the key approach is to ensure that content is not impossible to access - sometimes that means content remains difficult to access.

But these are not the situations that give rise to blog posts warning about too much accessibility.

The typical example

More often than not, the common example cited by accessibility commentators warning of too much accessibility is the markup fragment of an alt attribute to an image:

<img src="tr.png" height="10" width="10"
 alt="Top right corner of the page">

Apparently the alt attribute of Top right corner of the page is an examle of accessibility taken too far. This is an accessibility problem, but this is not because accessibility was taken too far.

This error is typical of developers trying to make a website accessible, but failing to understand what accessibility is. Its a clear sign that the barrier to access hasn't been taken into account. The intention may be there, but the understanding isn't.

This indicates either a failing of the developer to learn about accessibility, or a systemic failure of the accessibility community to teach accessibility.

Distorting accessibility

Why does this mistake occur over and over? Where is this non-negotiable need for every image to have a populated alt attribute coming from?

Its coming from bad advice, advice that has been so watered down and disfigured that the real advice is buried and the distorted dogma of Give every image an alt attribute.

This advice is distorted because the presence of an alt attribute is not the fundamental step of making an image accessible. An image with an alt attribute doesn't suddenly become accessible. There is something far more important than the presence of an alt attribute to making an image accessible - that something is the presence of a text equivalent of the image's content. Many people in the accessibility community seem oblivious to the distinction, and that is rubbing off on web developers.

This distorted advice, as a way of teaching or instructing accessibility, is wrong. It gives the developer no option but to mindlessly regurgitate the advice. There's no understanding, and thus no thought can be applied. The developer has no significant means of assessing whether his fix actually removes the perceived barrier.

When you give a developer a distorted piece of advice, the end result of following such advice is correspondingly distorted. A developer needs to understand why the change he is making is necessary (what barrier does it tackle?), how it benefits people with disabilities (who is affected by the barrier), and what are the side effects of doing it (what other barriers does it leave or create?). When the accessibility problem is identified and understood, the path to an actual solution is relatively straightforward.

Accessibility and validation

Where is this distortion coming from? The conflation of web accessibility and validation. Validation is one of the key cornerstones for interoperability and universality - its important for universality, but not really all that important for web accessibility. (All other things being equal, well-formed markup is sufficient for robust accessibility.)

Validation, insisting on an alt attribute on an image, is part of the problem. A validator requires an alt attribute on images, but says nothing about what its meant to contain. When it comes to accessibility, validation is not all that important.

The correlation between validity and accessibility is weak. Screenreader users were using the web right from the beginning, before web standards gained any traction at all. They grew up with invalid and badly formed markup, so valid markup isn't that great a deal. What screen reader users needed was accessible sites, not valid ones. There's some cross-over, but that's merely because developers who build accessible sites today also use (close to) valid markup. The correlation isn't because one benefits the other, but because the developer does both as a matter of course.

Fixing the root cause

The root cause is the tickbox mentality - technical-orientated checklists. Advice like Give every image an alt attribute needs to disappear, and replace with actual accessibility guidance.

Instead of listing the technical repairs for problems, the time is better invested in explaining what the real problem is. Its very much like the cliche of teaching a man to fish.

Developers who are required to make a website accessible have the duty to learn about accessibility so that they can perform their jobs to a satisfactory level. This involves learning about how disabled people use the web, identifying barriers on their own sites, understanding what those barriers are and how they affect disabled people. Only when they reach that point of adequately diagnosing and understanding the real accessibility problem does the technical repair or improvements need to be considered.

The accessibility community is making a grave mistake by advocating technical advice without offering a rational explanation of the accessibility barrier, why its a barrier, and describing the various techniques and approaches for resolving the barrier (along with pros and cons of each approach).

Its clear in the example markup snippet the developer has been told that images need an alt attribute. Its also clear that developer doesn't sufficiently understand the reason behind that proclamation, and is not in a position to identify whether his change has helped, hindered or made no difference to the accessibility of the page.

Teaching the fundamentals

A developer working on creating an accessible website needs the right guidance, he needs to be properly informed and educated (in addition to the ability to think). For example, here are the considerations a developer should be well aware of and consider (as well as use in his thinking) in making an accessible website:

Provide equivalent alternatives to auditory and visual content.
Don't rely on color alone.
Use markup and style sheets and do so properly.
Clarify natural language usage
Create tables that transform gracefully.
Ensure that pages featuring new technologies transform gracefully.
Ensure user control of time-sensitive content changes.
Ensure direct accessibility of embedded user interfaces.
Design for device-independence.
Provide context and orientation information.
Provide clear navigation mechanisms.
Ensure that documents are clear and simple.

None of the above should come as any surprise to an experienced developer, and this advice has been around for almost a decade now.

Any reasonably competent accessible developer should be able to take any of the above points and describe what the fundamental problems people with disabilities face, and how each point addresses that barrier. Once that is done, the developer should then be able to outline approaches for real world websites, evaluate each proposed technique and be in a position to determine which technique is sufficiently adequate.

Understanding the above is sufficient for developing and creating a static brochure-ware website, and perhaps sites with very simple ecommerce applications. It was certainly sufficient for Legal & General's web accessibility project.

Websites offering a richer experience need more modern considerations. The problem with the above considerations is that they focus very much on the state of technology on the Web from the last century, and they fail to take into consideration accessibiliy improvements in widely available technology used on today's websites.

There is a newer set of considerations are more appropriate for today's modern world (they take into account technology improvements over the last decade):

Content must be perceivable.
- Provide text alternatives for all non-text content.
- Provide synchronized alternatives for multimedia.
- Ensure that information, functionality, and structure can be separated from presentation.
- Make it easy to distinguish foreground information from background images or sounds.
Interface elements in the content must be operable.
- Make all functionality operable via a keyboard interface.
- Allow users to control time limits on their reading or interaction.
- Allow users to avoid content that could cause seizures due to photosensitivity.
- Provide mechanisms to help users find content, orient themselves within it, and navigate through it.
Content and controls must be understandable.
- Make text content readable and understandable.
- Make the placement and functionality of content predictable.
Content must be robust enough to work with current and future technologies.
- Use technologies according to specification.
- Ensure that user interfaces are accessible or provide an accessible alternative(s)

None of the above should sound like rocket science to a web developer. Its all fairly good common sense. This list is effectively an expression of the typical barriers people with disabilities face when using websites, and a guidance as to how to alleviate or remove that barrier.

This is a set of first principles. Its a fundamental starting point for making a website accessible. Frankly, if you don't understand how a barrier prevents disabled people from using a website, how can you be certain the solution you implement alleviates, or reduces, that barrier?

We need to stop this nonsense about dogmatic technical quickfixes, and start afresh with first principles. We need to understand the real world problems disabled peope face - using the above considerations to frame that understanding. Once that picture is built up and understood, then the technical aspects of the solution can be implemented with understanding and consideration towards the real problem being solved.

Profiting from the fundamentals

I realised, from working on Legal & General's landmark accessibility project, that the technical solution was only a small part of making websites accessible. We spent a good portion of time discussing potential accessibility barriers or problems, understanding the effects of those barriers. Once we understood those barriers sufficiently were we in a good position to roll out a technical solution, understanding the implications of each technique, and using the technique that best tackled the barriers we found.

The end result speaks for itself. Julie Howell, Director of Accessibility at Fortune Cookie (also an author of PAS 78, and was the Digital Policy Development Manager for the RNIB), on the BoagWorld podcast episode 91, mentioned that Legal & General saw a 300% increase in revenue and business in a major financial product within months because of the accessibility overhaul we did (1:02:53 into the podcast). I believe that proves the correctness of our approach - getting developers to approach a website by appreciating the barriers from a disabled person's perspective.