10 Reasons Clients Don't Care About Accessibility
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
Clients want to hear success stories from market leaders before they spend money. Unfortunately, pointing out that Amazon.com does not have a 450KB rotating logo splash page will not convince inexperienced clients that it’s a bad idea.
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.
Clients want to hear success stories from market leaders before they spend money. Unfortunately, pointing out that Amazon.com does not have a 450KB rotating logo splash page will not convince inexperienced clients that it’s a bad idea.
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.
Labels: Accessibility
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home