Working as an accessibility consultant in an IT company is a very frustrating job right now. Highly publicized lawsuits and deep-rooted accessibility myths leave us with a lot to explain when the final product does not really help visitors. Our clients simply don’t care about accessibility as much as we’d like them to, and there are several reasons for that.

Reason 1: It’s the Law But There’s None to Follow

Since February 2002, it has been a legal requirement for
organizations to make reasonable adjustments to ensure their sites are
accessible. The Disability Rights Commission of Great Britain (DRC)
issued a revised code of practice for Part 3 of the Disability Discrimination Act
(DDA) of 1995, which covers goods, facilities and services. The code of
practice explicitly included Web sites under Part 3 of the DDA and
includes both those that provide services and goods for free and for
payment.

Our clients heard that
and wondered how to make “reasonable adjustments.” They turned to us
for guidance, asking about standards and certifications.

But it’s hard to find standards for accessibility. Guidelines are easy to come by, but they’re outdated, not always logical or practical and are written for a world in which user agents (such as browsers) behave perfectly.

They are also a lot more demanding than they look, and encompass a
whole methodology including testing with disabled users—something that
is conveniently forgotten by a lot of agencies promising “100%
accessible, verified Web sites.”

When we do follow the guidelines, we still don’t get a
certification. A “WAI-AAA” button on our page carries the same legal
punch as “Bill’s world of wicked Web sites gives your Web site five
beer cans.”

Accessibility is about communication and compromise. Nobody expects
you to cater for every disabled group because you simply cannot predict
all scenarios. You need to go as far as you can but keep an open ear
for concerns that are raised before legal action is taken.

Our rap now is “Yes, you can be sued for being inaccessible, but we
cannot offer you a protection against that as there are no standards to
follow.” Tough to put a price on that one.

Reason 2: There Is No Immediate Benefit

There is no immediate, measurable benefit from making a Web site
accessible. Web accessibility enthusiasts might point out that that is
not true as accessible Web sites are automatically more usable, and
search engines can index them a lot easier. That is true but the
benefits of that do not show up immediately—if ever. A fancy microsite
or a video ad for a product, however, can trigger an immediate,
measurable response in the form of traffic or revenue.

Good usability is a very important element in customer satisfaction,
but you will rarely find it on the agenda of a project in the scoping
phase (unless of course the project is usability consulting).

The argument that search engines are “blind billionaires”—that they
“see” the Web like a blind visitor—is also a weak one. Search engine
optimization (SEO) is a vast field and a lot of competitors fight dirty
(e.g., link farms, bridge pages).
Large corporations would rather plan for sponsored links and cross
marketing than concern themselves with markup techniques to boost their
search engine rankings.

Reason 3: Accessibility Is Sold As a Technical Problem

A lot of tutorials and introductory accessibility articles are
written by Web developers for Web developers. They explain all the ins
and outs of the HTML/CSS/scripting we have to worry about, and claim
that it is not hard to do. It is true that when it comes to HTML, 90%
of the accessibility changes happen “under the hood” and are not that
hard to implement. This is also the biggest problem. It’s hard to
explain to non-technical client why you have two development hours on
your plan that didn’t result in any visible change.

Accessibility is perceived and sold as a technical issue, and there
is little documentation out there for project managers on how to plan
and budget an accessible Web site. They think it can be done later or
that the developers will automatically take care of it.

If we want to develop a usable, accessible Web site, the development
phase is far too late to think about accessibility. Designing for
accessibility means ensuring that:

• Text is easy to understand
• All image material and colors are unambiguous to various groups of visually impaired users
• There are meaningful text alternatives for all content images and multimedia
• There is a glossary explaining all acronyms and abbreviations
• The navigation and the flow of the site is logical and easy to follow
• The maintenance staff of the product knows about these issues or gets trained accordingly

Reason 4: Disability Is Not Something Clients Want to Think About

A big problem with accessibility is that we just don’t want to think
about why it is needed. For a visual person there is nothing scarier
than the loss of sight. To address accessibility, the client and the
designer has to think about what that experience would be like. The Web
is still perceived as a medium for the able, the young and the wealthy.
If your client sells games online and says its customers are in their
twenties and have fast computers with broadband connections, it might
be a tough sell to ditch the plan to build 150 links in a four-level
drop-down navigation. Some clients can’t imagine that anyone in their
audience would need to use the tab key to move through menus.

In Greek drama, the choir acted as the perfect audience, asking
questions and commenting on the happenings. A lot of clients have
something like that in their head when they talk about their users. The
target audience is not necessarily the real audience, though. Grandmothers might be buying games online for their grandkids’ birthdays.

Reason 5: We’re Past Inventing, We’re Maintaining

As Joe Clark pointed out in his excellent book Building Accessible Web sites, it is a lot harder to retrofit an existing Web site than to start from scratch.

The Web is no longer new. Many companies spent a lot of money on
their site, and it’s not always an option to start from scratch.
Building an accessible blog or a 10-page brochure site is a lot easier
than cleaning out a 200,000-page monster maintained in an
eight-year-old content management system.

It’s even harder if you built the client’s site in the first place.

For years, badly planned and executed Web sites were sold at high
prices. Now we have to tell businesses they’ve been had. Nobody likes
to hear that they need to replace an expensive, functional product with
a new one.

Reason 6: It Is Not Part of the Testing Methodology

The way we test Web sites is still rooted in the days of the browser wars. The important questions are:

• Does the page work on browsers X, Y and Z on operating system 1 and 2?
• Does it work on monitors with 800 by 600 resolution and is everything important visible without scrolling?
• Are all images loading and positioned correctly?

We also need a methodology and test plan to address non-visual accessibility issues:

• Does the alternative text make sense?
• Is the language easy to understand?
• Do links on the page make sense outside their context?
• Does the page have a logical header order?
• Does the page make sense without the style sheet?

Accessibility issues that require human verification are harder to
quantify. Some automated verification tools flag these issues as “user
checks” rather than “possible fatal errors that need user testing.” To
clients, a bug that can’t be seen is not worth extra money spent on
intensive testing.

Reason 7: Accessibility Seems Like a Party Pooper

Although the Web has been around for quite a while now, technology
is still being toyed with. You don’t see newspapers printing at a
45-degree angle or TV news anchors talking “street,” but on the Web,
anything goes.

Clients want their Web sites to be interactive—often, this means an
interaction-required navigation that creates hardship for some disabled
users. Unfortunately, it’s a lot easier to get a budget approved for a
project with lots of flashy visuals than for a plan scoping out a very
usable and accessible Web site. After all, the latter requires more
client interaction and—gasp—maintenance.

Reason 8: Nobody Complains

It is hard for a client to see accessibility as a need when nobody complains. Many elderly and disabled people don’t claim their government benefits,
so it’s safe to say that thwarted Web site users don’t necessarily
complain. “No feedback is good feedback” seems to be the credo for a
lot of site owners unaware of how badly their site is performing.

Reason 9: It Requires Involvement

One reason our clients don’t care about accessibility is that it
means that they will have to deal with their Web site. In the
low-budget market, clients think that you pay a Web designer to do your
Web site and that’s that. A company brochure is not enough to base a
fully accessible Web site on, and “build it and they will come” does
not hold true anymore.

Aside from competitive pricing and a superior product or service,
the only way to have success with your Web site is to give visitors
what they want, regardless of their ability and technical environment.
Many clients don’t want to be so involved. They can simply give their
ideas to the print shop for their brochure, so why should they have to
help a designer create and maintain a Web site?

Reason 10: There Is No Leader to Follow

The saddest reason for client indifference toward accessibility is that there is no leader to follow. Except in the case of Maguire vs. Sydney Organising Committee for the Olympic Games
(SOCOG), no one has successfully sued a company for discrimination
because of an inaccessible Web site. This makes it hard to spark a
feeling of urgency in our clients.

Few big corporations follow Web standards, mostly because of legacy
systems and methodologies lingering from the days of browser wars.

As the DRC pointed out in its April 2004 report The Web - Access and Inclusion for Disabled People 81% of 1,000 Web sites failed to achieve a minimum level of compliance.

Another problem is the products that drive the Web. There are few
content management systems that enforce accessibility testing in their
workflow or create proper markup.

The same applies to frameworks like Microsoft’s .NET. Most
“accessibility enhancements” mean graceful degradation for browsers
like Netscape Communicator or “adding an alt attribute.” WYSIWYG
editing is a very big selling point for a content management system,
but it will inevitably result in malformed markup and bad document
structure. Clients don’t care—all they want to do is easily maintain
copy.

So what can we do?

Gently prod clients in the right direction. Here are some ideas:

• Stop selling accessibility as a technical issue. Address it in the scoping and design phase rather than at delivery
• Make sure you’ve got your facts straight before releasing another
  “accessibility” article or blog entry (rounded corners in CSS do not
  increase accessibility, really, they don’t!)
• Make product presentations and assessments more fun by taking away the client’s mouse and changing monitor settings
• If you want to support disabled users, don’t stop at one group.
  “Skip links” helps blind users and keyboard/switch access users alike,
  don’t hide them!
• Send emails to companies every time it is hard for you to use their
  site. Point out that you will buy the product on their competitor’s
  site and why.
• Step away from the visuals. Embrace Web design as a mixture of good
  content, proper structure and nice visuals. Start developing sites in
  the text editor, not in Illustrator.

Filed under: Web Development