How Expensive is Web Accessibility?

Nothing. Done.Wouldn’t it be nice if we could just say accessibility costs nothing? In fact, that’s what some people (including myself) have said. As far as I’m concerned, that’s exactly what it costs when I make websites because I’ve been doing it so long that developing accessibly is just how things get done. But that’s the catch to such a claim, isn’t it? When it becomes part of how you do things, of course it is free.

Whenever I leave my car, I lock the doors. It (the locking action) even has its own motion. I open the door, hit the door lock, and shut the door with one hand. One time, I stopped at a Burger King on the way to Kings Dominion. When I got out and shut the door, I missed the lock. Muscle memory kept the whole motion underway until my brain realized that the door wasn’t locked. I tried sneaking my hand back in to lock the door, but it slammed on my hand. The doors on a 1970 Camaro are really heavy. One of my fingers split wide open like an overcooked hot dog. Anyway, the point is, once you get used to doing something, that’s just how it gets done, all the time, every time. The same goes for accessibility. The problem is, whenever someone asks “How expensive is accessibility”, they aren’t one of those people for whom accessibility has become a habit. Typically, the “How much does it cost” question happens when someone is working to integrate accessibility into their processes and, in such a scenario, costs can be very real and very substantial if not handled correctly.

What Accessibility Related Costs Are There?

It is this latter point, I think, which got me called out on Twitter recently. Very often, development and QA staff aren’t knowledgeable about accessibility. Very often, it hasn’t yet become well ingrained in how things get done across the organization. Finally, it is often handled in a way that makes it an expensive undertaking. Typically, you will find added costs in the following areas when it comes to integrating accessibility:

• Determining accessibility requirements for final deliverables
• Developing internal style guides and best practices
• Training staff
• Finding new toolsets
• Modifying existing codebases
• Additional QA time & resources
• Consultant Fees/ Salary for an internal Subject Matter Expert

Determining accessibility requirements for final deliverables

When adopting accessibility it will (or at least it should) typically mean that new requirements will be added to the acceptance criteria for final deliverables. Determining which requirements must be included will take some time. How much time depends on how many requirements and what type(s) of ICT products are under development.

• How to do it right: Adopt an agile approach, even if you’re not an agile shop. Start out small and integrate the set of highest impact items into requirements. Such things as accessible form labeling and instructions, effective alt text, and good document structure don’t need to take a lot of effort to do or to describe in requirements but have a high positive impact on accessibility. Then, as the organization matures, begin iterating on past successes by including additional sensible requirements.
• How to do it wrong: Trying to do too much from the start. Setting out on a special project to put together the full list of requirements applicable to all possible scenarios is the wrong approach and is only advisable if you’re under legal pressure and are seriously out of compliance.

Another option in this area is to make use of the many already existing information resources on this topic. The Web Content Accessibility Guidelines aren’t particularly fun to read, but there is a lot of good accompanying material including Understanding WCAG 2.0 and Techniques for WCAG 2.0 which can all be used as resources to help put together your own requirements documents.

Developing internal style guides and best practices

Related to the above, requirements for accessibility are usually the kind of things that are static in nature. In other words, depending on the type(s) of technology under development, outlining what criterion need to be met to be accepted is the kind of thing you typically should do once and reuse for every project. Many organizations have internal coding style guides (or coding standards) in use which allow the development staff to understand the organization’s standard practice for development. Some of these style guides are more detailed than others. Some of them are solely oriented around code formatting & naming conventions whereas others talk about both coding style and visual style. It only makes sense, therefore, to include accessibility coding standards into these internal guides so that accessibility becomes built into the coding habits of their developers and many of my clients have done so very successfully. In fact, it is this sort of integration of accessibility throughout an organization that allows you to be successful in accessibility.

• How to do it right: Again, use an agile approach here. Begin by including the subset of most high-impact items and iterate on success. As other changes happen to the style guide, take the opportunity to ensure that those changes also include any necessary accessibility improvements. When something is added to the style guide, ensure that the new item includes accessibility in it.
• How to do it wrong: Undertake a project to develop a big, special accessibility style guide. Doing so means resources dedicated to such a project will be taken from other projects. Furthermore, it continues the separation of accessibility as its own distinct effort rather than becoming integrated.

Another way to do this right is to assign such a task to be done during downtime. For instance if a knowledgeable developer has some extra free time, get them to contribute some of that free time to adding to and improving the style guide.

Training staff

As I so often say, accessibility issues are not caused by malicious developers but rather ignorant developers. Upon recognizing that there is a common lack of knowledge among development staff, it is natural and good to want to train them. I view training as the single best strategy for making a more accessible web. Training will come at a cost of purchasing/ developing the training and lost time for employees who must attend the training.

“What’s worse than training your workers and losing them? Not training them and keeping them.”
Zig Ziglar

There is no “How to do it right/ how to do it wrong” for training. How to do it wrong is to not train. Training has a wide array of payoffs that will easily offset any costs – both in the long term and short term. Training improves employee performance and productivity, and is the fastest way to get them successful at developing accessibly.

Finding new toolsets

Integrating accessibility into development processes will likely make it necessary to include additional tools into the developer and QA engineer toolset – specifically tools to test whether their work is compliant or not. There is a wide array of accessibility evaluation tools and an equally wide variation in features & quality among them. Large enterprise class tools can be quite pricey and may not be appropriate for all organizations.

• How to do it right: Make a smart buying decision that nets you a tool which is easy to use, works well, and fits in with your process.
• How to do it wrong: Do the opposite. Buy something over priced and that is not user friendly. Having a tool you hate will mean that in a short time it will become shelfware because nobody wants to use it.

In a future blog post, I’ll discuss buying an automated testing tool. There are too many considerations to go into here. For a large organization with a very large website, an automated testing tool can have a huge payoff in terms of efficiency, with the caveat that quality and usability of the tools matter quite a bit.

Modifying existing codebases

It is very rare for developers to write completely new code from scratch. In most cases, they’re reusing code they’ve used in the past or using frameworks created by others. At this point every programming language out there has a developer community which has created and shared so much code that it is very rare for developers to start from scratch. Even in cases where some from-scratch development takes place, developers often tend to reuse whatever they can. This is the smart way to do it. Reinventing the wheel sucks. But when an organization discovers their systems have accessibility problems, it is rare that such problems are simple issues caused by one-off code. Typically, accessibility bugs will fit a pattern where individual pieces of code, reused in multiple places, causes the problem everywhere it is used. This isn’t unique to accessibility, by the way.

To give an example, let’s say I had a PHP forms class (which I do), and I have a method in that class which creates a textarea (which it does) and you call that method like so:

$form->textarea('Comments', 'userComments', TRUE);

Now, let’s say here’s the output for that code:

Comments * <textarea name="userComments" >

If you have a basic understanding of accessibility, you’d see from the above that this method creates a textarea which does not have an explicit label. Everytime that method is called throughout the site, it creates an accessibility problem. The answer? Modify that class so the method creates accessible markup.

• How to do it right: Prioritize your remediation efforts to eliminate the highest impact/ highest volume accessibility issues first, deferring low impact/ low volume issues for later.
• How to do it wrong: Take an all-or-nothing approach to remediation, starting a special project to just repair accessibility issues, or choosing the wrong issues to fix first.

Prioritizing remediation efforts takes a careful, considered approach and requires an understanding of accessibility and development. Picking the wrong issues to fix will be a waste of time. Trying to fix too much at once will be expensive and time consuming.

Additional QA time & resources

It stands to reason that additional requirements means additional testing time to verify that the requirements have been met. Afterall, an unenforced rule isn’t a rule at all.

• How to do it right: Offload some of the QA work to the developers themselves. This is again an area where Agile can make things easier. Developers should – at minimum – be utilizing a testing tool which allows them to test for those things that can be definitively determined to be pass-fail using machine testing. QA staff should never be finding things like missing alt attributes or missing form fields, because such errors should never make it to version control.
• How to do it wrong: Require all testing to be done by QA staff. Don’t train QA staff in accessibility. Don’t do testing until very late in the SDLC. Require QA staff test for low-impact items.

Testing for accessibility is vital, especially when the organization is new to developing accessibly. Testing early & often and having developers test their own code is vital in avoiding excess cost. The cost to find and repair a bug (any bug) late in the development cycle is well-understood as being unnecessarily high. Avoiding the bugs in the first place is the cheapest approach, which is why developers need to be testing their own code. In addition, QA staff must be trained in accessibility. QA personnel are very often (in my experience) not developers and are therefore accustomed to only looking for things that are definitively pass-fail. So much about accessibility is subjective that QA engineers can often miss things that require them to make a subjective determination.

Consultant Fees/ Salary for an internal Subject Matter Expert

Consultants (such as myself) cost money and the cost of a real expert in something (anything) is real money.

• How to do it right: Hire the right person. Make sure that whoever you hire is really someone who understands accessibility and has experience in working with your type (and size) of organization. Ensure that they have experience working with the technology platforms your organization uses.
• How to do it wrong: Hire the wrong person.

In order to become an accessibility consultant, all you need to do is put the words “Accessibility Consultant” on your business card. It is an unfortunate reality that the pace of technological change is growing faster than many “Accessibility people” can keep up with. In fact, it is something I struggle with every day myself. Hiring a consultant or SME is a great way to quickly close gaps in your team’s accessibility knowledge. The catch is you have to make sure the person you bring on really knows what they’re doing and can help you. Hiring someone whose only web development experience is constructing their own static 10-page site is a bad idea if you’re hiring someone to help on a highly interactive site that gets 10,000 page views per minute. Hiring the right person with the right experience and knowledge will deliver value that goes far beyond the money you pay them.

How to lessen the pain

By now you’ve probably noticed that my recommendation for lessening the pain is to adopt an Agile approach. As I’ve said in earlier posts, using Agile enables an easier integration of accessibility so that it doesn’t exist as its own distinct process. When responsibilities for accessibility are distributed their impact is lower. Similar steps can be taken toward an iterative approach which lowers the impact of the new accessibility efforts so that ultimately accessibility is just how things get done. For example, an organization can start small by choosing only a small subset of high impact accessibility best practices to concentrate on. This is a far better approach than attempting to take on the full range of accessibility requirements anew. If you handed a restaurant menu to someone and said “you need to eat everything” they would begin to feel full before the first bite. Taking small steps means quick wins, less disruption, and more buy-in.

Not seeing it as a “Cost” in the first place

My earlier point when I stated I don’t see any difference in terms of development time for something inaccessible vs. something accessible was as much about attitudes as it is about actual time. In any given development scenario, development staff will inevitably have a situation where they need to think of a solution to a new and interesting challenge. Or, they may need to adhere to a new style guide. Or, they may need to change the way they do something to avoid a known bug. Or there may be something else in the long array of possibilities that changes how things get done. All extra time is extra money, but people never track these changes as something separate and different from any other time. Why do we think we need to track accessibility? If we need to create a new object because the existing object isn’t keyboard accessible, then we should do it and chalk it up as the time needed to do a good job instead of acting as if it is something extra. Making this change of mindset is the first step toward accepting accessibility as “just the way we do things” and stops this from being a conversation about accessibility and frames it as just doing a good job.

So how expensive is accessibility?

I don’t know. There are obvious expenses involved whenever an organization begins adopting accessibility which are diminished as accessibility as a topic is adopted and integrated into how things get done, but nobody truly knows what those costs are or how rapidly they’re diminished. There have been plenty of guesses and some of them look sensible, but I think the truth is that nobody has a good grasp of the data. Part of the reason why the data is so hard to get ahold of is because those who are successful at accessibility are those for whom accessibility is integrated into how things get done. Given the lack of data on this topic, I’m just as comfortable saying accessibility costs nothing as I would be using some made-up claim based on anecdotal evidence.

Update: July 30, 2012

I’ve been concerned for a while that this post has frequently been taken as a statement that Accessibility is free – partly because of the statement I struck above. My overall point for this post is to say that if you handle accessibility right – heeding the points above where I say “How to do it right” – the impact can be very minimal. The problem is that most people don’t do it right. This can, and has, result in hugely painful expenses of time and money when mishandled. The best approach, and indeed the overall message for this post, is to get involved in accessibility now, not later. Start taking steps, however small, that will move you in the right direction and minimize stress, cost, and time later.